_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
> * 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