Hi guys,
I've been catching up on my mailing list reading on fedora, helix, and general sound server interaction, and saw a couple threads of interest from late last year.
I'm curious to know what the current fedora thinking is on software mixing & sharing sound hardware, particularly with sound devices that don't have any hardware mixing support.
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.
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.
2. Pausing was generally broken
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.
4. Decent alsa documentation was generally lacking.
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.
In terms of what we currently support in helix on linux we have:
- OSS support
- Esound support (works for audio only, not usable for good quality AV playback)
- Usound support (contributed by Matt Campbell, http://mattcamp.paunix.org/usound/)
- ALSA support
... of which we're only shipping OSS.
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
- 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
- Have good sound latency information, enabling good AV sync
- Be generally solid in terms of pausing & restarting playback
- Be documented :)
I'm very interested in what others are thinking here for fedora, be it alsa-related or otherwise.
-- Ryan Gammon rgammon@xxxxxxxx Developer for Helix Player https://player.helixcommunity.org
