[gst-devel] testing the plugin limits for bluetooth

[Brad Midgley]

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.

- 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.

- 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?

brad