This question is probably not specific to Bluez, but might be.
When opening an SCO connection between two clients using Bluez, there is
a continous
stream of incoming data on both ends, even without issuing any sends on
either side.
The stream ends when the SCO connection is terminated.
I have done some tests, and this happens in both of the following cases:
1. With scotest, by blocking for some time right before the send(...)
call in scotest.c:send_mode.
By using hcidump, it is clear that both devices receive streams of
data without sending anything.
2. I wrote an application that used hci_sock w/ hci_usb (raw data and
hci_raw bit set) to manually
setup an acl and then sco connection. Same result.
This was tested on machines running Linux 2.4.25 (usb-uhci), with Belkin
USB (CSR) devices. The SCO connection
in case 2 was setup to use HV2 packets.
I have tested this with different voice settings, but pretty much with
the same results (although the data changes).
Most of the data is SCO packets of length 0x30 and the data contents are
either garbage or 0x00.
Is this generated by the BT-devices to maintain a ~ 64kb/s synchronous
stream of data, is it generated
by the Bluez modules, or is there something wrong in the hci_usb driver
isoc. interface rx implementation that makes it
deliver garbage to the socket?
Thanks,
Thor E. Skaug
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Thor,
> When opening an SCO connection between two clients using Bluez, there is
> a continous
> stream of incoming data on both ends, even without issuing any sends on
> either side.
> The stream ends when the SCO connection is terminated.
>
> I have done some tests, and this happens in both of the following cases:
>
> 1. With scotest, by blocking for some time right before the send(...)
> call in scotest.c:send_mode.
> By using hcidump, it is clear that both devices receive streams of
> data without sending anything.
>
> 2. I wrote an application that used hci_sock w/ hci_usb (raw data and
> hci_raw bit set) to manually
> setup an acl and then sco connection. Same result.
>
> This was tested on machines running Linux 2.4.25 (usb-uhci), with Belkin
> USB (CSR) devices. The SCO connection
> in case 2 was setup to use HV2 packets.
>
> I have tested this with different voice settings, but pretty much with
> the same results (although the data changes).
> Most of the data is SCO packets of length 0x30 and the data contents are
> either garbage or 0x00.
>
> Is this generated by the BT-devices to maintain a ~ 64kb/s synchronous
> stream of data, is it generated
> by the Bluez modules, or is there something wrong in the hci_usb driver
> isoc. interface rx implementation that makes it
> deliver garbage to the socket?
it is all fine. You get the audio stream from the other side, even if
you don't input anything.
Regards
Marcel
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users