Re: Pulseaudio

[Lennart Poettering <mztabzr 0pointer de>]

On Sat, 13.10.07 00:23, Gustavo J. A. M. Carneiro (gjc inescporto pt) wrote:

Hi!

>   But I would be interested to know why PA hogs the sound device.  No
> one explained this yet, and is the #1 question in my mind.  As far as I
> can tell, though I admit I'm no expert and could be wrong, PA should be
> able to access the sound device without locking it, like any normal
> application.  To put it simply, PA over ALSA/dmix.  If dmix was

Uh? dmix locks the device too.

<snip>
$ aplay -D dmix < /dev/urandom &
$ aplay -D hw:0
aplay: main:545: audio open error: Device or resource busy
</snip>

> underneath PA, couldn't you still keep doing all those neat things
> anyway?  The way I see it, only applications using ALSA directly don't
> benefit from PA's features, but at least it would work.

PA is about latency. To get the lowest latency possible, you want to
sit as near as possible to the hardware, do as little copies as
necessary and because we are a real-time system we also want to take
as little locks as necessary. Thus we mmap() the hw buffer of the
sound card if possible. However, dmix requires multiple buffers (hw,
saturation), i.e. copies, we cannot really mmap it, needs locking (on
smp) and is just yet another layer between PA and the hw. Also dmix
forces a fixed fragment setting to PA. Also nothing we really want.

But you know what? You're welcome to configure PA so that it goes
through dmix for playback. It's not what I'd recommend, because i'd
recommend to do it the other way round, redirecting output of all alsa
apps to PA, but you're welcome to configure it in every way you want.

>   Every time I bring this issue the reply is usually "but you don't need
> to do that because of this and that", not an actual explanation of why
> it can't be done.

It *can* be done. But as explained above, it's not what is good for
latency. To keep your latencies low you want only a single RT thread
accessing your audio devices, and not one system stacked on the other
stacked on the other stacked on the other.

>   One use case for the above would be (non-free) flash plugin running as
> 32-bit program with nspluginwrapper attached to an amd64
> epiphany/firefox.  Unless you have also PA libraries and alsa plugin
> replicated in /usr/lib32, audio won't work if you are redirecting
> everything from ALSA to PA...  Yes, I know non-free flash plugin is
> evil, but you can't easily escape it these days... :-(

As mentioned in my long email we ship a pa plugin for flash in F8,
that even works with multilib. This is a non-issue.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4