Sharing sound hardware

[Ronald S. Bultje]

Hi Ryan,

On Sat, 2005-02-05 at 03:10, Ryan Gammon wrote:
>  From where I'm sitting, there's some appeal to the alsa asym / dmix 
> solution that I've seen discussed.

(nod here. Same seems to be true for GNOME on the Linux-side.)

> 2. Pausing was generally broken

Hm, do you mean the ALSA paused state? As far as I know, Dmix doesn't
implement that. You're supposed to just stop playback alltogether when
paused. Not ideal, admittedly, but appears to work.

> 4. Decent alsa documentation was generally lacking.

Kernel documentation is still lacking poorly. There's library reference
API, and the server is sometimes even turned on, so they're making
progress. There's no good example code documentation or programming
guides. On the good side, alsamixer et al are liberally licensed, so you
use those for inspiration.

Note that I've faced those exact same problems, plus a lot of
instability and erronous behaviour inside ALSA, and I've found ALSA to
vastly improve on those fronts over the last year.

> Ideally IMHO dmix / asym would:
[..]
> - Open the sound device using sensible maximum capabilities of the 
> device in terms of sampling rate and # of channels, etc. The guys who 
> write our resamplers generally prefer to have helix doing any sample 
> rate conversion where possible:
> http://lists.helixcommunity.org/pipermail/audio-dev/2004-March/000243.html

Would fixed-samplerate do (e.g. fixed to 48kHz)? 99% of the users won't
notice the difference if you're using a reasonably good resampler. On my
computer (don't know if this is generally true), dmix operates on a
fixed samplerate, regardless of playback.

For the future, ALSA is definately the way to do. It's a pain to get
fully stable, still, but it's getting better. I've ended up debugging
some ALSA issues, but the result isn't too bad really.

Cheers,
Ronald

-- 
Ronald S. Bultje <rbultje at ronald.bitfreak.net>