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@xxxxxxxxxxxxxxxxxxx>
