Sharing sound hardware
Ryan Gammon
rgammon at real.com
Sat Feb 5 02:10:32 UTC 2005
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
More information about the fedora-devel-list
mailing list