[pulseaudio-discuss] digital devices (spdif)

[Lennart Poettering]

On Sat, 03.01.09 10:45, Jens Peters (jpeters7677 at gmx.de) wrote:

Heya!

> I wonder actually if there are any decisions made regarding AC3/DTS pass-
> through and may be life encoding. The only outsider regarding sound 
> output is AC3/DTS where I talk directly to alsa (mplayer -ao alsa -ac 
> hwac3,hwdts,). It would be very cool if I could do something like mplayer 
> -ao pulse -ac hwac3,hwdts,. The stream would show up in pulse control and 
> I can imagine that even moving the stream to another (digital) output 
> could realized. Obviously any other normal output on a digital output 
> would have been muted/discarded when pass-through output is started (At 
> the moment I have to make sure that there is no active output before 
> starting pass-through output). A second pass-through stream should also 
> be muted/discarded until the output is free again. (Actually I guess this 
> is the same work-flow as on Windows). I read somewhere that a big 
> showstopper for this is the detection of digital devices. Why not just 
> adding a module parameter for that, because I guess that most users, 
> including me, already have to add the digital output by hand, so e.g.: 
> load-module module-alsa-sink device=iec958:0 capabilities=spdif,..
> until hal/alsa gives some more information.

The first part is to support SPDIF at all (i.e. for PCM), the next
step is than to add pass-through CODEC support. It is rather unlikely
that we will add compression/decompression support for codecs
other than the free ones (vorbis) anytime soon. That means
pass-through support for AC3/MP3 is all we can do, i.e. no volume
control, no mixing, no nothing.

As mentioned the problem is that we cannot really detect which setups
of a device are incompatible with each other and which ones are
not. My plans for the Fedora 11 release is to add easy support for
changing these setups, and -- for the ALSA case -- detect them at
initialization time by trying since that's the only option we have
right now. I.e. we try to open the sound card for playback/capturing
in different configurations (such as Stereo, 7.1, SPDIF, for playback
and capturing) and see what works together. Then we compile a list for
that and allow the user to quickly select one of the available
configurations for each device during runtime and without
interrupting playback. The list could look like this as one example:

  Analog Stereo Playback, Analog Stereo Capturing from Line-In
  Analog Stereo Playback, Analog Stereo Capturing from Microphone
  Analog Surround 7.1 Playback
  Analog Surround 5.1 Playback
  Analog Surround 4.0 Playback, Analog Stereo Capturing from Line-In
  Analog Surround 4.0 Playback, Analog Stereo Capturing from Microphone
  Stereo PCM SPDIF Playback, Analog Stereo Capturing from Line-In
  Stereo PCM SPDIF Playback, Analog Stereo Capturing from Microphone

Many sound cards can either do surround or full duplex but not
both. That's why the list above has no capturing when playback is at
5.1/7.1.

The list above is manufactured, I am not sure if the list might not
actually explode in a real life example because we try to serialize an
n-dimensional configuration into a linear list. But even if it would,
it's not getting thaaaat large and this could be fixed by the UI.

And with the ALSA ac3 plugin we could even silently add support for
doing on-the-fly AC3 compression for SPDIF.

> Additionally having a post-processing module like ladspa for live 
> encoding like the windows counterparts Dolby Digital Live of even better 
> DTS Connect would made pulse the _real_ audio control software imho. But 
> I already read about license issues, I don't know what possibilities are 
> there :(  

I don't think PA is the right place to do matrix
encoding/decoding. But if someone provides me with a good patch and
the patent situation is somewaht clear I might be convinced otherwise...

Also note that ALSA has an ac3 plugin.

Lennart

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