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