All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brad Midgley <bmidgley@xmission.com>
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] A2DP and Alsa Plugin
Date: Fri, 12 May 2006 11:10:45 -0600	[thread overview]
Message-ID: <4464C195.1020403@xmission.com> (raw)
In-Reply-To: <7A6DA545D7FDCC4B93DB651FDBC1EDDE46C2E7@eumonex01.palmsource.com>

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

  reply	other threads:[~2006-05-12 17:10 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-11  9:15 [Bluez-devel] A2DP and Alsa Plugin Frederic Dalleau
2006-05-12 17:10 ` Brad Midgley [this message]
2006-05-17 16:51   ` Frédéric DALLEAU
2006-05-17 17:40     ` Brad Midgley
2006-05-29  7:02     ` Brad Midgley
2006-05-30 10:20       ` Frédéric DALLEAU
2006-05-30 16:38         ` Brad Midgley
2006-05-30 20:28         ` Brad Midgley
2006-08-02 14:08 ` Brad Midgley
2006-08-02 14:54   ` Frédéric DALLEAU
  -- strict thread matches above, loose matches on Subject: below --
2006-05-10  8:17 Frederic Dalleau
2006-05-10 17:49 ` Brad Midgley
2006-05-05 12:38 Frederic Dalleau
2006-05-05 17:24 ` Brad Midgley
2006-05-04 15:58 Frederic Dalleau
2006-05-04 17:19 ` Brad Midgley
2006-05-04 15:34 Frederic Dalleau
2006-05-04 13:30 Frederic Dalleau
2006-05-04 14:36 ` Brad Midgley
2006-05-04 14:50 ` Brad Midgley
2006-05-04 15:20 ` Brad Midgley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4464C195.1020403@xmission.com \
    --to=bmidgley@xmission.com \
    --cc=bluez-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.