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

[David Henningsson]

On 2014-07-31 12:15, Alexander E. Patrakov wrote:
> 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

Ok, my bad. Sorry.

>> 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.

Ouch. :-/ Interesting problem, though.

>> 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.

Ok. Well, then using dcahdmi is okay.

I went to test and then commit your patch, but I noticed that our test 
case alsa-mixer-path-test started failing. Did you forget to ship the 
new hdmi-output-*.conf files?


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic