하드웨어 오프로드 오디오 처리

하드웨어 오프로드 오디오 처리를 사용하면 컴퓨터의 기본 CPU 외부에서 기본 오디오 처리 작업을 수행할 수 있습니다.

오디오 처리는 계산 집약적일 수 있습니다. 따라서 많은 시나리오에서 전용 프로세서가 혼합 및 효과 적용과 같은 처리 작업을 처리하도록 허용하는 것이 도움이 될 수 있습니다.

오프로드된 오디오용 드라이버를 구현할 때 오프로드된 오디오 스트림을 처리하고 Windows 오디오 시스템에 해당 기능을 노출할 수 있는 드라이버를 개발합니다.

이 섹션의 다음 topics 드라이버 개발, 애플리케이션 영향 및 오프로드된 오디오 스트림을 처리하기 위해 하드웨어 오디오 엔진을 구현하는 오디오 어댑터용 오디오 드라이버를 개발할 때 알아야 할 기타 문제에 대해 설명합니다.

하드웨어 오프로드된 오디오 드라이버 구현

오프로드된 오디오 처리를 위한 도우미 인터페이스

오프로드된 오디오에 대한 결함 보고

오프로드된 APO에 대한 자세한 내용은 하드웨어 오프로드된 APO 효과를 참조하세요.

Hardware-Offloaded 오디오 처리 아키텍처 개요

소프트웨어 오디오 엔진

다음 다이어그램은 Windows 소프트웨어 오디오 엔진을 보여 줍니다.

애플리케이션이 SFX, MFX 및 EFX 효과로 호출되어 드라이버 및 오디오 하드웨어에 연결하는 오디오 드라이버 아키텍처를 보여 주는 다이어그램

오디오 스트림은 WASAPI(Windows 오디오 세션 API) 계층에서 Media Foundation과 같은 상위 수준 API를 통해 소프트웨어 오디오 엔진에 도착합니다. SFX(소프트웨어 오디오 엔진 스트림 효과)에서는 별도의 스트림이 혼합되기 전에 스트림 단위로 적용한 다음, EFX(사용 가능한 엔드포인트 효과)를 통과하여 렌더링 하드웨어 및 스피커로 전송할 수 있습니다.

하드웨어 오디오 엔진

하드웨어 오디오 엔진은 오디오 어댑터에서 구현되며 주로 소프트웨어 오디오 엔진의 기능을 미러링합니다. Windows는 하드웨어 오프로드 오디오 처리를 지원하지만 지정된 오디오 어댑터의 오디오 드라이버는 다음 다이어그램에 표시된 토폴로지를 사용하여 오디오 하드웨어의 기본 기능을 노출해야 합니다.

하드웨어 오디오 엔진은 단일 호스트 프로세스 스트림과 최대 n개의 오프로드된 스트림을 허용해야 합니다. 이러한 오프로드된 스트림은 애플리케이션 계층에서 직접 라우팅되어 하드웨어에서 처리됩니다. 즉, 오프로드된 스트림은 소프트웨어 오디오 엔진을 통해 전달되지 않습니다. 다이어그램은 최대 3개의 오프로드된 스트림을 처리하도록 설계된 구현을 보여 줍니다. 호스트 프로세스 스트림은 소프트웨어 오디오 엔진에서 처리된 모든 스트림의 소프트웨어 믹서에서 최종 출력됩니다. 각 하드웨어 오디오 엔진에는 하드웨어 믹서도 포함되어야 합니다.

소프트웨어 오디오 엔진 및 WASAPI 인터페이스와의 패리티를 유지하려면 하드웨어 오디오 엔진이 루프백 스트림의 형태로 오디오 스택에 최종 오디오 출력 스트림을 다시 제공해야 합니다. 이는 에코를 취소하고 피드백을 방지하기 위해 최종 출력 스트림에 대한 지식이 필요한 Acoustic Echo Cancellation을 사용하는 애플리케이션 및 시나리오에 특히 중요합니다.

루프백 스트림에 대한 경로를 구현하기 위해 오디오 드라이버는 루프백 핀을 노출해야 합니다. 데이터가 PCM 형식으로 인코딩된 경우 이 핀은 최종 오디오 엔진 출력에서 오디오 데이터를 반환합니다. 그렇지 않으면 후 혼합(하지만 사전 인코딩) 결과가 반환됩니다. 즉, PCM이 아닌 형식으로 인코딩하는 하드웨어 EFX로 처리되는 오디오 데이터의 경우 루프백 스트림은 하드웨어 믹서 바로 뒤 하드웨어 오디오 엔진의 EFX 단계 전에 수행됩니다. 하드웨어 오디오 엔진을 나타내는 KS 필터 토폴로지에 대한 자세한 내용은 하드웨어 오프로드 오디오 드라이버 구현을 참조하세요.

통합 오디오 아키텍처

다음 다이어그램에서는 하드웨어 오디오 엔진이 Windows 소프트웨어 오디오 엔진에서 작동하는 경우의 결과 아키텍처에 대한 개요를 보여 줍니다.

애플리케이션이 SFX, MFX 및 EFX 효과로 호출되어 드라이버, 오디오 하드웨어 및 WASAPI 계층으로 다시 이어지는 루프백 스트림에 연결하는 통합 소프트웨어 및 하드웨어 오디오 엔진의 다이어그램

오디오 드라이버가 오프로드된 오디오 처리에 대한 지원을 표시한 시나리오에서 초기화된 첫 번째 n(이 경우 3개) 스트림은 WASAPI 계층에서 하드웨어 오디오 엔진으로 직접 라우팅되어 소프트웨어 오디오 엔진을 우회합니다. 하드웨어 오디오 엔진에서 지원하는 n에 이어 새로운 오디오 스트림은 처리를 위해 소프트웨어 오디오 엔진을 통해 라우팅됩니다. 그러면 소프트웨어 오디오 엔진의 결과 스트림이 호스트 프로세스 스트림으로 하드웨어 오디오 엔진으로 전송됩니다. 호스트 프로세스 스트림은 첫 번째 n 스트림과 혼합되고, EFX 처리가 적용되고, 결과 스트림이 스피커로 전송됩니다.

KS 필터 토폴로지

Windows 8 이상 운영 체제에서는 온보드 하드웨어 오디오 엔진이 오디오 스트림을 처리할 수 있도록 지원이 제공되었습니다. 이러한 오디오 어댑터를 개발할 때 연결된 오디오 드라이버는 오디오 시스템이 이 어댑터와 해당 드라이버의 기능을 검색, 사용 및 적절하게 노출할 수 있도록 특정 방식으로 사용자 모드 오디오 시스템에 이 사실을 노출해야 합니다.

오디오 드라이버가 이러한 새로운 오디오 어댑터의 하드웨어 기능을 노출할 수 있도록 하기 위해 Windows 8 드라이버에서 사용해야 하는 KS 필터 토폴로지를 도입했습니다.

호스트 프로세스 입력 핀, 오프로드된 오디오 입력 핀 및 루프백 출력 핀이 있는 KS 필터 토폴로지 다이어그램 오프로드된 오디오 및 호스트 프로세스 핀, 최종 처리 단계의 루프백 경로 및 ks 필터 토폴로지에서 DAC를 통해 두 개의 스트림에 적용된 오디오 처리입니다.

앞의 그림과 같이 KS 필터 토폴로지 는 하드웨어를 통한 데이터 경로를 나타내며 해당 경로에서 사용할 수 있는 함수도 보여 줍니다. 오프로드된 오디오를 처리할 수 있는 오디오 어댑터의 경우 KS 필터에 다음과 같은 입력 및 출력(핀이라고 함)이 있습니다.

  • 하나의 호스트 프로세스 핀. 이는 소프트웨어 오디오 엔진에서 KS 필터에 대한 입력을 나타냅니다.

  • 루프백 핀 1개. 이는 하드웨어 오디오 엔진에서 WASAPI(Windows 오디오 세션 API) 계층으로의 출력을 나타냅니다.

  • 오프로드된 오디오 핀의 수입니다. 그림에는 이 유형의 핀이 하나만 표시되지만 IHV는 임의의 수(n)의 핀을 자유롭게 구현할 수 있습니다.

오디오 어댑터 및 해당 드라이버의 검색으로 "연결"되는 사용자 모드 오디오 시스템의 실제 서비스는 AudioEndpointBuilder입니다. AudioEndpointBuilder 서비스는 디바이스 인터페이스 도착 및 제거에 대한 KSCATEGORY_AUDIO 클래스를 모니터링합니다. 오디오 디바이스 드라이버가 KSCATEGORY_AUDIO 디바이스 인터페이스 클래스의 새 instance 등록하면 디바이스 인터페이스 도착 알림이 발생합니다. AudioEndpointBuilder 서비스는 디바이스 인터페이스 도착 알림을 검색하고 알고리즘을 사용하여 시스템에서 오디오 디바이스의 토폴로지를 검사하여 적절한 작업을 수행할 수 있도록 합니다.

오프로드된 오디오를 처리할 수 있는 어댑터를 지원하도록 오디오 드라이버를 개발하는 경우 드라이버는 KSNODETYPE_AUDIO_ENGINE 오디오 엔드포인트를 사용하여 하드웨어 오디오 엔진의 기능을 노출해야 합니다. 오디오 엔드포인트 검색 프로세스에 대한 자세한 내용은 오디오 엔드포인트 작성기 알고리즘을 참조하세요.

사용자 인터페이스 고려 사항

오프로드된 오디오를 처리할 수 있는 오디오 어댑터의 기본 하드웨어 기능을 제어하는 오디오 드라이버를 개발했습니다. 즉, 드라이버는 어댑터의 기능을 제어하는 방법에 대한 최상의 지식을 갖추고 있습니다. 따라서 어댑터의 기능을 선택, 사용 및/또는 사용하지 않도록 설정할 수 있는 옵션 형식으로 최종 사용자에게 노출하는 UI를 개발해야 합니다.

그러나 개발한 API(오디오 처리 개체)를 제어하는 데 사용되는 UI가 이미 있는 경우 새 오디오 어댑터에서 작동하도록 이 UI를 확장할 수 있습니다. 이 경우 UI에 대한 확장은 API에 대한 소프트웨어 제어와 어댑터에 대한 하드웨어 제어를 제공합니다.

애플리케이션 영향

이 새로운 유형의 오디오 어댑터 및 관련 드라이버에 대해 설명된 기능은 WASAPI, Media Foundation, Media Engine 또는 HTML 5 <오디오> 태그를 통해 UWP 앱에서 사용할 수 있습니다. Wave 및 DSound는 UWP 앱에서 사용할 수 없으므로 사용할 수 없습니다. 또한 데스크톱 애플리케이션은 하드웨어 오프로드 오디오를 지원하는 오디오 어댑터의 오프로드 기능을 사용할 수 없습니다. 이러한 애플리케이션은 여전히 오디오를 렌더링할 수 있지만 소프트웨어 오디오 엔진을 사용하는 호스트 핀을 통해서만 렌더링할 수 있습니다.

UWP 앱이 미디어 콘텐츠를 스트리밍하고 Media Foundation, Media Engine 또는 HTML 5 <오디오> 태그를 사용하는 경우 적절한 오디오 범주가 스트림에 대해 설정된 한 앱은 하드웨어 오프로드에 대해 자동으로 옵트인됩니다. 하드웨어 오프로드에 대한 옵트인은 스트림별로 수행됩니다.

WASAPI 또는 스트리밍 통신을 사용하는 UWP 앱은 하드웨어 오프로드를 명시적으로 옵트인해야 합니다.

하드웨어 오프로드된 오디오 드라이버 구현

Windows 오디오 처리 개체