SCO 디버깅 하기

출처 : http://permalink.gmane.org/gmane.linux.bluez.devel/75

Re: [Bluez-devel] Re: (no subject)

Hello,

It seems that many people are stuck at the same place when trying to
transmit voice over SCO. The nature of Marcel's replies suggests to me
that there may 
be something that we all get wrong, so I'll try to summarize what I 
understand, to see if we can locate the misconception together.

a- SCO sockets in Bluez just encapsulate SCO links from the BT stack.

b- Voice can be transmitted over SCO links.

c- BT devices have embedded algorithms for transmitting voice over SCO.
They encode sound received from the host into a specific "air" format,
and the other way around.

d- Encoding can be parameterized through the "hciconfig hci0 voice"
command. Basically, one can choose the "host" encoding among formats
such as PCM ulaw, PCM Alaw, PCM linear, etc, and the "air" encoding
among formats such as CVSD or PCM.

e- CVSD is a lossy format which encodes differences from a predicted
signal, and consequently it is impossible to detect bugs by comparing
what's given at one end and what's received at the other end.

f- Given a sound file, and (for instance) two PCs with BT dongles, one
can transmit the sound over BT and play it by:
  0. having the two BT dongles use the same "air" encoding, say CVSD
(this is done through "hciconfig hci0 voice"
  1. converting the sound to the "host" encoding expected by the BT
dongle (encoding which has been specified through "hciconfig hci0
voice")
  2. opening a SCO socket and transmitting the sound over it
  3. at the receiving end, converting the sound from the "host" encoding
(encoding which has been specified through "hciconfig hci0 voice") to a
format usable by /dev/dsp
  4. feed the sound to /dev/dsp

This is basically it. The problem is that when doing this, it does not
work for me: I mostly get noise at the other end. The problem is that it
is hard to debug, because :
 - I don't know for sure if the problem is SCO-related or sound-related.
 - one cannot just test the SCO connection by sending and comparing
samples, because of the CVSD encoding.

Here are some bits of code I used for doing this.

Le mar 10/06/2003 à 16:04, Marcel Holtmann a écrit :
> Hi Jian,
> 
> > hciconfig hci0 voice 40
> > hciconfig hci1 voice 40
> > It still cannot work. I just dump some 0xff or 0x00 data.
> 
> first of all this must be "hciconfig hci0 voice 0x0040".
> 
> > I use 2.4.20 with patch-2.4.20-mh7.gz,
> > I try mandrake 9.1 with 2.4.21 kernel and hci_usb-031803.tar.gz
> 
> Use 2.4.20-mh9. And do scoinfo tell you that the device support SCO over
> HCI (MAP_SCO_PCM=0x00).
> 
> > I use scotest.c instead of hstest.c. I have no bluetooth headset. I have just two bluetooth usb adapters.
> > 
> > Could you tell me how to debug the scotest.c and bluez modules kernel together?
> 
> Convert your wav file into PCM format (according to the voice setting)
> and transport it over the SCO link. On the other side convert it back to
> wav. The bits may change, but if you play it, it will to sound similar.
> 
> Regards
> 
> Marcel
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
> 

Attachment (sco.tgz): application/x-gzip, 2301 bytes

sco.tgz

 

mpg123 -s rolie6.mp3 | sox -V -t raw -r 44100 -s -w -c 2 - -r 8000 -c 1 -b rolie6.sb

sox -t raw -r 8000 -c 1 -s -b audio -t ossdsp -r 44100 -c 2 -s -w /dev/dsp vol 2.0 2> /dev/null