[pulseaudio-discuss] [PATCH] fix profile configurations for IEC/SPDIF outputs

[Colin Guthrie]

'Twas brillig, and pl bossart at 21/06/10 21:59 did gyre and gimble:
> On Mon, Jun 21, 2010 at 1:16 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
>> 'Twas brillig, and Tanu Kaskinen at 21/06/10 18:35 did gyre and gimble:
>>> Didn't Coling specifically ask proposals NOT involving passthrough?
>>
>> Yup :), and as I was heading home today I thought of a good example: games!
>>
>> Sadly Jens beat me to posting it here :D
>>
>> But I think games are a very specific case and while it's not a primary
>> case, it's one to be considered. I think the passthrough case is likely
>> the most important (especially in the short-term), but perhaps
>> approaching the design with the non-passthrough case in mind will allow
>> for a cleaner overall implementation? (I really don't know enough about
>> how it will flow through PA to say this for sure - so just a thought... :))
> 
> Thanks everyone for your comments. I don't really disagree with any of
> them, there are just some details where we are not in sync.
> Looks like we want to have the following supported:
> 
> 1. multichannel data (including but not limited to ac3/dts) -> decode
> -> downmix -> spdif/hdmi stereo

Yup. Not necessarily the most exciting or practical of "pipelines", but
I think, in principle, it has to be supported. What license restrictions
are there on ac3/dts decoding. I'm totally ignorant to this side of
things (tho' I do have an ex-Dolby contact I could probably tap for info
if needed).

> 2. multichannel data (including but not limited to ac3/dts) -> decode
> -> mix -> reencode with a52 -> IEC formating -> spdif passthrough
> pros: allows for all formats to be supported
> cons: power, MHz, complexity, patents/licensing cost
> works with iec958-ac3-surround-51

If by "a52" you mean the generic standard, yes. If you mean the alsa
plugin specifically, I'd say it's not strictly needed, provided the
functionality can be replaced by something else if appropriate (I think
a52 encoding in pulse itself was mentioned although perhaps it has
license issues so would have to be optional). It's just that a52 alsa
plugin is the only available system today that works with PA (that I
know off and for various values of "works") so if some folk have got it
working the general setup shouldn't be removed unless something better
replaces it :)


> 3. multichannel data (including but not limited to ac3/dts) -> decode
> -> mix -> hdmi multichannel
> not supported for now, there isn't a digital profile with multichannel
> PCM output.

Would certainly be nice for the future, but certainly no regression in
not supporting it yet.

> 4. ac3/dts data -> IEC formatting -> spdif/hdmi passthrough
> pros: limited activity on the source, power-efficient, no patent
> requirements on source
> cons: no mixing, formats limited to the ones supported by receiver and
> IEC standards.
> doesn't work for now. I would probably make sense to add a different
> profile that would be selected by the user if the receiver can handle
> such data.

Yeah I guess so. Having recently battled with passthrough in XBMC, I can
say that even taking PA out of the equation, it's not perfect. The GUI
likes to use sounds for key presses etc. (and I like it), but when using
passthrough the GUI has to release the device before the player starts.
AFAIK the GUI uses SDL, but the player does not (not 100% sure I've not
bothered looking in too much depth).

So for that reason it's nice to support mixing, but for the pure movie
case, pass through is clearly better and more efficient. Handing over
and switching between passthrough and remixed mode is clearly the
zenith, but for the same reason as on-the-fly sample rate changes are
not a nice idea, I'm not sure this approach could ever work here either.

So ultimately I guess a profile may be best. Connections that come in
once something is already running would I guess just be corked? This
could lead to some problems in some programs perhaps....

> Now that I understand what the a52 plugins does, in hindsight I should
> have kept it. No reason to remove it.

Cool.

> One thing that's pretty clear: the following profile cannot work
> [Mapping iec958-surround-40]
> device-strings = iec958:%f
> channel-map = front-left,front-right,rear-left,rear-right
> priority = 1
> SPDIF is stereo only, this one isn't possible unless encoding takes place.

Seems sane to me. It was added in the original rework commit and has
only changed for the device number change. So I guess it could just be a
thinko, unless some obscure h/w that Lennart has shome how supports this
(not sure if that's even possible!).


> The other issue is that using iec958 isn't great. On my laptop in some
> cases the receiver fails to detect AC3 data, it always works when
> using the hardware device.

Would that be an ALSA bug then?

> The only cases where you absolutely want to use the iec plugin is if
> you want to select a non-default output or set consumer/user bits,
> i.e. "iec958:{CARD=1,AES0=0x0f,AES1=0xff,AES2=0x00,AES3=0x00}"

I don't think it's so much wanting to use the iec958 prefix (I'm not
sure what the right name for "prefix" is, but it's not a plugin - its a
definition in the ALSA config scripts) as wanting to avoid using hw
devices, which are completely unreliable and entirely different on
different h/w. Using iec958 gives a consistent interface that (is
supposed to) always work across different h/w.

I think the important bit here is how the DEV argument is calculated.
ALSA does this for us, but from what I can see of the
/usr/share/alsa/pcm/iec958.conf file, all it does is setup a slave PCM
for the actual device.

Can you configure a manual slave PCM and have it fail in the same way as
you notice using the iec958: device? If not, then it's something to do
with the config that's borked, e.g. finding the default DEV argument.

Does setting "export ALSA_IEC958_DEVICE=n", bypass the failure? If so,
then that points at a problem with the:

                                @func refer
                                name defaults.pcm.iec958.device

bit of the config.

> Given that this is a profile, it would be hard to pass these AES bits
> and it would be quite a challenge to guess which non-default card
> would need to be used. Plus most receiver just ignore these bits given
> their general lack of reliability, and use the audio payload to
> synchronize and extract the required information.

It would be possible to set this bits in a fairly generic way via
profiles without too much effort I reckon, but from what you say it's
probably not worth the bother...

> And if you look at the a52 code you will see that there isn't any
> mandatory dependency on iec958. You can connect the a52 plugin
> straight to the pcm hardware device (which is what I am also doing).

Yeah, like I say all the iec958 stuff does is set the right device
automatically and setup a slave PCM.... connecting a52 directly to the
device just misses out this automatic device selection and the extra
slave pcm. So not really surprising.

> Along the same lines, HDMI should be handled in a similar manner, on
> most platforms this is going show as a different card.

Not all platforms show this as a separate card. I'm pretty sure I've
seen some that don't. Again hdmi: prefix is used here to set the right
device. Looking at the file, it seems to use the same
"defaults.pcm.iec958.device" and ALSA_IEC958_DEVICE env var to set the
device. Not sure if this is just copy/paste of if it piggy backs on to
this config....

> Overall I'd rather use some ENV variable or a field in daemon.conf to
> set which digital output to use rather than hard-code 'iec958' in
> profiiles

I really think iec958 is very much the *right* think to do. Have a look
at the alsa config files that set these things up. They are not rocket
science but they do allow this kind of thing to work, and perhaps the
ALSA_IEC958_DEVICE environment variable is exactly what you want but it
works *with* iec958, not against it.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]