On 2014-07-31 12:15, Alexander E. Patrakov wrote:
2014-07-31 14:46 GMT+06:00 David Henningsson <[email protected]>:
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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
