Re: [Bluez-devel] CVS audio-api.txt : 1st question

Fabien Chevalier
2007-07-11T17:33:52Z

Hi All,

Please find below some comments

>> Mikko L at Nokia basically said they wouldn't consider anything along
>> these lines since it gets so complicated when a system sound needs to
>> interrupt mp3 playback. Do you:
>>
>> - mix two mp3 streams together (technically possible)
>> - reconfigure the set for sbc and encode the streams to sbc (best
>> case is a delay, worst case a crash in the set during reconfiguration)
>> - stop the mp3 player and play the system sound mp3 instead (tricky)

I agree with you : none of those are acceptable. However you may have
missed something : MP3 is not to be used as an output format if
bluetooth is plugged to a sound mixing daemon :-).
In this case SBC is to be used :-)

The only valid case of MP3 streaming is the one when you build a
dedicated audio path between the application(multimedia player) and the
hardware device(bt headset). In this case there is no notion of "system
sounds" that would appear and would need to be mixed in :-)

>>
>> It doesn't help that there's not much notion of a sound "card" that
>> can natively decode mp3. The audio servers don't account for this
>> possibility at all.
>
> I wont consider going with gstreamer set of elements instead of an
> alsa plugin for system wide

My remark was not one against the other.
Obviously there are so many ALSA applications that an ALSA option is a
must have. :-)
However a decicated gstreamer support would be nice to have, too.

, as you said we might have some
> technical challengers and as a sound "card" this is not exactly a
> good idea. So as a system wide solution we must have a alsa plugin
> that just deliver sbc codec.

Agreed. Alsa plugin should implement sbc codec only (no mp3 needed here
:-) )

>
> A future work perhaps we may be possible to deliver something more
> flexible to application, but in this case application would have to handle
> the stream by it' s own.

Like a GStreamer based application for instance, that is already used to
build its own media pipeline :-)

>
> Why Im already considering this advanced usage? We have an ipc
> system that should be flexible enough to be able to work with
> those applications.

Agreed. We should be able to plug whatever system using this ipc
mechanism, including:
- an ALSA plugin
- a GStreamer bt element
- a sound server

> I guess it should be possible for someone to
> add native support for multimedia frameworks such as gstreamer,
> but the support itself is outside the scope of bluez.
>

I guess one of those days i'm gonna hack a gstreamer element just for
fun :-)... and to prove it's feasible :-)

Cheers,

Fabien