[Bluez-devel] SCO on bluez : some architectural tips

[Bluez-devel] SCO on bluez : some architectural tips

[Fabien Chevalier]

[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]


Marcel & Brad,

I send you this e-mail to share some of the experience acquired while 
writing bluez-headset.
There is much to share but i'll do it bits at a time, it will be more 
easy to digest than a 300 lines e-mail :-).

So let's talk about SCO today. :-)

SCO is designed for low quality (poor Hz rate). It's only application is 
telephony.
However it requires *really* low latency.

At first hand i tried the same approach as you did, which means route 
audio trough a daemon that could do all kind a of funny and interesting 
stuff in it. This would have been a very interesting approach.
However result was really bad, for two reasons:
 * The unix socket between application and the daemon would queue some 
data, which would add unwanted delay.
 * And moreover, the fact to send the data trough a 3rd party unix 
process (the daemon), resulted in jitter due to scheduling behaviour. Do 
avoid hearing audio cuts in the headset, i had to add run daemon as root 
and decrease its nice value to unsane levels.

Due to this, i had to fall back on having the SCO file descriptor 
available in application process space.

However, due to the fact a2dp is not supposed to be used for delay sensitive
 streams, it is possible to use this architecture for a2dp. :-)

Cheers,

Fabien

[-- Attachment #2: fchevalier.vcf --]
[-- Type: text/x-vcard, Size: 241 bytes --]

begin:vcard
fn:Fabien CHEVALIER
n:CHEVALIER;Fabien
org:SILICOM
adr:;;4 rue de Jouanet;RENNES ATALANTE;;35700;FRANCE
email;internet:fchevalier@silicom.fr
title:Software & Studies Engineer
tel;work:+33 (0) 2 99 84 17 17
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #4: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] SCO on bluez : some architectural tips

[Albert Huang]

>  * The unix socket between application and the daemon would queue some
> data, which would add unwanted delay.

just curious, was setvbuf( fp, NULL, _IONBUF, 0 ) to disable socket
buffering an option?

-albert

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] SCO on bluez : some architectural tips

[Brad Midgley]

Fabien

> Due to this, i had to fall back on having the SCO file descriptor 
> available in application process space.

If it's inevitable, I think we could keep the fd in the audio app's 
userspace and mostly pull things off as envisioned. We would have to put 
in some locking to keep applications from trying to open more 
simultaneous sco sockets. I wonder how the other audio servers avoid 
this problem.

Brad


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] RE : SCO on bluez : some architectural tips

[Frederic Dalleau]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

Hi Fabien,

> However, due to the fact a2dp is not supposed to be used for delay sensitive
> streams, it is possible to use this architecture for a2dp. :-)

A2DP data are certainly not sensitive, but having the sound of your movie playing
with delay is really unpleasant. So in the end the need for low latency is probably
the same in SCO and A2DP.

>>From my point of vue, having the SCO socket inside application is not needed.
The benefit is one single unix socket transfer. In a typical video conferencing
application used on the internet, the delay used for transmitting data will probably
be by far more important than the delay induced by this transfer. So any gain
on the SCO side would be made negligible against what is lost during transmission.

Frederic

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 3046 bytes --]

[-- Attachment #3: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #4: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] RE : SCO on bluez : some architectural tips

[Frederic Dalleau]

[-- Attachment #1: Type: text/plain, Size: 169 bytes --]

Hi Albert,

> just curious, was setvbuf( fp, NULL, _IONBUF, 0 ) to disable socket
> buffering an option?

Would this work on a bluetooth L2CAP socket?

Frédéric

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2674 bytes --]

[-- Attachment #3: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #4: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] SCO on bluez : some architectural tips

[Fabien Chevalier]

Hi Albert,

>>  * The unix socket between application and the daemon would queue some
>> data, which would add unwanted delay.
> 
> just curious, was setvbuf( fp, NULL, _IONBUF, 0 ) to disable socket
> buffering an option?
> 

In our case we use direct read/write calls from socket descriptor, which 
means that setvbuf is useless, as it works at libc layer.

Good try anyway ;-)

Cheers,

Fabien

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] SCO on bluez : some architectural tips

[Fabien Chevalier]

Hi Brad,

> Fabien
> 
>> Due to this, i had to fall back on having the SCO file descriptor 
>> available in application process space.
> 
> If it's inevitable, 

I'm afraid it is.

I think we could keep the fd in the audio app's
> userspace and mostly pull things off as envisioned. 

Yes, i would tend to agree with that, i think it's best to hide most of 
the complexity from the application.

We would have to put
> in some locking to keep applications from trying to open more 
> simultaneous sco sockets. I wonder how the other audio servers avoid 
> this problem.

Brad, you should have a look at headsetd source.
I solved this problem there by having headsetd open the sco channel and 
then hand it over to the application using unix sockets ancillary data. 
(man 7 unix for more info)

Cheers,

Fabien

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] RE : SCO on bluez : some architectural tips

[Fabien Chevalier]

[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]

Hi Frederic

> Hi Fabien,
> 
>> However, due to the fact a2dp is not supposed to be used for delay sensitive
>> streams, it is possible to use this architecture for a2dp. :-)
> 
> A2DP data are certainly not sensitive, but having the sound of your movie playing
> with delay is really unpleasant. So in the end the need for low latency is probably
> the same in SCO and A2DP.

Yes and No :-)
I agree having the sound of your movie played with delay is unpleasant.

However even if it takes one second between the moment the player sents
audio data and the moment it is heared by you, it is this possible to
have audio and video in sync if the player sends desyncs audio and video
 of one second. For instnace, mplayer + and - keys allows you to do just
that.


> 
>>>From my point of vue, having the SCO socket inside application is not needed.
> The benefit is one single unix socket transfer. In a typical video conferencing
> application used on the internet, the delay used for transmitting data will probably
> be by far more important than the delay induced by this transfer. So any gain
> on the SCO side would be made negligible against what is lost during transmission.

I don't agree with that. It's not uncommon these days to have ~ 50 ms
latency between one point fo the internet and the other. (ok not at the
other side of the planet tough :-) )
Let' say you use a unix socket. Sco sockets have a fixed queue length
(something like 1 kb if i remember : this should be checked). Each SCO
packets is 48 bytes, with 'lasts' 3 msec. Which means we can fit
20 packets, or 60 ms data.
Congratulations, we just added more delay that the network itself !! ;-)

Cheers,

Fabien


[-- Attachment #2: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] RE : RE : SCO on bluez : some architectural tips

[Frederic Dalleau]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

Hi Fabien,

We won't be able to use +/- in a game or system sound!

> Let' say you use a unix socket. Sco sockets have a fixed queue length
> (something like 1 kb if i remember : this should be checked). Each SCO
> packets is 48 bytes, with 'lasts' 3 msec. Which means we can fit
> 20 packets, or 60 ms data.
> Congratulations, we just added more delay that the network itself !! ;-)

Did you mean Unix socket have a fixed queue length? If buffering takes place
inside the SCO socket, then work is due to the socket itself. In both cases,
I would be surprised if this wasn't tunable.

Nevertheless, there is no need to know the buffer size : if the buffer was
1 Mb long would you wait for it to be full before reading data? 

Last, benchmarks on the net measure unix socket latency using µs unit.


Probably the best way to figure out the best architecture is to have both and
measure.

Regards,
Frédéric

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 3376 bytes --]

[-- Attachment #3: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #4: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] RE : RE : SCO on bluez : some architectural tips

[Brad Midgley]

Frederic

> We won't be able to use +/- in a game or system sound!

multiplayer gaming would not be acceptable with a2dp latencies. System 
sounds like taps that are supposed to be an immediate feedback would 
have to be turned off probably.

I want to have the bluetooth audio daemon keep track of latency for a 
given headset and leave it up to the app to do something about it. 
System sounds like tap feedback would be turned off for significant 
delay but single-player gaming and video playing could accommodate the 
delay.

Brad

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] SCO on bluez : some architectural tips

[Brad Midgley]

Fabien

> We would have to put
>> in some locking to keep applications from trying to open more 
>> simultaneous sco sockets. I wonder how the other audio servers avoid 
>> this problem.
> 
> Brad, you should have a look at headsetd source.
> I solved this problem there by having headsetd open the sco channel and 
> then hand it over to the application using unix sockets ancillary data. 
> (man 7 unix for more info)

nice... just like a cross-process dup().

if we have two audio clients open, it sounds like they could both hold 
the fd to the sco socket--we'd just have to arbitrate who is allowed to 
use it at any one time.

Brad

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] RE : RE : SCO on bluez : some architectural tips

[Fabien Chevalier]

Hi Frederic,

> =

> We won't be able to use +/- in a game or system sound!

Of course we can't :-). But a2dp has never been designed for that =

either. It has been designed so that handset makers be able to stream =

music over headsets.

> =

>> Let' say you use a unix socket. Sco sockets have a fixed queue length
>> (something like 1 kb if i remember : this should be checked). Each SCO
>> packets is 48 bytes, with 'lasts' 3 msec. Which means we can fit
>> 20 packets, or 60 ms data.
>> Congratulations, we just added more delay that the network itself !! ;-)
> =

> Did you mean Unix socket have a fixed queue length? =


Yes they did. I had to dig into kernel sources to find that :-)

> If buffering takes place
> inside the SCO socket, then work is due to the socket itself. In both cas=
es,
> I would be surprised if this wasn't tunable.

SCO socket queue is tunable, provided you use my flow control patch... =

otherwise it's not.

> =

> Nevertheless, there is no need to know the buffer size : if the buffer was
> 1 Mb long would you wait for it to be full before reading data? =


Frederic, this is not the point. Of course we won't wait the buffer to =

be full before sending audio data to the remote device.
But if buffer is 1 MB long, then the application that plays sound will =

fill up the buffer faster that the device reads. Which means at one =

point or another, the buffer will be full, thus introducing audio =

latency equal to the time it takes to empty the buffer

> =

> Last, benchmarks on the net measure unix socket latency using =B5s unit.
> =


That easy to say. Just give it a try and you might have some surprises :-)

> =

> Probably the best way to figure out the best architecture is to have both=
 and
> measure.

I 100% agree with that. :-)

I can provide wome source code that doe just that to whoever is =

interested in testing this daemon approach.

Cheers,

Fabien

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE=
VDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] SCO on bluez : some architectural tips

[Fabien Chevalier]

Brad,

> Fabien
> 
>> We would have to put
>>> in some locking to keep applications from trying to open more 
>>> simultaneous sco sockets. I wonder how the other audio servers avoid 
>>> this problem.
>> Brad, you should have a look at headsetd source.
>> I solved this problem there by having headsetd open the sco channel and 
>> then hand it over to the application using unix sockets ancillary data. 
>> (man 7 unix for more info)
> 
> nice... just like a cross-process dup().

That's exactly the spirit of it. :-)

> 
> if we have two audio clients open, it sounds like they could both hold 
> the fd to the sco socket--we'd just have to arbitrate who is allowed to 
> use it at any one time.

Exactly. :-) Current headsetd implementation waits for clients 
connections on a unix server socket, and can only accept a single client 
at a time.
Thus we are sure that the server will be able to hand over the sco fd to 
only one client at a time.

Just a question that comes to my mind: Headsetd does only support one 
active application and one SCO headset at a time. Is there any gain 
supporting two headsets at the same time ? I was just trying to look for 
use cases but didn't find any :-(

Cheers,

Fabien

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel