[gst-devel] testing the plugin limits for bluetooth

[ensonic]

hi brad,

On 9:46:31 am 24/05/2006 Brad Midgley <bmidgley at xmission.com> wrote:
> Stefan
>
> Thanks for the note.
>
> >>  I'm trying to make a case to a palmsource developer for doing all
> >>  the bluetooth audio stuff natively in gstreamer (as opposed to
> >>  using our alsa plugin indirectly)... any help here would be great
> >>  for steering that effort.
> >>
> >  What is the problem with a bluetooth headset appearing as an
> >  alsa-device? Imho this is the way to go and then use gst on the
> >  appliation level.
>
> It looks to me like alsa is too limiting, but please tell me how you
> think some of these problems apply:
>
> - stereo bluetooth requires compression; the codec is negotiated at
> connect time. Alsa plugins only accept raw audio. If we use alsa
> devices, we may end up with a situation in which gst decodes an mp3,
> writes raw audio to the alsa device which then reencodes an mp3 and
> transfers it to the headset.
>
Do you still have not answerded one question. Do you wan't this to work
with any application? Or just for some specific apps. This decission then
dictates wheter the application has to handle some cases or if all has to
be handled in the element. I think transparently switching from and to the
bluetooth-sink would probably best be done as a bin-element (like playbin).
Have a bluetooth aware audiosink bin. If apps use that, it could handle
auto-plugging decoders/encoders for mp3 and also do the sink switching.
>
> - gst provides for multiple codec implementations, such as a
> commercial codec or one using a dsp. We lose this by forcing all the
> codecs into our alsa plugin. This requires recompilation and possible
> license conflicts when vendors want to make use of their own codecs.
>
Okay then you want to have a bluetooth audio sink that changes its caps
sink-caps accordingly.

> - ALP and maemo use gstreamer and they are a big target. I'm not
> totally sure, but it looks like nokia does not use alsa at all in
> maemo (instead they use a dsp plugin for audio i/o). Introducing alsa
> requirements here is onerous for embedded platforms that are already
> hurting for resources.
>
> >>  * Audio sent by multiple apps gets mixed and is transmitted to the
> >>  headset by a single process/thread.
> >  can one use dmix via a bluetooth device? Gstreamer provides mainly
> >  interprocess stuff.
>
> dmix uses ipc to converge the streams to a single thread and is great
> engineering within the constraints of alsa. Are you saying gstreamer
> also has an ipc equivalent?
>
I has not, thats why I was suggesting alsa in the first place :)
>
> brad
>
Stefan