2006-05-11 09:15:57

by Frédéric DALLEAU

[permalink] [raw]
Subject: RE: [Bluez-devel] A2DP and Alsa Plugin

Brad,

> I've read about ALP. It looks exciting. I was glad to see ALP=20
> will include gstreamer as part of the foundation. You should=20
> help me write proper gstreamer plugins.

I did not worry about gstreamer as I tried the gstreamer
alsasink yesterday. This allow you to create a graph with either
bluetooth output or alsa output without modifying your .asoundrc. Just
modify the device field. One address only as set in filename.

> alsa plugins use an api that is too simple for complete=20
> headset support... also there have been complaints about=20
> libalsa not scaling down for embedded systems.

I'm new to alsa and gstreamer and I don't understand you yet.
Can you point me to document you use? I just saw that volume control
wasn't available with alsa-plugin if this is what you mean.

However, I mainly worry about the following points :
* I do not get 2 apps with a2dp output on the same address. As
devices seems to manage only one socket, the second app will generally
crash. Could we implement some sort of mixing or application selection
(the foreground app or the first app started on an address, but with
proper error handling for the others)?
* How to select whether the application will output on a2dp or
speaker? Should this be application related or system related?
* What you told me with gxine may vary depending the
application. I believe one way to handle this is to maintain
asynchronous connection to target sink. The api would just enqueue the
audio packets into a common shared queue (per target). The connection
simply close when there are no more audio packets.

Did you change something since 0.42?

Frederic


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel


2006-05-30 20:28:20

by Brad Midgley

[permalink] [raw]
Subject: Re: [Bluez-devel] A2DP and Alsa Plugin

Fr=E9d=E9ric

>>Ideally it's a system function, but I'm not seeing a way to pull that off.
>> =

> gstreamer makes it easy to write applications, but application writer =

> can choose whatever sink he wants. We cant rely on application being =

> a2dp aware.

I just read this more carefully... so the system would do things like
discover headsets, pair, update .asoundrc (or equivalent). The app
should only have to search for a plugin and let the user choose it.

Brad


_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-05-30 16:38:32

by Brad Midgley

[permalink] [raw]
Subject: Re: [Bluez-devel] A2DP and Alsa Plugin

Fr=E9d=E9ric

> gstreamer provides a tcpserver sink and source but it does not work the =

> way i want it to.

yeah too bad... gst folks could recommend the easiest approach to code
up a fix.

> However, mixing might be a fake problem. Maybe we should first figure =

> what applications uses alsa directly. All the popular apps (xmms/totem) =

> seems esd and arts aware.

totem and amarok at least have gstreamer "ports" now, but that might be
mainly to get the best codec the os can provide.

i have not looked at all into having esd/arts working with our alsa
plugin. they may need patching to look for plugins, to open on demand,
and to briefly cache unneeded connections.

brad


_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-05-30 10:20:32

by Frédéric DALLEAU

[permalink] [raw]
Subject: Re: [Bluez-devel] A2DP and Alsa Plugin

Hi brad,

>>>> * How to select whether the application will output on a2dp or
>>>>speaker? Should this be application related or system related?
>>>> =

>>>>
>
>Ideally it's a system function, but I'm not seeing a way to pull that off.
> =

>
gstreamer makes it easy to write applications, but application writer =

can choose whatever sink he wants. We cant rely on application being =

a2dp aware.
To provide system level functionnality, a good place is inside the sound =

daemon like esd. esd already does the mixing and ipc stuff.
The main drawback is that this would restrict usage to gnome apps.

I just saw a media system selector (gstreamer-properties) but I haven't =

figured its role. Is that a sort of default gstreamer audio sink?

>gstreamer has no ipc equivalent to the alsa dmix, so a pure gst
>implementation will not mix multiple apps down to one stream.
> =

>
I've played a bit with dmix but did not have it working. It seems to =

only redirect sound to hardware sound cards. gonna ask on alsa mailing list.

>that is unless you help write the ipc mixer for gst :)
> =

>
The only sort of ipc I know that would suit would be ip sockets... We =

will end up writing a sound server like esd and we would still need to =

write a plugin and a gstreamer sink.

gstreamer provides a tcpserver sink and source but it does not work the =

way i want it to. The server will block until a client connect. Multiple =

client are not allowed.

However, mixing might be a fake problem. Maybe we should first figure =

what applications uses alsa directly. All the popular apps (xmms/totem) =

seems esd and arts aware.

Fr=E9d=E9ric



_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-05-29 07:02:19

by Brad Midgley

[permalink] [raw]
Subject: Re: [Bluez-devel] A2DP and Alsa Plugin

Fr=E9d=E9ric

I've been discussing this over at the gstreamer list and I have some
more info.

>>> * How to select whether the application will output on a2dp or
>>> speaker? Should this be application related or system related?

Ideally it's a system function, but I'm not seeing a way to pull that off.

> How about a daemon that uses gstreamer with one or more ipc gstreamer
> source, a mixmatrix, volume control (if not done by mixmatrix), (alsa
> sink or (sbcfilter and a2dp sink)) to finish...
> An alsa plugin and/or a gstreamer ipc plugin would just send ipc to the
> daemon.

gstreamer has no ipc equivalent to the alsa dmix, so a pure gst
implementation will not mix multiple apps down to one stream.

that is unless you help write the ipc mixer for gst :)

sadly, gst would really be a great implementation (moving the encoder
into a hotpluggable module, allowing for late binding on choosing the
encoder, possibly a way to redirect a stream in progress to the set) but
the lack of a way to mix multiple apps is not great.

Brad


_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-05-17 17:40:41

by Brad Midgley

[permalink] [raw]
Subject: Re: [Bluez-devel] A2DP and Alsa Plugin

Fr?d?ric

> How about a daemon that uses gstreamer with one or more ipc gstreamer
> source, a mixmatrix, volume control (if not done by mixmatrix),
> (alsa sink or (sbcfilter and a2dp sink)) to finish... An alsa plugin
> and/or a gstreamer ipc plugin would just send ipc to the daemon.

I will ask on the gstreamer list. When reading the gstreamer docs it
seems like the "sky's the limit." I wish I could understand the
limitations better.

> Why not sharing code between a2play and alsa-plugin? There are some
> variables that are shared among instances (bufe,lenbufe,tsend,...)
> why are they globals? There is a snd_pcm_a2dp_t structure that would
> (IMHO) embed them very well. Is this alsa related limitation? This
> forbid using multiple headsets at a time...

Marcel wanted to leave this stuff out of bluez for now but avrcp/a2dp
signaling would best fit there if they are to be shared.

alsa-plugin is a little messier than our typical bluetooth-alsa
component. yes, a bunch of those should not be global variables and some
further cleanup is in line. An even bigger problem is we essentially
ignore the return value from write(). I want to figure out how things
can fail there and what we should do to recover.

> Now that cvs works, how to propose patches? on the list? By creating
> a sf developper account?

please submit patches here to the list for now.

brad


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-05-17 16:51:59

by Frédéric DALLEAU

[permalink] [raw]
Subject: Re: [Bluez-devel] A2DP and Alsa Plugin

Hi brad,

>> * How to select whether the application will output on a2dp or
>>speaker? Should this be application related or system related?
>>
>>
>system. we need a way to change it while an app is outputing sound.
>
>
It is not that simple with alsa, as I'm really unsure whether alsa can
change output plugin at runtime unless the plugin reinject the sound
into alsa itself? It's weird... Other than socket, what sort of ipc
would allow mixing? I'm unsure a named pipe can do it. You need to
create multiple pipes but how to choose one from the client app...

How about a daemon that uses gstreamer with one or more ipc gstreamer
source, a mixmatrix, volume control (if not done by mixmatrix), (alsa
sink or (sbcfilter and a2dp sink)) to finish...
An alsa plugin and/or a gstreamer ipc plugin would just send ipc to the
daemon.

Now to be more specific, I still have some questions :

Why not sharing code between a2play and alsa-plugin?
There are some variables that are shared among instances
(bufe,lenbufe,tsend,...) why are they globals? There is a snd_pcm_a2dp_t
structure that would (IMHO) embed them very well. Is this alsa related
limitation? This forbid using multiple headsets at a time...

Now that cvs works, how to propose patches? on the list? By creating a
sf developper account?

Thanks
Frederic





-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-05-12 17:10:45

by Brad Midgley

[permalink] [raw]
Subject: Re: [Bluez-devel] A2DP and Alsa Plugin

Frederic

> I did not worry about gstreamer as I tried the gstreamer
> alsasink yesterday. This allow you to create a graph with either
> bluetooth output or alsa output without modifying your .asoundrc. Just
> modify the device field. One address only as set in filename.

It will work (probably not much worse than direct alsa). We end up with
a plugin api that is a least-common denominator of the two this way. I'd
rather eliminate the need for the extra layers. (btw, libalsa and
alsasink probably add over a megabyte together in libraries.)

regarding docs... alsalib is poorly documented (that's one of the
problems) but gstreamer does have good plugin docs.

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/index.html

the gstreamer approach allows us to easily snap out the software sbc
codec for a dsp task if you have one available. the decision doesn't
even have to be made until runtime and the other layers like a2dp setup
don't need to be replaced or duplicated.

>> alsa plugins use an api that is too simple for complete
>> headset support... also there have been complaints about
>> libalsa not scaling down for embedded systems.
>
> I'm new to alsa and gstreamer and I don't understand you yet.
> Can you point me to document you use? I just saw that volume control
> wasn't available with alsa-plugin if this is what you mean.

the link above goes into gstreamer and there's a good document for app
writers. it is complicated but I think it will serve the purpose well.

we may have to use "soft" volume control by manipulating the stream
before encoding it. there should be a plugin for this. i've tried to use
avrcp to control volume without any luck.

> However, I mainly worry about the following points :
> * I do not get 2 apps with a2dp output on the same address. As
> devices seems to manage only one socket, the second app will generally
> crash. Could we implement some sort of mixing or application selection
> (the foreground app or the first app started on an address, but with
> proper error handling for the others)?

we either need a sound server or we need a plugin that can use ipc so a
single instance is actually transferring data to the headset. i know
alsa can't do the latter but i'm not sure if gstreamer helps.

> * How to select whether the application will output on a2dp or
> speaker? Should this be application related or system related?

system. we need a way to change it while an app is outputing sound.

> * What you told me with gxine may vary depending the
> application. I believe one way to handle this is to maintain
> asynchronous connection to target sink. The api would just enqueue the
> audio packets into a common shared queue (per target). The connection
> simply close when there are no more audio packets.

yes. a sound server or mixer plugin via ipc could enforce this behavior.

> Did you change something since 0.42?

not yet

brad


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-08-02 14:08:55

by Brad Midgley

[permalink] [raw]
Subject: Re: [Bluez-devel] A2DP and Alsa Plugin

Frederic

>> I've read about ALP. It looks exciting. I was glad to see ALP
>> will include gstreamer as part of the foundation. You should
>> help me write proper gstreamer plugins.
>
> I did not worry about gstreamer as I tried the gstreamer
> alsasink yesterday. This allow you to create a graph with either
> bluetooth output or alsa output without modifying your .asoundrc. Just
> modify the device field. One address only as set in filename.

I was just cleaning out my mailbox and saw this discussion.

Is the memory footprint acceptable when introducing the alsa dependency
on your embedded platform? In my experience lib-alsa itself builds to
about 800KB on arm. The difference in cpu load is probably negligible.

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