[pulseaudio-discuss] [PATCH] alsa: Add extra HDMI mappings

[Alexander E. Patrakov]

2014-07-31 14:46 GMT+06:00 David Henningsson <david.henningsson at canonical.com>:
>
>
> On 2014-07-30 20:36, Alexander E. Patrakov wrote:
>>
>> Add DTS-encoded profiles (they need dcaenc from git).
>>
>> The use cases for DTS over HDMI are:
>>
>> 1. Radeon driver on old kernels, with no support for multichannel PCM HDMI
>>     audio.
>> 2. A TV that acts as a converter between an HDMI-connected computer and
>>     an SPDIF-connected receiver, with no other way to connect the
>> components.
>
>
> You never mentioned this before, and I haven't heard anyone asking for it
> either.

I have mentioned it, and Tanu ACKed it, see
http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-July/020915.html

> OTOH, dts encoders are probably not installed by default on any common
> distro except very media focused ones (e g OpenElec, XBMC and such), and if
> you're manually installing the dts encoder or running a media center distro
> then maybe this is interesting.
>
> Also, there are probably HDMI cards out there that only support stereo LPCM
> in hardware but I'm not sure how common it is.

That's the same as "Radeon on old kernels".

> So I guess it's okay, but it wouldn't hurt with more opinions about how
> common dts really is over HDMI.
>
> Also, have you tried this yourself so you know that pulseaudio works well
> enough with the dca encoder? We don't want crashes.

That's how I test it at home. The case already covered in stock
PulseAudio (DTS over SPDIF) is something that I can't test myself but
that's reportedly working for others.

As for crashes, the only known case is related to the CPU usage (see
e.g. https://plus.google.com/105465824670275586186/posts/EG7nT9TXTpd
). However, the CPU frequency scaler aggravates the problem: it starts
from a high CPU frequency, sees that the CPU usage is low enough from
its viewpoint, and tries to lower the frequency. But then, if it goes
all the way down, the resulting CPU usage becomes around 30% (for the
same computational load), which is too high from the viewpoint of the
realtime killer.

>> +[Mapping hdmi-dts-surround]
>> +description = Digital Surround 5.1 (HDMI/DTS)
>> +device-strings = dcahdmi:%f
>> +paths-output = hdmi-output-0
>> +channel-map =
>> front-left,front-right,rear-left,rear-right,front-center,lfe
>> +priority = 1
>> +direction = output
>
>
> Just a question about the dcahdmi:%f stuff - isn't the "dca" definition
> flexible enough that you can just use dca:hdmi:%f instead of dcahdmi:%f ?
> That way it should work with earlier versions of dcaenc too?

Unfortunately, no. The definition of "dca" in both versions explicitly
stacks on top of iec958. I can try to make a new PCM definition that
does stack, but then I'd have to name it differently ("dcaenc"
perhaps?). And then I'd have to pass the user-settable AES0..AES3
parameters somehow down to the slave (and unfortunately there are no
settings that work for all receivers), and I don't know the syntax for
that.

-- 
Alexander E. Patrakov