KR20160013207A

KR20160013207A - 다수의 동시적 오디오 모드

Info

Publication number: KR20160013207A
Application number: KR1020157036942A
Authority: KR
Inventors: 프랭크 예레이스; 키쇼어 코터리; 리안 충
Original assignee: 마이크로소프트 테크놀로지 라이센싱, 엘엘씨
Priority date: 2013-05-29
Filing date: 2013-09-19
Publication date: 2016-02-03
Also published as: US20140358262A1; EP3005074A1; KR102033209B1; US9519708B2; CN105378646A; CN105378646B; WO2014193435A1

Abstract

본원에서 설명되는 실시형태는 상이한 오디오 스트림을 상이한 하드웨어 기반의 오디오 프로세싱 모드로 동시에 프로세싱하기 위한 디바이스 및 프로세스를 포함한다. 이러한 실시형태를 위한 컴퓨팅 디바이스는 병렬 실행이 가능한 다수의 하드웨어 오디오 신호 프로세싱 모드를 구비할 수도 있다. 운영체제 또는 그 오디오 스택은, 각각의 타입의 오디오 신호를 생성하는 오디오 소스에 대한 오디오 경로 또는 스트림을 관리할 수도 있다. 오디오 경로 또는 스트림 중 어떤 것이, 하드웨어 오디오 신호 프로세싱 모드 중 어떤 것과 연결될 것인지는, 오디오 신호의 타입에 따라 결정될 수도 있다. 제2 하드웨어 오디오 신호 프로세싱 모드가 제2 오디오 경로 또는 스트림의 제2 타입의 오디오 신호를 프로세싱하는 동안, 동시에, 제1 하드웨어 오디오 신호 프로세싱 모드는 제1 오디오 경로 또는 스트림의 제1 타입의 오디오 신호를 프로세싱하고 있을 수도 있다.

Description

다수의 동시적 오디오 모드{MULTIPLE CONCURRENT AUDIO MODES}

컴퓨팅 디바이스는 오디오 신호 프로세싱을 수행하기 위한 특수화된 오디오 하드웨어를 종종 구비한다. 통상적으로, 이러한 오디오 하드웨어는, 컴퓨팅 디바이스에 의해 캡쳐되고 있는 또는 생성되고 있는 오디오 신호에 대해 신호 프로세싱을 수행하는 하나 이상의 디지털 신호 프로세싱 칩 또는 알고리즘을 포함한다. 이러한 신호 프로세싱은 음악 신호를 향상시키는 것, VOIP(voice over Internet Protocol; 인터넷 전화) 신호에서 에코를 제거하는 것, 노이즈를 감소시키는 것, 반향을 시뮬레이팅하는 것 등등과 같은 특수 오디오 효과를 야기할 수도 있다. 몇몇 경우에서, 이러한 전용 오디오 하드웨어 또는 오디오 카드(종종 호스트 버스를 통해 연결됨)는 다양한 이러한 하드웨어 기반의 신호 프로세싱 모드 또는 효과를 제공할 수 있다.

이전에는, 컴퓨팅 디바이스는, 전용 오디오 신호 프로세싱 디바이스가 다수의 이러한 모드와 함께 구성되는 경우에도, 이러한 하드웨어 기반의 프로세싱 모드를 한 번에 하나보다 많이 사용할 수 없었다. (모든 오디오 경로 또는 스트림에 대해) 모든 오디오 프로세싱을 하나의 모드에서 다른 모드로 교대로 시프트함으로써 운영체제가 다수의 모드의 이용가능성을 일반적으로 핸들링할 것이다. 임의의 주어진 시간에, 컴퓨팅 디바이스에 의해 프로세싱되고 있는 모든 오디오는 동일한 하드웨어 기반의 오디오 신호 프로세싱 모드에 의해 프로세싱될 것이다.

이 방식은 본 발명가에 의해서만 인식된 단점을 갖는다. 가끔, 컴퓨팅 디바이스 상의 상이한 애플리케이션은 상이한 신호 프로세싱 선호도를 가질 수도 있다. 예를 들면, VOIP 애플리케이션은 자신의 입력에 에코 소거 프로세싱을 그리고 자신의 출력에 최소 프로세싱을 필요로 할 수도 있고, 한편, 동시에 음악을 렌더링하는 음악 플레이어는 렌더링된 음악을 향상시키기 위해 노이즈 감소 신호 프로세싱을 필요로 할 수도 있는데, 노이즈 감소 신호 프로세싱은 레이턴시를 도입할 가능성이 있다. 또한, 종래의 싱글 모드 방식은 오디오 하드웨어 리소스의 완전한 활용을 막았다. 오디오 하드웨어가 동시적 다중 모드 프로세싱이 가능한지의 여부에 무관하게, 이러한 하드웨어를 관리하는 운영체제는 이러한 성능을 이용하도록 디자인되지 않았다.

동시적 다중 모드 오디오 프로세싱을 제공하는 것에 연관이 있는 기술이 하기에서 논의된다.

하기의 개요는, 단지, 하기의 상세한 설명에서 논의되는 몇몇 개념을 도입하기 위해서 포함된다. 본 개요는 포괄적이지 않으며, 말미에 제공되는 특허청구범위에 의해 제시되는 청구된 주제의 범위를 묘사하지 않는다.

하기에서는, 첨부의 도면과 연계하여 고려되는 하기의 상세한 설명을 참조로, 수반하는 특징 중 많은 것이 설명될 것이다.

본 설명은 첨부의 도면의 관점에서 읽혀지는 하기의 상세한 설명으로부터 더 잘 이해될 것인데, 첨부의 도면에서는, 수반하는 설명에서 동일한 부분을 나타내기 위해 동일한 도면 부호가 사용된다.
도 1은 컴퓨팅 디바이스를 도시한다.
도 2는 오디오 하드웨어의 오디오 프로세싱 모드에 의해 동시에 프로세싱되는 오디오 스트림의 상세를 도시한다.
도 3은 오디오 스택 및 오디오 스택을 통해 오디오 데이터를 수신하는 애플리케이션을 도시한다.
도 4는 오디오 스택의 상세를 도시한다.
도 5는 상기에서 설명되는 실시형태가 구현될 수도 있는 컴퓨팅 디바이스의 예를 도시한다.

하기에서 논의되는 실시형태는, 상이한 오디오 스트림에 동시에 적용될 수 있는 다수의 오디오 모드를 제공하는 것에 관한 것이다. 오디오 신호 프로세싱 하드웨어와 함께 구성되는 컴퓨팅 디바이스의 개관으로 논의가 시작될 것이다. 다음에, 운영체제에 의해 구현되는 오디오 스트림 관리 방식이 논의될 것이다. 오디오 스트림 스택의 상세는 다음에 설명될 것이고, 후속하여 그로 인해 수행되는 프로세스의 논의가 설명될 것이다.

도 1은 컴퓨팅 디바이스(100)를 도시한다. 컴퓨팅 디바이스(100)는 오디오 하드웨어(102)를 구비한다. 통상적으로, 오디오 하드웨어(102)는, 시스템 버스를 통해 중앙 처리 유닛(central processing unit; CPU)과 연동하는 전용 칩 또는 주변장치 카드이다. 오디오 하드웨어(102)는, 하나 이상의 디지털 신호 프로세서로 구현될 수도 있는 다수의 오디오 신호 프로세싱 모드(또는 효과)를 제공한다. 각각의 모드는 상이한 오디오 신호 프로세싱 알고리즘을 구현한다. 다음에 언급되는 것은, 다양한 오디오 프로세싱 디바이스 상에서 존재할 수도 있는 이러한 모드의 예이다: 3D 오디오, 게이밍, 동적 이득 조정, 보이스, 주변, 에코 소거, 사운드 소스 로컬라이제이션 등등. 모드는 캡쳐된 오디오, 스피커 상에서 재생될 렌더링된 오디오, 또는 둘 모두에 대한 것일 수도 있다는 것을 유의한다. 또한, 모드는 반드시 신호를 변환할 필요는 없다. 몇몇 모드는, 신호에 관한 애플리케이션에 대한 정보를 생성하기 위해 신호 분석을 수행할 수도 있다. 모드는 또한, 포맷 변환, 예를 들면, 비트레이트, 샘플링 레이트, 채널 수, 또는 다른 신호 피쳐를 변환하는 것에 대한 것일 수도 있다.

컴퓨팅 디바이스(100) 상의 운영체제(104)는, 하나 이상의 애플리케이션(106)에 의한 오디오 하드웨어(102)에 대한 액세스 및 그 사용을, 어쩌면 디바이스 드라이버(도시되지 않음)의 사용과 함께, 제어한다. 특히 오디오 스택(audio stack)(108)(운영체제(104)의 오디오 기능)은, 오디오 하드웨어(102)를 이용하여 오디오 신호를 애플리케이션(106)으로/으로부터 링크하는 오디오 통로(pathway)(경로 또는 스트림으로도 칭해짐)를 관리할 수도 있다. 상이한 운영체제에 대해 구현 상세가 변경될 것이지만, 오디오 스트림은 소스와 목적지 사이에서의 디지털 오디오 신호의 플로우이다. 오디오 스트림의 방향에 따라, 소스 및 목적지는 애플리케이션(106), 마이크(110), 라우드스피커(112), 스토리지 등일 수도 있을 것이다. 운영체제(104)는, 애플리케이션(106)이, 오디오 스트림을 개시하는 것, 판독하는 것, 기록하는 것, 닫는 것(closing), 및 다르게는 관리하는 것과 같은 기능성(functionality)을 호출하는 것을 가능하게 하기 위한 애플리케이션 프로그래밍 인터페이스(application programming interface; API)를 제공할 수도 있다. 운영체제(104)는 다른 기능, 예컨대, 버퍼링, 오디오 통로에서의 컴포넌트 연결, 오디오 하드웨어(102)의 사용 및 오디오 하드웨어(102)에 대한 액세스를 제어하기 위한 오디오 디바이스 드라이버와의 상호작용, 등등을 투명하게 수행할 수도 있다.

도 2는 오디오 하드웨어(102)의 오디오 프로세싱 모드(120, 122, 124)에 의해 동시에 프로세싱되는 오디오 스트림(118)의 상세를 도시한다. 오디오 프로세싱 모드(120) 중 일부는, 호스트 컴퓨팅 디바이스(100)의 CPU 상에서 실행하는 소프트웨어 모듈로서 구현될 수도 있다. 애플리케이션(106)은 컴퓨팅 디바이스(106) 상에서 실행하는 임의의 소프트웨어 컴포넌트, 예를 들면, 유저 론칭 애플리케이션(user-launched application), 백그라운드 서비스, 관리된 코드 환경에서의 스레드(thread), 가상 머신 등등일 수 있다. 도 2의 예에서의 애플리케이션(106)은, 라우드스피커(112) 상에서의 출력을 위한 사운드를 렌더링하는 사운드 소스이다. 도 3을 참조로 하기에서 논의되는 바와 같이, 애플리케이션(106)은 또한, 사운드 싱크(sink); 오디오 스택(108)에 의해 핸들링되고 출력되는 오디오 신호 데이터의 수신측일 수 있다.

오디오 스트림을 형성하여 관리하는 것은 도 2 및 도 3에서 묘사되지 않은 복잡성을 수반할 수도 있다는 것이, 컴퓨팅 디바이스용 오디오 프로세싱 시스템의 기술분야의 숙련된 자에 의해 인식될 것이다. 예를 들면, 신호를 분할하기 위한 티(tee), 신호를 믹싱하기 위한 믹서, 유틸리티 신호 프로세싱 모듈(CPU 기반), 및 어쩌면 심지어 다수의 신호 프로세싱 모드(예를 들면, 소프트웨어 기반의 모드 및 하드웨어 기반의 모드)의 인스턴스는 다양한 방식으로 결합되어 오디오 데이터 플로우의 복잡한 그래프를 형성할 수도 있다. 이러한 구현 상세에 무관하게, 운영체제(104) 및/또는 그 오디오 스택(108)은, 오디오 신호 프로세싱 하드웨어(오디오 하드웨어(102))를 통한, 오디오 신호 데이터의 애플리케이션(106)으로/으로부터의, 그리고 몇몇 경우에서는 사운드 생성 디바이스 또는 사운드 캡쳐 디바이스(예를 들면, 라우드스피커(112), 마이크(110))로부터/로의 교환을 가능하게 하기 위한 데이터 통로를 제공한다.

동시적 다중 모드 오디오 신호 프로세싱을 용이하게 하기 위해, 오디오 스택(108)은 프로세스(126)와 같은 프로세스를 수행할 수도 있다. 애플리케이션(106)이, 예를 들면, 애플리케이션(106)에 의해 렌더링되는 사운드를 출력하기 위해, 오디오 스트림을 필요로 하는 경우, 애플리케이션(106)은, 아마도 오디오 API를 통해, 운영체제(104)로 호출(call) 또는 요청을 발행한다. 운영체제(104) 또는 오디오 스택(108)이 요청을 수신하면, 요청된 오디오 스트림에 대한 오디오 타입이 식별된다. 오디오 타입은 다양한 수단에 의해 확인될 수 있다. 예를 들면, 요청하는 애플리케이션(106)은 타입을 나타내는 정보를, 새로운 오디오 스트림을 요청하는 호출의 파라미터로서, 오디오 스트림에 태깅할 수 있다.

오디오 타입을 분류하고, 식별하고, 또는 결정하는 다른 수단이 사용될 수도 있다. 예를 들면, 애플리케이션은, 오디오 데이터에 또는 스트림 자체에 식별자를 임베딩함으로써 오디오 타입을 특정할 수 있다. 오디오 스택(108)은, 애플리케이션과 연관되는 오디오의 타입을 식별하는, 요청하는 애플리케이션(106)과 연관되는 메타데이터를 참조할 수 있다. 다른 실시형태에서, 애플리케이션이 사용한 오디오의 최종 타입(또는 애플리케이션에 의해 사용 중인 다른 스트림)은 새로운 오디오 스트림에 대한 오디오 타입을 결정하는 데 참조될 수도 있다. 또 다른 실시형태에서, 오디오 스택(108)은, 요청된 오디오 스트림을 오디오 타입을 모르는 상태로 셋업하고, 애플리케이션(106)으로부터 몇몇 오디오 신호 데이터를 수신하고, 애플리케이션으로부터 제공되는 오디오 신호 데이터를 버퍼링하고, 버퍼링된 오디오 데이터(사운드 데이터)를 분석하여 오디오 데이터에서의 사운드의 타입(예를 들면, 음악, 보이스 등등)을 결정할 수도 있다.

프로세스(126)로 돌아가서, 요청된 오디오 스트림의 오디오 타입이 결정되면, 새로운 오디오 스트림을 프로세싱하기 위한 적절한 모드가 오디오 신호 프로세싱 모드(120, 122, 124) 중에서 선택된다. 일 실시형태에서, 오디오 스택(108)은, 오디오 타입을 특정한 오디오 신호 프로세싱 모드(120, 122, 124)와 연관시키는 연관 정보를 유지한다. 다른 실시형태는 도 4를 참조로 나중에 논의된다.

오디오 신호 프로세싱 모드가 어떻게 선택되는지에 무관하게, 오디오 스택(108)은 새로운 오디오 스트림을 선택된 오디오 신호 프로세싱 모드와 링크하도록 진행한다. 예를 들면, 애플리케이션(106)이 "App1"이고, 오디오 신호 프로세싱 모드(120)가 "무비(movie)" 타입의 모드이면, 애플리케이션(106)에 의해 생성되는 오디오 데이터는 오디오 스트림을 통해 흐르고, 오디오 신호 프로세싱 모드(120)("무비")에 의해 프로세싱되고, 라우드스피커(112)에 의해 사운드로서 방출된다.

하나 이상의 오디오 스트림(118)이 오디오 신호 프로세싱 모드 중 하나 이상으로 오디오 데이터를 이미 전달하고 있는 동안, 애플리케이션(106)은 또 다른 오디오 스트림을 요청하여, 다시 프로세스(126)를 호출할 수도 있다. 새로운 오디오 스트림은 상기에서 논의된 것과 동일한 방식으로 구축되어 구성된다. 새로운 오디오 스트림이, 현재 사용 중이지 않은 오디오 신호 프로세싱 모드를 활용하는 경우, 그럼에도 불구하고, 요청된 오디오 스트림은 그 타입에 따라 구현될 수도 있다. 다시 말하면, 상이한 모드가 오디오 신호 데이터를 동시에 프로세싱할 수도 있다. 오디오 스트림 타입을 추적하고 오디오 스트림 타입 사이를 구별하는 운영체제(108) 및/또는 오디오 스택(104)의 능력은, 상이한 하드웨어 기반의 오디오 신호 프로세싱 모드에 의한 오디오 스트림의 동시적 프로세싱을 용이하게 한다.

또한 오디오 스트림에 관하여, 오디오 스트림의 타입 또는 카테고리는 제한되지 않는다; 오디오 스트림의 타입은 오디오 스트림의 임의의 특성 또는 피쳐에 대응할 수 있다. 예를 들면, 스트림 타입은 오디오 포맷 특성(trait)에 대응할 수 있다. 스트림은, 비트레이트, 오디오 컨텐츠를 인코딩하기 위해 사용되는 코덱 타입, 버퍼링 모드, 버퍼 사이즈, 데이터 블록 사이즈, 샘플링 레이트, 채널 수 등등과 같은 특징을 나타내도록 라벨링되거나 태깅될 수 있을 것이다. 애플리케이션 또는 그 오디오 스트림에 연관되는 다른 정보, 예컨대 오디오 컨텐츠에 대응하는 컨텐츠 생성기를 식별하는 정보, 오디오 컨텐츠를 생성하기 위해 사용되는 디바이스를 나타내는 정보, 데이터 정보, 등등도 또한 사용될 수도 있다.

일 실시형태에서, 오프로드(offload) 경로(126)가 포함될 수도 있다. 오프로드 경로(126)는, 애플리케이션에 의해 요청되면, 오디오 스택(108)의 신호 프로세싱의 거의 모두를 애플리케이션이 바이패스하는 것을 허용한다. 오프로드 모드는 미가공 모드(raw mode)와는 상이할 수도 있다. 오프로드 경로는 애플리케이션이 오디오 디바이스에 직접적으로 교신하는 것을 허용하여 운영체제를 바이패스한다. 오디오 디바이스는 하드웨어에서 모드 특정 프로세싱(mode specific processing)을 제공하거나, 또는 어떠한 프로세싱도 전혀 제공하지 않을(미가공(raw)) 수도 있다. 미가공 경로는, 그 경로 내에 신호 프로세싱을 갖지 않는 경로이다. 미가공 경로는 비오프로드(non-offload)일 수도 있거나(즉, 운영체제에 의해 구현될 수도 있거나, 또는 오프로드 경로로서 하드웨어에 의해 구현될 수도 있다(애플리케이션이 오디오 디바이스와 직접적으로 교신하는 경우, 오디오 디바이스는 임의의 모드 특정 프로세싱을 적용하지 않으면서 오디오를 렌더링한다). 주로, 미가공 경로에 존재하는 유일한 프로세싱은 강제 프로세싱(mandatory processing)이다. 미가공 프로세싱(raw processing)은, 애플리케이션이 렌더링/캡쳐하는 오디오 데이터가 운영체제 또는 하드웨어에 의해 구현되는 어떠한 비강제 신호 프로세싱도 거치지 않을 것이라는 것을 애플리케이션에게 보장한다.

상기에서 논의되는 바와 같이, 미가공 오디오 신호 프로세싱 모드(124)는, 어떠한 오디오 효과 또는 신호 프로세싱도 방지할 것을 그리고 대응하는 오디오 스트림이 미가공 신호로서 렌더링되는(또는 캡쳐되는) 것을 허용할 것을 애플리케이션에 의해 요청받을 수 있다. 하드웨어 보호 신호 프로세싱은, 오디오 하드웨어에 손상을 줄 수도 있는 신호 특성을 해결하기 위해, 미가공 모드(또는 다른 모드)를 사용할 때 투명하게 그리고 강제적으로 적용될 수도 있다. 오프로드 경로(126), 또는 모드 중 다른 것은, 소프트웨어 기반의 모드, 즉 호스트 CPU 상에서 실행하는 모드로서 구현될 수 있다.

디폴트 오디오 신호 프로세싱 모드(122)가 또한 포함될 수도 있다. 디폴트 오디오 신호 프로세싱 모드(122)는 임의의 신호 프로세싱 알고리즘을 구현할 수 있지만, 가벼운 또는 기본적인 신호 프로세싱만을 수행하는 것이 바람직하다. 디폴트 오디오 신호 프로세싱 모드(122)는 사용되고 있는 특정 오디오 하드웨어(102)에 대한 사운드를 최적화하도록 구현될 수도 있다. 대안적으로, 디폴트 오디오 신호 프로세싱 모드(122)는, 플랫폼에 걸쳐 신호 프로세싱 베이스라인을 제공하는 신호 프로세싱 표준을 구현할 수 있다. 디폴트 오디오 신호 프로세싱 모드(122)가 수행하는 프로세싱에 무관하게, 지정된 디폴트 모드가 존재한다는 사실은, 오디오 스트림의 타입이 발견되지 않을 때 시스템이 폴백(fallback)을 갖는 것을 허용하여 이용가능한 대응하는 모드를 갖게 하는데, 이것은 도 4를 참조로 논의될 것이다.

오프로드 경로(126) 외에, 몇몇 실시형태는, 애플리케이션에 의해 요청될 수 있는 루프백 경로(loopback path)(128)를 포함할 수도 있다. 루프백 경로(128)는 프로세스 이후에 애플리케이션이 오디오 데이터를, 아마도 라우드스피커(112)로 전달될 때 갖게 될 형태로, 직접적으로 수신하는 것을 허용한다. 다른 실시형태에서, 개개의 루프백은 각각의 오디오 프로세싱 모드에 대해 제공될 수도 있다. 루프백 경로(128)는 에코 소거 및 기본 사운드 캡쳐링과 같은 목적에 유용할 수 있다. 오디오 디바이스가 다수의 신호 프로세싱 모드를 구현하면, 오디오 디바이스는, 믹스 후 오디오를 다시 리턴하기 위한 루프백 경로를, 오디오를 요청한 임의의 애플리케이션에게 또한 제공하는 것을 필요로 할 수도 있을 것이다는 것을 유의한다.

도 3은 애플리케이션(106)이 오디오 스택(108)을 통해 오디오 데이터를 수신하고 있을 때의 오디오 스택(108)을 도시한다. 도 2의 논의가 도 3에 동등하게 적용가능하다. 실제, 하나 이상의 애플리케이션(106)은 오디오 스트림(118)을 통해 오디오 데이터를 수신하면서 소싱(sourcing)하고 있을 수도 있다. 애플리케이션(106)은 유입하는(incoming) 그리고 유출하는(outgoing) 오디오 스트림 둘 모두를 가질 수도 있다.

동일한 주어진 오디오 신호 프로세싱 모드를 통과할 오디오 스트림을, 다수의 사운드 출력 애플리케이션이 요청하는 경우, 오디오 스택(108)은, 그들의 오디오 스트림을 주어진 오디오 신호 프로세싱 모드를 통과하는 신호 프로세싱 경로로 전달하기 이전에, 그들의 오디오 스트림을 하나의 서브믹스로 함께 혼합할 수도 있는데, 이것은 하나의 오디오 파이프라인이 다수의 애플리케이션을 지원하는 것을 허용한다. 마찬가지로, 여러 애플리케이션이 동일한 모드를 통해 오디오를 수신하고 있을 때, 오디오 스트림은 프로세싱되기 이전에 분할될 수도 있고, 그 다음 오디오 스트림은 분할되어 애플리케이션으로 전달된다.

도 4는 오디오 스택(108)의 상세를 도시한다. 몇몇 실시형태에서, 오디오 스택(108)은 커널 모드 또는 유저 모드 또는 이들의 조합에서 실행될 수도 있다. 애플리케이션이 오디오 스택(108)의 기능성에 액세스하는 것을 허용하기 위해, API(140)가 제공된다. API(140)를 통해 제공되는 메쏘드 또는 호출은 통상적인 운영체제 데이터 스트림 또는 파일 호출 예컨대 판독, 기록, 열기, 닫기, 복사 등을 포함할 수도 있다. 또한, API(140)는, 이용가능한 오디오 신호 프로세싱 모드 또는 오디오 타입을 애플리케이션이 발견하거나 또는 열거하는 것을 허용하는 호출을 구비할 수도 있다. 오디오 스트림의 타입을 특정하기 위한 별개의 호출이 존재할 수도 있는데, 이것은 스트림을 셋업할 때 호출될 수도 있거나 또는 스트림의 오디오 타입을 변경하기 위해 호출가능할 수도 있을 것이다. 오디오 타입은 스트림 열기 호출(stream-open call)의 파라미터로서 또한 명시될 수도 있다. 오디오 스택(108)은, 상기 언급된 기능뿐만 아니라 상기에서 논의되는 다른 기능성을 핸들링하는 로직 또는 오디오 경로 모듈(142)을 구비할 수도 있다.

이러한 열거는 오디오 신호 프로세싱 모드에 관한 상태 정보, 예컨대 모드가 사용되고 있는지의 여부, 모드가 어떤 부하를 받고 있는지 또는 어떤 데이터 레이트가 프로세싱되고 있는지 등을 또한 제공할 수도 있다.

이것은 애플리케이션이, 유사한 오디오 타입 또는 모드의 선택이 주어지면, 낮은 부하를 갖는 타입 또는 모드를 명시하는 것을 허용할 수도 있다.

오디오 경로 모듈(142)은 오디오 타입을 오디오 프로세싱 모드와 매칭시키기 위한 로직을 또한 핸들링할 수도 있다. 일 구현예는, 오디오 타입을 오디오 모드에 매핑하는 테이블(144)을 사용할 수도 있다. 각각의 오디오 타입은 우선순위에 의해 순서가 정해지는 대응하는 오디오 신호 프로세싱 모드의 리스트를 갖는다. 오디오 스트림이 특정한 오디오 타입, 예컨대 "타입1"을 갖는다는 것을 오디오 스택(108)이 결정하면, 오디오 경로 모듈(142)은 테이블(144)에서 오디오 타입을 찾고, 이용가능한 또는 동작가능한 제1 모드를 리스트로부터 선택한다. 오디오 타입이 "타입1"이면 "모드2"가 선택되거나, 또는 "모드2"가 이용가능하지 않으면 "모드1"이 선택된다. 스트림 고유의 모드가 이용가능하지 않거나 또는 결정불가할 때 디폴트 모드가 자동적으로 선택되는 실시형태에서는, "디폴트" 모드의 포함은 생략될 수도 있다. 일 실시형태에서, 테이블(144) 또는 다른 매핑 정보가 사용되지 않고, 대신, 오디오 타입과 오디오 신호 프로세싱 모드 사이에 구별이 존재하지 않고, 모드 또는 타입은 1 대 1 기반으로 직접적으로 사용된다. 다시 말하면, 스트림 및 모드 모두는 동일한 카테고리 또는 타입을 갖는다. 예를 들면, 오디오 스택(108)은 각각의 오디오 신호 프로세싱 모드에게 가장 가깝게 결정된 오디오 타입을 할당할 수도 있고, 애플리케이션은 모드/타입을 직접적으로 특정한다.

도 5는 상기에서 설명되는 실시형태가 구현될 수도 있는 컴퓨팅 디바이스(100)의 예를 도시한다. 컴퓨팅 디바이스(100)는 디스플레이(166)뿐만 아니라, 스토리지 디바이스(162) 및 프로세서(164)를 구비할 수도 있다. 이들 엘리먼트는 컴퓨팅의 기술분야에서 충분히 이해되는 방식으로 협력할 수도 있다. 또한, 입력 디바이스(168)는 컴퓨팅 디바이스(100)와 통합될 수도 있거나 또는 통신할 수도 있다. 디스플레이(106)는, 입력 디바이스로서 또한 기능할 수 있는 터치 감응식 디스플레이일 수도 있다. 컴퓨팅 디바이스(100)는 임의의 폼팩터(form factor)를 가질 수도 있거나 임의의 타입의 포괄적인 디바이스에서 사용될 수도 있다. 예를 들면, 어플라이언스(appliance), 로봇, 및 다른 머신을 제어하기 위해, 터치 감응식 제어 패널이 종종 사용된다. 컴퓨팅 디바이스(100)는, 스마트폰, 태블릿 컴퓨터, 게임용 디바이스, 헤드리스 서버(headless server) 등등과 같은 핸드헬드 디바이스의 형태일 수도 있다.

상기에서 논의되는 실시형태 및 특징은, 휘발성 또는 불휘발성 컴퓨터 또는 디바이스 판독가능 디바이스에 저장되는 정보의 형태로 실현될 수 있다. 이것은, 적어도, 디바이스 예컨대 광학 스토리지(예를 들면, 컴팩트 디스크 ROM(compact-disk read-only memory; CD-ROM), 자기 매체, 플래시, ROM, 또는 디지털 정보를 저장하기 위한 디바이스를 포함하는 것으로 간주된다. 저장된 정보는, 머신 실행가능 명령(예를 들면, 컴파일된 실행가능 2진 코드), 소스 코드, 바이트코드, 또는 상기에서 논의되는 다양한 실시형태를 컴퓨팅 디바이스가 수행하는 것을 가능하게 하기 위해 또는 상기에서 논의되는 다양한 실시형태를 수행하도록 컴퓨팅 디바이스를 구성하기 위해 사용될 수 있는 임의의 다른 정보의 형태일 수 있다. 이것은 또한, 적어도, 휘발성 메모리 예컨대 RAM(random-access memory) 및/또는 정보 예컨대 실시형태를 실행하는 프로그램의 실행 동안 중앙 처리 유닛(CPU) 명령을 저장하는 가상 메모리뿐만 아니라, 프로그램 또는 실행파일(executable)이 로딩되어 실행되는 것을 허용하는 정보를 저장하는 불휘발성 디바이스를 포함하는 것으로 간주된다. 실시형태 및 특징은, 휴대형 디바이스, 워크스테이션, 서버, 모바일 무선 디바이스 등등을 포함하는 임의의 타입의 컴퓨팅 디바이스 상에서 수행될 수 있다.

상기에서 논의되는 실시형태 및 특징은, 휘발성 또는 불휘발성 컴퓨터 또는 디바이스 판독가능 디바이스에 저장되는 정보의 형태로 실현될 수 있다. 이것은, 적어도, 디바이스 예컨대 광학 스토리지(예를 들면, CD-ROM), 자기 매체, 플래시, ROM, 또는 디지털 정보를 물리적 물질(physical matter)로 저장하기 위한 임의의 다른 디바이스를 포함하는 것으로 간주된다. 저장된 정보는, 머신 실행가능 명령(예를 들면, 컴파일된 실행가능 2진 코드), 소스 코드, 바이트코드, 또는 상기에서 논의되는 다양한 실시형태를 컴퓨팅 디바이스가 수행하는 것을 가능하게 하기 위해 또는 상기에서 논의되는 다양한 실시형태를 수행하도록 컴퓨팅 디바이스를 구성하기 위해 사용될 수 있는 임의의 다른 정보의 형태일 수 있다. 이것은 또한, 적어도, 휘발성 메모리 예컨대 RAM 및/또는 정보 예컨대 실시형태를 실행하는 프로그램의 실행 동안 중앙 처리 유닛(CPU) 명령을 저장하는 가상 메모리뿐만 아니라, 프로그램 또는 실행파일이 로딩되어 실행되는 것을 허용하는 정보를 저장하는 불휘발성 매체를 포함하는 것으로 간주된다. 실시형태 및 특징은, 휴대형 디바이스, 워크스테이션, 서버, 모바일 무선 디바이스 등등을 포함하는 임의의 타입의 컴퓨팅 디바이스 상에서 수행될 수 있다.

Claims

컴퓨팅 디바이스에서 오디오 데이터를 관리하는 방법에 있어서,
상기 컴퓨팅 디바이스는 프로세서 칩, 스토리지, 및 오디오 프로세서 칩을 포함하고, 상기 오디오 프로세서 칩은 복수의 신호 프로세싱 모드를 제공하고, 각각의 신호 프로세싱 모드는 상이한 타입의 오디오 신호 프로세싱을 포함하고, 상기 방법은 상기 컴퓨팅 디바이스의 운영체제 및/또는 커널 모드 컴포넌트에 의해 수행되며, 상기 방법은,
상기 오디오 프로세서 칩과 상기 컴퓨팅 디바이스 상에서 실행되는 애플리케이션 사이에서 통과되는 오디오 스트림을 제공하고 관리하는 단계;
상기 오디오 스트림을 개시하기 위한 요청 - 각각의 요청은 상기 오디오 스트림을 요청한 대응하는 상기 애플리케이션에 의해 표시되는 각각의 오디오 타입과 연관됨 - 을 상기 애플리케이션으로부터 수신하는 단계; 및
애플리케이션으로부터 요청이 수신될 때마다, 상기 오디오 스트림에 대해 상기 신호 프로세싱 모드 중 하나를 선택함으로써, 대응하는 오디오 스트림을 개시하는 단계
를 포함하고,
상기 신호 프로세싱 모드는 상기 요청의 오디오 타입에 따라 선택되는 것인, 컴퓨팅 디바이스에서 오디오 데이터를 관리하는 방법.
제1항에 있어서,
어떤 오디오 타입이 어떤 신호 프로세싱 모드와 연관되는지를 표시하는 매핑 정보를 유지하는 단계, 및
상기 오디오 스트림이 개시될 때, 상기 오디오 스트림을 상기 신호 프로세싱 모드에 링크시키기 위해 상기 매핑 정보를 사용하는 단계
를 더 포함하는, 컴퓨팅 디바이스에서 오디오 데이터를 관리하는 방법.
제1항에 있어서,
상기 신호 프로세싱 모드는 각각의 애플리케이션의 상기 오디오 스트림의 오디오 신호 데이터를 동시에 프로세싱하는 것인, 컴퓨팅 디바이스에서 오디오 데이터를 관리하는 방법.
제1항에 있어서,
상기 애플리케이션은 각각의 제1 오디오 스트림을 통한 오디오를 프로세싱하는 제1 애플리케이션 및 각각의 제2 오디오 스트림을 통한 오디오를 프로세싱하는 제2 애플리케이션을 포함하고, 상기 제1 오디오 스트림은 제1 오디오 타입을 갖고, 상기 제2 오디오 스트림은 제2 오디오 타입을 갖고,
상기 방법은,
상기 제2 오디오 스트림을 상기 신호 프로세싱 모드 중 제2 신호 프로세싱 모드로 동시에 프로세싱하는 동안, 상기 제1 오디오 스트림을 상기 신호 프로세싱 모드 중 제1 신호 프로세싱 모드로 동시에 프로세싱하는 단계
를 더 포함하는, 컴퓨팅 디바이스에서 오디오 데이터를 관리하는 방법.
제1항에 있어서,
상기 방법은, 상기 오디오 프로세싱 칩이 두 개의 상이한 애플리케이션에 대한 두 개의 상이한 타입의 신호 프로세싱을 동시에 수행하는 것을 가능하게 하는 것인, 컴퓨팅 디바이스에서 오디오 데이터를 관리하는 방법.
제1항에 있어서,
애플리케이션에 의한 요청시, 상기 오디오 프로세싱 칩에 의해 실질적으로 어떠한 오디오 신호 프로세싱도 대응하는 오디오 스트림에 적용되지 않게 하는 미가공(raw) 신호 프로세싱 모드를 제공하는 단계
를 더 포함하는, 컴퓨팅 디바이스에서 오디오 데이터를 관리하는 방법.
컴퓨팅 디바이스에 있어서,
복수의 하드웨어 기반 타입의 오디오 신호 프로세싱을 포함하는 오디오 신호 프로세싱 디바이스; 및
애플리케이션을 실행하며 상기 애플리케이션에 대한 오디오 스트림을 제공하는 프로세서
를 포함하고,
상기 프로세서는 상기 오디오 스트림을 상기 하드웨어 기반 타입의 신호 프로세싱 중 대응하는 하드웨어 기반 타입과 매칭시킴으로써 상기 하드웨어 기반 타입의 오디오 신호 프로세싱에 의한 동시적 프로세싱을 가능하게 하고,
상기 하드웨어 기반 타입의 오디오 신호 프로세싱은 상기 오디오 스트림을 동시에 프로세싱하는 것인, 컴퓨팅 디바이스.
제7항에 있어서,
상기 애플리케이션은, 상기 오디오 스트림과 상기 하드웨어 기반 타입의 오디오 신호 프로세싱과의 매칭을 허용하기 위해, 각각의 상기 오디오 스트림을 태깅(tagging)하는 것인, 컴퓨팅 디바이스.
제8항에 있어서,
동일한 오디오 타입으로 태깅된 오디오 스트림은 혼합 신호를 형성하기 위해 혼합되고, 상기 혼합 신호는 상기 동일한 오디오 타입에 대응하는 상기 하드웨어 기반 타입의 오디오 신호 프로세싱으로 통과되는 것인, 컴퓨팅 디바이스.
제9항에 있어서,
오디오 스트림이 미가공(raw) 타입이라는 것을 상기 프로세서가 결정하는 경우, 상기 오디오 스트림은 어떠한 하드웨어 기반의 오디오 신호 프로세싱도 통과하지 않는 것인, 컴퓨팅 디바이스.