Audio Server와 버퍼링¶
오디오 개요에서 오디오 인터페이스와 제품 세션을 선택한 뒤 이 페이지를 참고하십시오. 이 페이지는 애플리케이션 코드, Audio Server 세션, DMA 버퍼, 하드웨어 오디오 경로 사이의 런타임 경계에 초점을 맞춥니다.
SDK 고유 동작의 범위: 아래의 API 상세 내용은 현재 SiFli SDK의 SF32LB52x를 기준으로 문서화된 것입니다. 대상 제품군과 SDK 릴리스의 audio_server.h, 구현, 구성과 대조하여 확인하십시오. 버퍼 크기 산정, 스케줄링, 캐시 관리에 관한 조언은 엔지니어링 지침이며, Audio Server가 모든 타깃에서 동일한 동작이나 버퍼 소유권을 보장하지는 않습니다.
세션 소유권¶
애플리케이션 정책과 스트리밍 메커니즘을 분리하십시오. 재생이나 녹음을 언제 시작하고, 정지하고, 상태를 바꿀지는 애플리케이션이 결정합니다. Audio Server는 세션을 조율하고, DMA는 샘플 블록을 이동하며, 드라이버는 하드웨어 구성을 소유합니다. 스트림이 활성 상태인 동안 UI, Bluetooth 콜백, 파일 시스템 읽기가 코덱 레지스터를 직접 조작하지 않도록 하십시오.
| 경계 | 소유자 | 검토 질문 |
|---|---|---|
| 소스 데이터 | 애플리케이션, 디코더 또는 스토리지 태스크 | 재생 큐가 비기 전에 계속 채워 줄 수 있습니까? |
| Audio Server 쓰기 캐시(구성한 경우) | Audio Server, 애플리케이션 구성으로 크기 지정 | write_cache_size가 이 SDK에서 유효하며, 애플리케이션이 모든 audio_write() 결과를 처리합니까? |
| 활성 전송 버퍼 | DMA/오디오 드라이버 | 전체 전송 동안 버퍼가 안정적이며 캐시 일관성이 유지됩니까? |
| 완료된 버퍼 | 애플리케이션 또는 처리 태스크 | DMA가 해당 영역을 재사용하기 전에 재생 데이터를 다시 채우거나 캡처된 데이터를 처리합니까? |
| 세션 상태 | Audio Server와 애플리케이션 정책 | 시작, 정지, 오류, 해제 요청이 반복되어도 리소스를 이중으로 닫거나 해제하지 않습니까? |
버퍼 전략 선택¶
드라이버가 지원하는 경우 더블 버퍼링이 실용적인 기준입니다. DMA가 한 영역을 전송하는 동안 소프트웨어는 다른 영역에서 재생 데이터를 준비하거나 캡처된 데이터를 처리합니다. 애플리케이션의 PCM 큐와 드라이버의 DMA 버퍼를 구분하십시오. Audio Server에 쓴다는 사실만으로 제로 카피 DMA 전송이 이루어진다고 볼 수는 없습니다.
스토리지 지연 시간, 디코딩 시간, Bluetooth 전송 지터, 스케줄링 변동 때문에 필요한 경우에만 큐 용량을 늘리십시오. 용량은 메모리를 소모하며, 대기 시간은 실제로 큐에 쌓인 오디오의 양으로 정해집니다. 버퍼를 더 많이 할당한다고 해서 지연 시간이 자동으로 늘어나는 것은 아닙니다. 채널 수와 샘플당 저장 바이트 수를 고려하여 오디오 개요의 프레임 기반 계산을 사용하십시오.
블록 지속 시간, 최악의 경우의 준비 또는 처리 시간, 허용 가능한 종단 간 지연 시간을 측정하십시오. 각 데드라인은 대상 드라이버의 버퍼 리필 및 전송 완료 통지와 버퍼 재사용 순서로부터 도출하십시오. 드라이버가 절반 전송(half-transfer)과 전체 전송(full-transfer) 콜백을 제공한다면 이 전환 시점을 기준으로 작업을 스케줄링하고, 현재 전송의 끝만을 유일한 데드라인으로 취급하지 마십시오. 재생 데이터는 DMA가 필요로 하기 전에 준비되어야 하고, 녹음된 데이터는 DMA가 덮어쓰기 전에 소비되거나 복사되어야 합니다. 스케줄링 여유를 두고, 가끔 발생하는 언더런이나 오버런도 조사하십시오.
애플리케이션이나 드라이버가 DMA에 직접 노출하는 메모리에는 대상의 캐시 및 소유권 규칙을 따르십시오. DMA가 읽기 전에 CPU가 쓴 재생 데이터를 clean하고, 필요에 따라 수신 버퍼를 준비하며, 대상이 요구하는 경우 CPU가 접근하기 전에 완료된 캡처 데이터를 invalidate하십시오. 이러한 단계는 SoC, 메모리 영역, 드라이버 API에 따라 달라집니다. 해당 API가 요구하지 않는 한 Audio Server나 드라이버가 소유한 버퍼를 수동으로 관리하지 마십시오. DMA가 소유한 영역은 절대 수정하거나 해제하거나 재사용하지 마십시오.
SF32LB52x Audio Server 문서는 콜백이 Audio Server 스레드에서 실행되며, audio_open() 콜백이 audio_close()를 호출하면 데드락이 발생할 수 있으므로 호출해서는 안 된다고 명시합니다. 콜백은 실행 시간이 한정되도록 유지하고, 블로킹이 발생하는 스토리지 또는 처리 작업은 워커로 넘기십시오. 캡처 콜백은 프레임의 포인터와 길이를 받지만, 인용한 문서에는 콜백 이후 해당 포인터가 얼마나 오래 유효한지 정의되어 있지 않습니다. 대상 SDK가 더 긴 수명을 명시적으로 문서화하지 않는 한, 반환하기 전에 데이터를 복사하십시오.
같은 SF32LB52x 문서는 다음과 같은 audio_write() 결과를 설명합니다.
| 반환값 | 문서화된 의미 |
|---|---|
> 0 |
값이 data_len과 같으며, 데이터가 쓰기 캐시에 수락되었습니다. |
0 |
쓰기 캐시가 가득 찼습니다. 구성된 캐시보다 큰 요청도 0으로 거부됩니다. |
-1 |
클라이언트가 일시 정지 또는 서스펜드된 상태이며, 제출된 오디오는 버려집니다. |
-2 |
잘못된 매개변수. |
해당 API에서 write_cache_size는 0x7FFF 바이트로 제한되며, 가이드는 핑퐁 쓰기 패턴을 위해 audio_write() 페이로드 하나 크기의 최소 두 배를 권장합니다. 이것은 Audio Server 소프트웨어 캐시이며, 드라이버의 물리적 DMA 버퍼 배치를 보장하는 것이 아닙니다. 이 제한을 적용하기 전에 정확한 대상 SDK를 확인하십시오. 클라이언트 우선순위, 믹싱, 사용 가능한 오디오 경로 역시 구성에 따라 달라집니다. 세션을 연다고 해서 칩의 모든 인터페이스가 Audio Server를 통해 노출되는 것은 아닙니다.
제품 부하에서 검증¶
제품에서 함께 동작하게 될 워크로드, 즉 디스플레이 갱신, Bluetooth 알림 또는 오디오, 스토리지 읽기/쓰기, 로깅, 저전력 전환과 함께 오디오 세션을 테스트하십시오. 재생 언더런, 녹음 오버런, 큐 점유율, 콜백에서 워커까지의 지연, 글리치, 재연결, 웨이크/슬립 전환을 로그로 남기십시오. 우선순위에 따른 중단, 서스펜드와 재개, 시작 실패, 반복되는 정지 요청을 시험하고, 데이터를 조용히 잃지 않고 의도한 복구 정책이 동작하는지 검증하십시오.
종료 시에는 드라이버가 전송을 중지했는지, 그리고 처리 중이던 콜백이 해제된 버퍼에 더 이상 접근할 수 없는지 확인하십시오. 오디오 관련 전원 요청과 외부 부품이 하드웨어 시퀀스에 따라 해제되었는지 점검하십시오. 시스템 전원 검증은 저전력 설계 개요를, 무선 공존은 Bluetooth 개요를 참고하십시오.
최종 업데이트: