I just thought about something like that... There should be a
possibility in headsetd or maybe the plugz, that would switch to a
fallback device, if the headset can't be connected (it's switched off or
whatever). The way it's working now - dropping the stream to /dev/null
or wherever is not a wanted behavior, when someone calls You on a softphone.
--
Cheers,
Michał Sawicz
Marc-André Lureau wrote:
> This kind of stuff are upper level management. Even ALSA do not handle
> this properly (if you plug/unplug a usb device). That's why all the
> major distributions will ship with PulseAudio installed.
I must say I'm impressed... I hope PA will get into mainstream real soon.
--
Cheers,
Michał Sawicz
On 2/5/07, Micha? Sawicz <[email protected]> wrote:
>
> I just thought about something like that... There should be a
> possibility in headsetd or maybe the plugz, that would switch to a
> fallback device, if the headset can't be connected (it's switched off or
> whatever). The way it's working now - dropping the stream to /dev/null
> or wherever is not a wanted behavior, when someone calls You on a
> softphone.
This kind of stuff are upper level management. Even ALSA do not handle this
properly (if you plug/unplug a usb device). That's why all the major
distributions will ship with PulseAudio installed.
My POV is that we need to focus on the io audio stream interface and provide
a standard Linux device (with HAL and ALSA). The underlying headset/audio
device can be accessible as any simple pcm device (with ressource
constraints that already exists).
Mixing, routing, device abstraction, sample rate conversion and even
encoding... should be handled by upper level applications.
If you want to join the design discussion, we could have a FAQ in the
http://wiki.bluez.org/wiki/Audio wiki. Please feel free to add your
comments&questions there (this is still very *drafty* btw)
Regards,
--
Marc-Andr? Lureau, GSmartMix