[gst-devel] testing the plugin limits for bluetooth

[Brad Midgley]

Stefan,

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

It should work in any app that is a gstreamer client (video player,
internet radio, etc.) I was hoping connecting a headset could be done at
a system level.

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

If making the switch is done at a system level not an app level,
wouldn't we have to decide which active bin-element to switch into
bluetooth mode? It sounds like only one app would use the headset at a
time without ipc.

Instead of making the switch at a system level, maybe a better fit is a
specific means to connect to a headset that only one app at a time can
choose, like choosing a bluetooth "sound card" from inside the app.

In any case, after connecting, the app will be able to get events from
the headset (forced disconnect, pause, answer-button) either via dbus or
the event mechanism in gst. Is dbus preferred for this?

> Okay then you want to have a bluetooth audio sink that changes its caps
> sink-caps accordingly.

ok, that's what I was thinking too.

>> 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 :)

Too bad. ipc mixing like dmix looks like a tough problem.

I would like to work with what we've got and give up the idea of
multiple simultaneous clients using one bluetooth device for now.

Brad