[펌]Advanced Audio support for the BlueZ stack

블루투스 오디오 관련 자료를 검색 중 찾음
( 주소 :  http://www.holtmann.org/linux/bluetooth/audio.html )



1. Introduction

The Advanced Audio Distribution Profile (A2DP) is a specification for transfering high quality audio over Bluetooth. Instead of SCO links that are used for telephony applications this specification uses the ACL link as transport. On the lower level the Audio/Video Distribution Transport Protocol (AVDTP) is used for any kind of audio or video streams.

The A2DP defines the low-complexity, subband codec (SBC) as the mandatory codec for all A2DP compatible devices.

2. Toshiba SR-1 information

The Toshiba SR-1 headphone was the first A2DP capable device on the market, but it didn't get widespreaded to the USA or Europe.

# hcitool inq Inquiring ... 08:00:46:A4:C5:C3 clock offset: 0x6d47 class: 0x200404 # hcitool info 08:00:46:A4:C5:C3 Requesting information ... BD Address: 08:00:46:A4:C5:C3 Device Name: SR-1_1.00 LMP Version: 1.1 (0x1) LMP Subversion: 0x20d Manufacturer: Cambridge Silicon Radio (10) Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00 <3-slot packets> <5-slot packets> <encryption> <slot offset> <timing accuracy> <role switch> <hold mode> <sniff mode> <park state> <RSSI> <channel quality> <SCO link> <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD> <paging scheme> <power control> <transparent SCO>

Besides the mandatory support for the audio sink with the SBC codec it also support another audio sink and an audio source with a non-A2DP codec. This might be used by the voice-regocnition feature of these headphone. The interesting part is the support for content protection and the non-default bitpool range.

< ACL data: handle 0x0028 flags 0x02 dlen 6 L2CAP(d): cid 0x0040 len 2 [psm 25] AVDTP(s): Discover cmd: transaction 0 > ACL data: handle 0x0028 flags 0x02 dlen 12 L2CAP(d): cid 0x0041 len 8 [psm 25] AVDTP(s): Discover rsp: transaction 0 ACP SEID 1 - Audio Sink ACP SEID 3 - Audio Sink ACP SEID 4 - Audio Source < ACL data: handle 0x0028 flags 0x02 dlen 7 L2CAP(d): cid 0x0040 len 3 [psm 25] AVDTP(s): Capabilities cmd: transaction 1 ACP SEID 1 > ACL data: handle 0x0028 flags 0x02 dlen 20 L2CAP(d): cid 0x0041 len 16 [psm 25] AVDTP(s): Capabilities rsp: transaction 1 Media Transport Media Codec - SBC 44.1kHz 48kHz Mono DualChannel Stereo JointStereo 4 8 12 16 Blocks 4 8 Subbands SNR Loudness Bitpool Range 4-64 Content Protection 02 00 < ACL data: handle 0x0028 flags 0x02 dlen 7 L2CAP(d): cid 0x0040 len 3 [psm 25] AVDTP(s): Capabilities cmd: transaction 2 ACP SEID 3 > ACL data: handle 0x0028 flags 0x02 dlen 19 L2CAP(d): cid 0x0041 len 15 [psm 25] AVDTP(s): Capabilities rsp: transaction 2 Media Transport Media Codec - non-A2DP 04 00 01 00 01 00 FC < ACL data: handle 0x0028 flags 0x02 dlen 7 L2CAP(d): cid 0x0040 len 3 [psm 25] AVDTP(s): Capabilities cmd: transaction 3 ACP SEID 4 > ACL data: handle 0x0028 flags 0x02 dlen 19 L2CAP(d): cid 0x0041 len 15 [psm 25] AVDTP(s): Capabilities rsp: transaction 3 Media Transport Media Codec - non-A2DP 04 00 01 00 01 00 FC

Besides this A2DP related support the SDP database of these headphone contains also a record for the headset profile on RFCOMM channel 1 and the audio/video remote control (AVCTP) feature on PSM 23. They also support an unique identifier with an UUID-128 service class saying that it is a TOSHIBA SR-1.

Playing with the Toshiba Bluetooth stack this is getting more weird. To identify the A2DP service on their headphone they don't use the A2DP sevice record. They look for a special UUID-128 and then display this service as Speech Recognizer SR-1.

> ACL data: handle 0x002a flags 0x02 dlen 31 L2CAP(d): cid 0x0040 len 27 [psm 1] SDP SS Req: tid 0xda01 len 0x16 pat uuid-128 bc199c24-958b-4cc0-a2cb-fd8a30bf3206 max 0xffff cont 00 < ACL data: handle 0x002a flags 0x02 dlen 18 L2CAP(d): cid 0x0057 len 14 [psm 1] SDP SS Rsp: tid 0xda01 len 0x9 tot 0x1 cur 0x1 hndl 0x10000 cont 00 > ACL data: handle 0x002a flags 0x02 dlen 23 L2CAP(d): cid 0x0040 len 19 [psm 1] SDP SA Req: tid 0xf501 len 0xe hndl 0x10000 max 0xffe7 aid(s) 0x0000 - 0xffff cont 00 < ACL data: handle 0x002a flags 0x02 dlen 61 L2CAP(d): cid 0x0057 len 57 [psm 1] SDP SA Rsp: tid 0xf501 len 0x34 cnt 0x31 aid 0x0000 (SrvRecHndl) uint 0x10000 aid 0x0001 (SrvClassIDList) < uuid-128 bc199c24-958b-4cc0-a2cb-fd8a30bf3206 > aid 0x0100 (SrvName) str "TOSHIBA SR-1" cont 00

But their first connection is not to PSM 25 for the AVDTP. They connect to PSM 0x8001 and use a special protocol. A headphone emulation must answer with a specifc sequence of bytes. These values are acknowledged and the stack requests the PIN code after that.

> ACL data: handle 0x002a flags 0x02 dlen 11 L2CAP(d): cid 0x0040 len 7 [psm 32769] 00 01 00 09 01 0D DC < ACL data: handle 0x002a flags 0x02 dlen 8 L2CAP(d): cid 0x0050 len 4 [psm 32769] 01 01 10 23 < ACL data: handle 0x002a flags 0x02 dlen 15 L2CAP(d): cid 0x0050 len 11 [psm 32769] 01 01 00 09 00 00 00 00 01 33 F4 > ACL data: handle 0x002a flags 0x02 dlen 8 L2CAP(d): cid 0x0040 len 4 [psm 32769] 00 01 21 10

The problem is that it uses an unknown PIN and the default 0000 is not accepted. Setting the headphone emulation into security mode 3 makes at least popup an input box for manual input of a custom PIN and the device setup can proceed. It seems that their special PIN is "fi01B3e5G855". After that a normal AVDTP exchange follows.

3. MusiCool 300 information

The MusiCool 300 from Aiptek is a package that contains two devices, a sending device (Audio SRC) and a receiving device (Headphone). Both of them uses the same Bluetooth chip from GCT and the real manufacturer of these devices is Air2U.

# hcitool info 00:0B:0D:50:0B:10 Requesting information ... BD Address: 00:0B:0D:50:0B:10 Device Name: Audio SRC[0B10] LMP Version: 1.1 (0x1) LMP Subversion: 0x530 Manufacturer: GCT Semiconductor (45) Features: 0xff 0xff 0x0d 0x00 0x00 0x00 0x00 0x00 <3-slot packets> <5-slot packets> <encryption> <slot offset> <timing accuracy> <role switch> <hold mode> <sniff mode> <park state> <RSSI> <channel quality> <SCO link> <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD> <power control> <transparent SCO> # hcitool info 00:0B:0D:50:12:51 Requesting information ... BD Address: 00:0B:0D:50:12:51 Device Name: Headphone[1251] LMP Version: 1.1 (0x1) LMP Subversion: 0x530 Manufacturer: GCT Semiconductor (45) Features: 0xff 0xff 0x0d 0x00 0x00 0x00 0x00 0x00 <3-slot packets> <5-slot packets> <encryption> <slot offset> <timing accuracy> <role switch> <hold mode> <sniff mode> <park state> <RSSI> <channel quality> <SCO link> <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD> <power control> <transparent SCO>

The Aiptek headphone is an audio sink devices and it uses SBC as default codec for the transmission of high quality audio. All possible settings are supported as required in the specification.

< ACL data: handle 0x002a flags 0x02 dlen 6 L2CAP(d): cid 0x0040 len 2 [psm 25] AVDTP(s): Discover cmd: transaction 0 > ACL data: handle 0x002a flags 0x02 dlen 8 L2CAP(d): cid 0x0041 len 4 [psm 25] AVDTP(s): Discover rsp: transaction 0 ACP SEID 1 - Audio Sink < ACL data: handle 0x002a flags 0x02 dlen 7 L2CAP(d): cid 0x0040 len 3 [psm 25] AVDTP(s): Capabilities cmd: transaction 1 ACP SEID 1 > ACL data: handle 0x002a flags 0x02 dlen 16 L2CAP(d): cid 0x0041 len 12 [psm 25] AVDTP(s): Capabilities rsp: transaction 1 Media Transport Media Codec - SBC 16kHz 32kHz 44.1kHz 48kHz Mono DualChannel Stereo JointStereo 4 8 12 16 Blocks 4 8 Subbands SNR Loudness Bitpool Range 2-250

4. Emulating a headphone

The sending device (Audio SRC) of the Aiptek package has an automatic pairing mode to find the headphone. What it does is searching for a device with the headset class of device 0x200404 and then tries to find an A2DP Sink service record. In the case of BlueZ it is possible to emulate this with the following commands:

# hciconfig hci0 class 0x200404 # hciconfig hci0 class hci0: Type: USB BD Address: 00:02:5B:01:00:42 ACL MTU: 384:8 SCO MTU: 64:8 Class: 0x200404 Service Classes: Audio Device Class: Audio/Video, Device conforms to the Headset profile # sdptool add a2snk Audio sink service registered # sdptool search --bdaddr local a2snk Searching for a2snk on FF:FF:FF:00:00:00 ... Service Name: Audio Sink Service RecHandle: 0x10002 Service Class ID List: "Audio Sink" (0x110b) Protocol Descriptor List: "L2CAP" (0x0100) PSM: 25 "AVDTP" (0x0019) uint16: 0x100 Profile Descriptor List: "Advanced Audio" (0x110d) Version: 0x0100

The details of the record added by the sdptool are not so really important, because the sender device only checks if there is a record for the A2DP Sink service and nothing more. It only checks the existence of this record with a SDP Service Search Request and after a positve response from the BlueZ side with a record handle it starts connecting to the L2CAP channel on PSM 25 for the AVDTP. The hcidump shows the details of the SDP request:

> ACL data: handle 0x002a flags 0x02 dlen 17 L2CAP(d): cid 0x0040 len 13 [psm 1] SDP SS Req: tid 0xfffe len 0x8 pat uuid-16 0x110b (AudioSink) max 0x2 cont 00 < ACL data: handle 0x002a flags 0x02 dlen 18 L2CAP(d): cid 0x0040 len 14 [psm 1] SDP SS Rsp: tid 0xfffe len 0x9 tot 0x1 cur 0x1 hndl 0x10002 cont 00

To proceed further with the headphone emulation there must be a listening L2CAP service on PSM 25. At the moment there exists no program for doing this.

5. Related projects

Bluetooth-alsa Project

6. Product links

Aiptek BT MusiCool 300
BlueTake i-PHONO BT420 EX

7. Qualification links

Toshiba Bluetooth Wireless Speech Recognizer
Air2U Bluetooth Audio adapter MCA01
Air2U Bluetooth Headphone MCH02