* [Bluez-devel] [RFC] : Bluez audio routing: introducing switch alsa plugin
@ 2006-12-10 15:51 Fabien Chevalier
2006-12-11 15:29 ` Brad Midgley
0 siblings, 1 reply; 2+ messages in thread
From: Fabien Chevalier @ 2006-12-10 15:51 UTC (permalink / raw)
To: BlueZ development
All,
I got here a suggestion for audio routing.
I take here as assumption that it is a possibility that sco and a2dp
plugins are different.
The idea is to bring in the picture a new plugin that i would call
conveniently the 'switch' plugin.
As its name suggests, its role would be to route to either one PCM
stream or another PCM.
We could imagine that per default the plugin would route audio to wired
PCM IO, and when notified that a alternate PCM is ready, would switch to
this plugin.
This would give sth like that:
audio application --> switch plugin --> wired io PCM
|
|
----> bluetooth plugin --> bt.audiod
This is an audio routing suggestion that could be used for both SCO and
A2DP.
as usual, comments are welcomed,
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Bluez-devel] [RFC] : Bluez audio routing: introducing switch alsa plugin
2006-12-10 15:51 [Bluez-devel] [RFC] : Bluez audio routing: introducing switch alsa plugin Fabien Chevalier
@ 2006-12-11 15:29 ` Brad Midgley
0 siblings, 0 replies; 2+ messages in thread
From: Brad Midgley @ 2006-12-11 15:29 UTC (permalink / raw)
To: BlueZ development
Fabien
> The idea is to bring in the picture a new plugin that i would call
> conveniently the 'switch' plugin.
> As its name suggests, its role would be to route to either one PCM
> stream or another PCM.
This approach would be ok I think. It's an implementation detail.
One motivation for this approach would be keeping a2dp and sco daemons
separate. Are you still interested in doing it that way?
We have been running with the assumption that we will have a single
daemon for sco and a2dp. So Connect(addr) would attempt to make control
connections for both protocols. Does this become too difficult?
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2006-12-11 15:29 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-12-10 15:51 [Bluez-devel] [RFC] : Bluez audio routing: introducing switch alsa plugin Fabien Chevalier
2006-12-11 15:29 ` Brad Midgley
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox