Sharing sound hardware

[Ryan Gammon]

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 at real.com
Developer for Helix Player
https://player.helixcommunity.org