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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Brad Midgley <[email protected]> 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 : <[email protected]> =
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Brad Midgley <[email protected]> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Brad Midgley <[email protected]> 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 : <[email protected]> =
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel