On Wed, 2010-06-16 at 10:23 +1200, solor...@epic.geek.nz wrote:
On Wed, June 16, 2010 09:43, Steve Holdoway wrote:
... cant linux get it's sound sorted out properly?
I share your frustration with Linux sound. We started with OSS, which was
okay *if* you had a card that was supported. Then ALSA came along and it
was struggle for a bit in the beginning. To date it still has issues
playing from more then one source at a time. So several sound daemons
were made, esd, arts, etc. that tried to solve that problem. But then
they don't play with apps that need real-time access to the hardware.
And finally with the last few versions of Ubuntu there is a push for
pulseaudio which I think is utter rubbish. It seems to me the real
problem lies in ALSA's inability to work with more then one source. There
are some workarounds that disable ALSA from locking the card to one app.
The problem is deeper than just alsa...
Alsa has a plugin called dmix, which allows multiple applications to
open an alsa output stream at the same time; the individual sources are
added together.
Similarly, there is a plugin called dshare, which allows multiple
applications to open an alsa input stream simultaneously; the individual
applications get their own copy of the data.
This is an almost good enough solution. The problem is that dmix and
dshare can only operate at a single sample rate at a time. The sample
rate of the sound card is set by the application that first uses a dmix
device.
So if you try to play a DVD or other video source with a 48kHz audio
sample rate at the same time as a CD or other audio source with a
44.1kHz audio sample rate then suddenly the second application finds
that it cannot open the device because the sample rate that it wants
conflicts with the sample rate set by the first application.
Some sound cards (but not many) can have multiple streams operating at
different sample rates. Your typical cheap sound card has a single
stream in each direction that runs at a single sample rate.
Now, alsa has other plugins that do sample rate conversion. So you could
set up a chain of alsa plugins as follows:
DVD-player -- dmix (48 kHz) -- sample-conversion (48--44.1) -- dmix
(44.1) -- sound card
CD-player -- dmix (44.1) -- sound card
Then applications could open either the 48 khz or the 44.1 kHz dmix
device and everything would be fine. However, the application would have
to know to open a different audio device depending on the sample rate. A
music-playing application might have audio sources with BOTH sample
rates, so it would have to open both devices.
A further problem is that these plugins are set up in configuration
files (/etc/asound.conf, ~/.asoundrc). So if someone wants to play or
record at 22050, 24000, 88.2 kHz, 96 kHz sample rate and who knows what
else, he has to modify the config files. And then my digital camera
records audio at 11024 (rather than the more logical 11025 which is 1/4
of CD sample rate)...
You have a similar problem in the reverse direction for audio input --
if we want to record audio for digital video and CD simultaneously.
JACK provides a robust mechanism for coordinating audio at the sample
level between multiple applications, and is ideal for studio-grade
applications. However, it operates at a fixed sample rate and hence does
not solve the DVD-CD sample rate mismatch. It relies on the applications
to do sample rate conversion, or more typically, for the user to ensure
that all his sources use the same sample rate.
Now pulseaudio can provides multiple alsa-compatible devices and does
automatic sample rate conversion and sound-card sharing. It also does
esd-compatible network audio input and output, so that when I am logged
into my Linux box from a Windows box (using Cygwin/X and puTTY), I can
play a video on the Linux box that displays on the Windows screen, and
the sound comes out of the Windows sound card.
So, I believe that pulseaudio really does provide useful functionality.
But it all comes at the cost of higher latency, complexity, and bugs as
the system gets itself worked out.
Stephen Irons
