Hey Ryan, I'm no ALSA expert and in fact I have a hardware mixing soundcard but for various reasons I'm interested in dmix. On Fri, 2005-02-04 at 18:10 -0800, Ryan Gammon wrote: > From where I'm sitting, there's some appeal to the alsa asym / dmix > solution that I've seen discussed. > > The alsa api, while pretty complex, gives good access to all the > features a given piece of hardware supports. The fact that alsa has an > awareness of the hardware it's running on gives it the ability to > (eventually) be smarter when it comes to things like mixing in hardware > vs mixing in software. This is a bit contentious. Rumour has it (i.e. I've seen other people saying this in forums rather than actual ALSA developers) the ALSA folks want to keep hardware mixing and software mixing apart rather than doing a Windows like fallback of hardware mixing where possible and software mixing if not. As I said, I haven't talked to (or seen mention by) any ALSA devs about this so it amounts to nothing more than gossip. > I did some playing around with dmix last year when I was touching up > helix's alsa support, and found it to be pretty buggy on the alsa side. > > Some of this may be incorrect, but as I recall: > > 1. libasound forks what is basically a sound server process when the > sound device is first accessed, but it does not exec. This was not > working well with helix -- by the time helix opens the sound device, it > has several threads running and a number of plugins loaded. Alsa's mixer > process was hanging when forked from helix, for reasons I never figured out. You have to be a member of the helix community in order to get a prebuilt helix player that supports ALSA don't you? I would have liked to have tested this because apparently dmix has had various fixes in the past few months to make it more robust (I think in FC3 it was prone to lockups so it was not enabled by default)... > 2. Pausing was generally broken I haven't tested this so I can't comment. > 3. The first process to play back sound defines the characteristics of > the sound device device. If it open up the device at a low sample rate, > all playback would suffer. Does it? I thought it was fixed in a configuration file (I'm not an ALSA developer or someone who develops apps with ALSA - I'm just looking at http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html#pcm_plugins_dmix ). Perhaps apps should try and work with whatever it defaults to. > 4. Decent alsa documentation was generally lacking. Still lacking from the sounds of it. It's a common complaint : ( > At the time, I fooled around with using esound + alsa + dmix, with > esound set up to always hold the sound device open, and with the alsa > sound server running in a forked esound process. > http://bugzilla.gnome.org/show_bug.cgi?id=140803 > http://sourceforge.net/mailarchive/message.php?msg_id=8898607 > > Currently, the helix we ship with RealPlayer 10 is built to use OSS, as > it's generally the lowest common denominator. We rely on sound servers > like esound releasing the sound device when not in use. I have to inject here. For legacy reasons wouldn't it be better to support esd? Then you would get artsd support for free (sure it will latent but it's better than nothing) and support old OSS systems. Newer systems with ALSA would get ALSA (with dmix) support. (goes away and reads posted links) Heh. You already know this and are submitting patches to make this work. I guess that tells me... > Ideally IMHO dmix / asym would: > - Be a sound server that runs on startup instead of something that forks > off the first process to open the sound device I think you might be better off suggesting this on the alsa-devel list. I don't know if Fedora could afford to deviate too far from upstream ALSA packages so the best thing would be to have a change like this come "down" from upstream. I suspect this won't be a popular idea because the "server-less" set up of dmix appears to have been done for design reasons (low latency problems, no need for RT priorities). I'll give a link in a minute. > - 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 This doesn't sound like it will happen with dmix (although it could with another ALSA plugin). In the UKUUG paper "Sound Systems on Linux" (http://www.ukuug.org/events/linux2003/papers/TIwai/soundsystems/ ) Takashi Iwai talks a little about the rationale behind dmix. It sounds like the aim is to be simple so existing ALSA apps do not have to be rewritten, low enough latency for consumer use and free of RT-scheduling requirements. > I'm very interested in what others are thinking here for fedora, be it > alsa-related or otherwise. My general take on things so far has been tainted because although helix and real player work great on hardware mixed cards the lack of shipped support for esd/artsd has users wondering why things like real player don't start when they are streaming a radio station in their web browser ('cos the sound device is locked and there's no hardware mixing is the answer). I dearly hope that dmix is shipped in a working default configuration soon because software mixing has always been one of those annoying issues on Linux. My brief experience as a dmix user suggests that it provides the nearest solution for reasonable software mixing in a variety of applications with only binary legacy non-ALSA/esd applications suffering. The downsides of shipping dmix by default in FC4 today appear to be potential inefficiency on hardware mixing cards, sound quality degradation for those that want to do their own resampling and breaking things for people with a second sound card. These trade-offs look reasonable in the short term though. Really, FC4 should not be shipping with apps that don't support dmix'd ALSA or esd and defaulting as much as possible to use ALSA rather than anything else (whether this is a reasonable thing is another question though). I suspect the number of sound servers for typical applications will eventually drop to two - whatever ALSA usually supplies (virtual or otherwise) and esd. Rumour has it that KDE will drop artsd and move to gstreamer and since gstreamer supports both esd and ALSA out of box sound experience on typical consumer hardware should stop being such a mess. -- Sitsofe | http://sucs.org/~sits/
