On Mon, 11 Dec 2006, Juan RP wrote:

> [juan@nocturno][~]> sudo btconfig -v ubt0
> ubt0: bdaddr 00:0a:94:13:22:93 flags 0x3<UP,RUNNING>
>         num_cmd = 1
>         num_acl = 20, acl_mtu = 120
>         num_sco = 0, sco_mtu = 0
>
> Is it the expected value?

No, All the devices I have seen show at least some values in the sco
portion. There is a Belkin device (BCM2035 I think) that apparently has
some kind of broken SCO support (I see this referred to in the BlueZ
source). Can you show the output of 'usbdevs -v' for this device?  I
wonder if its related..

> I would like to know the maximum payload size of my device but don't know
> where did you get the 64bytes value...

That was just the original value that btconfig showed.. (results of the
Read_Buffer_Size command to the device)

> Looks like I'd have to use same value than you, but that doesn't work for
> me... bthfp works fine but does not print "Audio connection established" or
> something like this as my previous tests, and I can only hear audio
> distorted or garbage.

Ok. Next idea then is that there are two directions - for incoming audio
(ie the phone is sending us sound) the device just sends us packets any
way it likes (we don't care, and they pass through the usb stack fine)

Do you have sysutils/hcidump installed? If you run that (sudo because
snooping on data is privileged) and check the length of the SCO packets
that the device sends us, that might be a good size to use..

..although, the audio data in each direction should be fairly independent,
so the fact that nothing is being sent to the phone when it is sending us
data should make no difference to the ringing noise in the computer
speakers.

Also, that you don't get 'Audio connection established' is strange since
its just a printf at the end of the function where the blocksize divide
was, did you put it back together?

iain