SCO on bluez : some architectural tips
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
begin:vcard
fn:Fabien CHEVALIER
n:CHEVALIER;Fabien
org:SILICOM
adr:;;4 rue de Jouanet;RENNES ATALANTE;;35700;FRANCE email;internet:[email protected] title:Software & Studies Engineer tel;work:+33 (0) 2 99 84 17 17
version:2.1
end:vcard
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Quoted 2 lines
* 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Fabien
Quoted 2 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fabien,
Quoted 2 lines
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.
Quoted 1 line
Quoted 1 line
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
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Albert,
Quoted 2 lines
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
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Albert,
Quoted 6 lines
Quoted 2 lines
* 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Brad,
Quoted 6 lines
Fabien
Quoted 2 lines
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
Quoted 1 line
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
Quoted 3 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Frederic
Quoted 8 lines
Hi Fabien,
Quoted 2 lines
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.
Quoted 6 lines
Quoted 2 lines
Quoted 2 lines
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
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fabien,
We won't be able to use +/- in a game or system sound!
Quoted 5 lines
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
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Frederic
Quoted 1 line
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Fabien
Quoted 9 lines
We would have to put
Quoted 3 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Frederic,
Quoted 3 lines
=
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.
Quoted 10 lines
=
Quoted 5 lines
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 :-)
Quoted 2 lines
If buffering takes place
inside the SCO socket, then work is due to the socket itself. In both cas=
es,
Quoted 1 line
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.
Quoted 4 lines
=
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
Quoted 4 lines
=
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 :-)
Quoted 3 lines
=
Probably the best way to figure out the best architecture is to have both=
and
Quoted 1 line
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Brad,
Quoted 6 lines
Fabien
Quoted 4 lines
We would have to put
Quoted 3 lines
in some locking to keep applications from trying to open more simultaneous sco sockets. I wonder how the other audio servers avoid this problem.
Quoted 6 lines
Quoted 4 lines
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. :-)
Quoted 4 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel