[Bluez-devel] caching A2DP/alsa connection

[Bluez-devel] caching A2DP/alsa connection

[Brad Midgley]

Marcel,

I remember you were trying to keep the headset connection open between 
the quick audio device close and reopen that some clients like xmms do.

I started thinking we need to put esd or another audio server or alsa 
layer between the apps and our libalsa a2dp connection. Could we extend 
the caching to work between different apps this way? We may even be able 
to use a soft mixer to get simultaneous clients...

This is part of the reason I've been slow to jump in. It seems like I'd 
need to understand alsa up and down to know how to best make this work.

Brad


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] caching A2DP/alsa connection

[Andreas Beck]

Brad Midgley <bmidgley@xmission.com> wrote:
> I remember you were trying to keep the headset connection open between 
> the quick audio device close and reopen that some clients like xmms do.

That would probably be good, as I have seen xmms fail for some reason
on a relevant percentage of opens, which makes xmms stall in
"Stop"-mode. You can immediately press "Play" again and it will usually
work, but it's annoying, if you aren't sitting in fornt of the PC (where
you could use the internal soundcard anyway).


> I started thinking we need to put esd or another audio server or alsa 
> layer between the apps and our libalsa a2dp connection. 

This might be a good idea. I have been thinking about the same to do
away with some of the headaches of the skype hijacker.

Basically, a sound server is a good thing in itself, as it allows to
multiplex several audio sources, thus avoiding not hearing softphones
ring while watching a video clip or listening to mp3s.

Moreover it would save me the ugly hack I do in the skype-hijacker
to switch around the sound, if one could _tell_ the soundserver
to switch devices.

>From what I have seen by a quick glance over the various soundservers,
artsd seems to offer most oft the functionality I'd like to see.
Especially it offers a remote control application (artsshell) that might
be easily adapted to offer a few more commands (like changing output
device).


> Could we extend the caching to work between different apps this way? 

We could even avoid implementing it ourselves. "-s auto-suspend time"
seems to do what you are asking for.

And for apps that don't support arts natively, there is the artsdsp
wrapper which will try to capture application output.


> We may even be able  to use a soft mixer to get simultaneous clients...

What I am not yet sure of, is if artsd supports multiple output devices
in a more generic way than what I just thought aloud about switching them 
using the command channel.

What I am thinking of here is either
(simple version) have multiple artsds and have apps connect to the
                 appropriate daemon to select their output device.
(nice and complex) have a single artsd that handles all output devices
                   and individual mixers for each application<->device
				   pair.

I suppose this hasn't been an issue up to now, as usually a PC had only 
1 soundcard and there wasn't much sense in using a second one.

However now with networked sound devices, you may want to have an XMMS
playing music in the livingroom via a secondary soundcard that transmits
there via a hardware RF-link device, while the primary card emits
the sounds of some game your son is playing on the console and the 
btsco device is dealing with a VoIP call of your wife ...

I suppose you get the idea.

So basically what I suggest is:

- let's discuss, what we'd like to see and how to accomplish it most
  easily.
- let's get in touch with the developers of the sound daemon that looks
  like being easiest to adapt.
- maybe we can get them to implement our suggestions, or we can help out
  with that.

> This is part of the reason I've been slow to jump in. It seems like I'd 
> need to understand alsa up and down to know how to best make this work.

Hmm. I think alsa is not quite part of the solution, rather part of the
problem.

Don't get me wrong - I like alsa - the interface is much better than OSS
with respect to supporting multiple channels etc., and I am not a fan of 
soundservers either (don't run one, as I haven't needed one yet), but
the more I think of it, the more I get the impression that using a
soundserver is the correct solution.

The point that pulls me toward that view is, that a soundserver will
give us _virtualization_ of the audio device, not only _arbitration_, 
as the OS interface does.

I.e. with ALSA/OSS/etc. we will always have a problem when running more
than one program on the same audio device. We can trick around that a
little by using the multichannel facilities of some cards (I run xmms on
hwdev:0.1 usually to avoid it interfering with other apps), but we will
always have some corner cases that don't work well.

What I envision is a "next generation" mixer application that will start
up showing all sound devices and all sound using applications in a
matrix and i can click which combination I'd like to modify, before a
normal (or rather a somewhat limited) mixer pops up.
(I doesn't make sense to offer the mixer settings that are
 hardware-specific [like line-in/CDROM/Beeper feeds] in the 
 app-specific mixer)

Moreover it should be easy to configure applications to output on a
specific device, or even a specific device combination (like an inbound
VoIP ring going out on all available channels).


Phew. That went long. I'll probably better lean back now and hear some
of your opinions about this vision.

CU, Andy

-- 
= Andreas Beck                    |  Email :  <becka-sig@bedatec.de>         =


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] caching A2DP/alsa connection

[Brad Midgley]

Andreas

I was thinking specifically about the stereo audio driver but it applies 
to handsfree/headsets.

> From what I have seen by a quick glance over the various soundservers,
> artsd seems to offer most oft the functionality I'd like to see.
> Especially it offers a remote control application (artsshell) that might
> be easily adapted to offer a few more commands (like changing output
> device).

I want to avoid a sound server that is tied to a specific desktop. What 
about alsa's dmix? it seems to do what we want and at a lower level 
where it would work for everyone... 
http://alsa.opensrc.org/index.php?page=DmixPlugin

> - let's discuss, what we'd like to see and how to accomplish it most
>   easily.
> - let's get in touch with the developers of the sound daemon that looks
>   like being easiest to adapt.
> - maybe we can get them to implement our suggestions, or we can help out
>   with that.

I like the thoughts you're having about this... here's what how I want 
it to behave:

- bluetooth audio connection is brought up on demand; best if control 
connection is brought up on demand too

- audio connection is held open for a slight delay after the device is 
closed or idle in case it's to be used again soon

- audio device can be used by multiple apps (writing) but just one app 
reading (in the case of sco)

- reading audio "from" the a2dp device can be redirected to another 
device like a hardwired mic

headset negotiation and avrcp (on newer a2dp sets) gets more complicated:

- generate dbus events for button presses on the headset
- accept dbus events to initiate headset "ring" function

I guess the next step is to find out if dmix is useful here.

Brad


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] caching A2DP/alsa connection

[Andreas Beck]

Brad Midgley <bmidgley@xmission.com> wrote:
> I was thinking specifically about the stereo audio driver but it applies 
> to handsfree/headsets.

Yes. No matter what kind of extra soundcard you have. As soon as it is
more than one, you will probably have use for these ideas.

> >From what I have seen by a quick glance over the various soundservers,
> >artsd seems to offer most oft the functionality I'd like to see.
> >Especially it offers a remote control application (artsshell) that might
> >be easily adapted to offer a few more commands (like changing output
> >device).
> I want to avoid a sound server that is tied to a specific desktop. 

It actually isn't. I run fvwm2, and artsd works fine without starting
too much other crap. However:

> What about alsa's dmix? 

I didn't know that, and I think I like it. 

> it seems to do what we want and at a lower level where it would work 
> for everyone... 

Yes. Very nice. I suppose it is implemented in the ALSA libs - right?

> http://alsa.opensrc.org/index.php?page=DmixPlugin

> - bluetooth audio connection is brought up on demand; best if control 
> connection is brought up on demand too

Yeah. As said, I envision some kind od "dynamic" mix application that
shows all currently active sound-using programs and all currently
available sound devices.

Moreover this program should be scriptable for automating certain
behaviours.

> - audio connection is held open for a slight delay after the device is 
> closed or idle in case it's to be used again soon

I'm not sure how it is done currently. I'm not even sure, if it is easy
to do if it is done from within the alsa library, but I got to look at 
the code first.

> - audio device can be used by multiple apps (writing) but just one app 
> reading (in the case of sco)

I have just tested it and multi-app-writing works. I pushed 3 mp3s in
parallel which is more than my 2 channel card normally does.

> - reading audio "from" the a2dp device can be redirected to another 
> device like a hardwired mic

Yeah. Basically I'd like to see some kind of "switchboard".


> headset negotiation and avrcp (on newer a2dp sets) gets more complicated:
> - generate dbus events for button presses on the headset
> - accept dbus events to initiate headset "ring" function

Yeah. I'll probably have to look into dbus, as more and more apps start
using it.

> I guess the next step is to find out if dmix is useful here.

It looks like it is. Thanks for that pointer.


CU, Andy


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] caching A2DP/alsa connection

[Andreas Beck]

Brad Midgley <bmidgley@xmission.com> wrote:
> I want to avoid a sound server that is tied to a specific desktop. What 
> about alsa's dmix? it seems to do what we want and at a lower level 
> where it would work for everyone... 
> http://alsa.opensrc.org/index.php?page=DmixPlugin

Have you seen 
http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php?company=Generic&card=Generic&chip=Generic&module=Generic#virmulti
?

Looks like it basically _is_, what we want. However I am unable to get
the "multi"-example working. I don't quite get the syntax and am unsure 
if it will do what I am trying to accomplish.

I tried to hack it to push the same sound stream to both the
headset-device and the soundcard. However alsaplayer segfaults at
startup after some not really meaningful error messages.

Maybe you can get that working? I think I need some sleep now.

It doesn't look, if it is designed to be reconfigureable dynamically,
but I'll think about that, when I have it working statically.

Do we have a contact to the alsa developers already? Someone who can
shed some light on how it is supposed to work, and if it can be tweaked 
to serve our purposes?


CU, Andy

-- 
= Andreas Beck                    |  Email :  <becka-sig@bedatec.de>         =


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] caching A2DP/alsa connection

[Brad Midgley]

Andreas

> Have you seen 
> http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php?company=Generic&card=Generic&chip=Generic&module=Generic#virmulti
> ?

This looks like it's for bonding cards together to behave like a big 
multichannel card. This doesn't solve the core problem of giving 
multiple clients simultaneous access to a userspace plugin.

Brad


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] caching A2DP/alsa connection

[Marcel Holtmann]

Hi Brad,

> I remember you were trying to keep the headset connection open between 
> the quick audio device close and reopen that some clients like xmms do.
> 
> I started thinking we need to put esd or another audio server or alsa 
> layer between the apps and our libalsa a2dp connection. Could we extend 
> the caching to work between different apps this way? We may even be able 
> to use a soft mixer to get simultaneous clients...
> 
> This is part of the reason I've been slow to jump in. It seems like I'd 
> need to understand alsa up and down to know how to best make this work.

even I have to look at it again, but what also came up lately is a
native integration of A2DP as GStreamer plugin. Maybe you wanna start
looking at that, because I never looked at any Code of the GStreamer
project by now.

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] caching A2DP/alsa connection

[Brad Midgley]

Marcel,

I've joined the gstreamer list and I'm looking into the docs some more 
before I ask them if gstreamer plugins can do everything we need. I hate 
to add a dependency, but if gstreamer is a more straightforward way to 
go and it's becoming mainstream, I don't mind requiring it.

Brad

Marcel Holtmann wrote:
> Hi Brad,
> 
> 
>>I remember you were trying to keep the headset connection open between 
>>the quick audio device close and reopen that some clients like xmms do.
>>
>>I started thinking we need to put esd or another audio server or alsa 
>>layer between the apps and our libalsa a2dp connection. Could we extend 
>>the caching to work between different apps this way? We may even be able 
>>to use a soft mixer to get simultaneous clients...
>>
>>This is part of the reason I've been slow to jump in. It seems like I'd 
>>need to understand alsa up and down to know how to best make this work.
> 
> 
> even I have to look at it again, but what also came up lately is a
> native integration of A2DP as GStreamer plugin. Maybe you wanna start
> looking at that, because I never looked at any Code of the GStreamer
> project by now.
> 
> Regards
> 
> Marcel
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. 
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] caching A2DP/alsa connection

[Marcel Holtmann]

Hi Brad,

> I've joined the gstreamer list and I'm looking into the docs some more 
> before I ask them if gstreamer plugins can do everything we need. I hate 
> to add a dependency, but if gstreamer is a more straightforward way to 
> go and it's becoming mainstream, I don't mind requiring it.

I still think the ALSA plugin is the way to go, but there are still some
problems to solve and it doesn't help for embedded systems that don't
use ALSA. I think we have to go both ways anyhow.

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel