[pulseaudio-discuss] "passthrough" audio (eg. AC3 / DTS / WM9)

[Lennart Poettering]

On Mon, 05.10.09 05:11, Sean McNamara (smcnam at gmail.com) wrote:

> I would surmise that PulseAudio is probably not for you if you want to
> do this. There is no optional mixing in PulseAudio; everything is
> mixed in software. I don't even know if PA has a way to tell client
> applications "sorry, but the soundcard is being used excuslively by
> another PA client right now". 

Uh, not sure why this would be desirable, but if it is, it is very
easy to write a module for this, probably not more than 20 lines or
so.

> Unless we had some way to do software mixing on other encodings like
> AC3 and WM9 (we'd have to code up special cases of the mixing logic
> for _each_ supported format), supporting arbitrary audio data
> formats would be eliminating the usefulness of 99% of PA's existing
> modules and features, which expect PCM samples.

Uh, not sure where you came up with "99%". Yes we currently only deal
with PCM. But the parts dealing with PCM are limited nonetheless and
the APIs can be extended to support encoded audio, too.

> As a matter of fact, it's relatively simple to write a daemon that
> accepts UNIX socket or TCP connections, reads audio data supported by
> a hardware decoder from the socket, and passes the data to ALSA. At
> least, I think it would be easier to develop such a daemon from
> scratch than it would be to modify PA to support what you're asking
> for.

Uh. That is bogus. Encoded audio is in many ways just another type of
audio. And hence it should be handled the same was as we already
handle PCM.

In fact, codec support in PA will come. Probably even in the near
feature, as I started to hack on that on my train ride back from the
BlueZ summit. In fact, at the BlueZ summit it became very clear that
having codec support matters. We need it for SPDIF, we need it for
HDMI, we need it for Bluetooth A2DP, we need it for UPnP AV/DLNA, we
need it for embedded hw where there is specific sound hw that natively
speaks codecs.

So, it is not a question whether this will come, it's more a question
when.

The complexity in adding this stems from the fact that deducing timing
information fromt the codec is not trivial. In fact the lower layers
(alsa) don't really handle that properly either and for the PA case
this becomes even more complex since we rely much more on that.

Lennart

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