alsa: AC3/DTS passthrough over HDMI plays noise

[ghost]

I've tried with both vlc (--spdif) and mpv (--ad=spdif:ac3,spdif:dts). According to #528, passthrough over ALSA should work now, so this might be a regression or a rather tricky configuration issue.

I tried this on Raspbian. I had to add this config file to /usr/share/alsa/cards/, as Raspbian seems to be missing it: https://gist.githubusercontent.com/julianscheel/9094131/raw/af99299b11d32693abb07481698b1f963a423076/bcm2835.conf (As I understand, the AES0 flag should cause the driver and firmware to send the data formatted correctly for passthrough.)

I couldn't test kodi over ssh, but from what I'm seeing it uses OMX for audio output anyway.

The same file, player code, and receiver works on a real computer using Linux and ALSA.

I've run apt-get update && apt-get dist-upgrade && rpi-update before testing this. uname -a shows: Linux raspberrypi 3.18.14-v7+ #793 SMP PREEMPT Sat May 30 14:04:35 BST 2015 armv7l GNU/Linux

If it matters, my config.txt has the following entries:

hdmi_drive=2
avoid_warnings=2
gpu_mem=320
no_hdmi_resample=1
hdmi_stream_channels=1

[ghost]

I can add that I can change the loudness of the noise with alsamixer.

[popcornmix]

@julianscheel is alsa passthrough still working for you?

[julianscheel]

@popcornmix I just had a quick test and it works for me. But I am not yet on the latest raspberry kernel, but running 3.18.5 plus firmware from May 18th. I'll try to rebase my kernel today and post an update then.

[julianscheel]

@wm4 Just one thing that popped to my mind: How is your PCM mixer set? This must be set to 0.00dB when using passthrough. If not, the gpu firmware tries to apply a softvolume onto the datastream, which obviously breaks encoded streams.

@popcornmix Do you think it might be easily possible to disable the application of volume when the gpu is set to non-audio mode?

[ghost]

How is your PCM mixer set? This must be set to 0.00dB when using passthrough. If not, the gpu firmware tries to apply a softvolume onto the datastream, which obviously breaks encoded streams.

You are correct. If I do that, it works. Apparently my receiver accepts the compressed data even if I don't pass the AES0 flag to the ALSA device (switching between PCM and DTS works just fine).

So I assume the problem is that the kernel doesn't disable extra processing when the correct AES0 flag is set. Sure, applications could somehow make sure to reset the mixer control, but that would be messy. Especially if the application would have to restore the volume too. Also, this is platform-specific (not good for a generic API like ALSA), and it could be that further mixer controls are added in the future, which are not known by the application. This puts the application completely out of control whether processing is enabled. I think having this logic in the kernel instead (or the firmware?) would be the best way to handle this.

Should I close this issue and make a new one, or should we reuse this issue?

[julianscheel]

@wm4 I think it's ok to keep it in this issue...
Personally I think it would be better to handle it in the firmware itself. The mixer is a PCM mixer, so it should be applied to whatever stream that is actually of type PCM, but not to others. The firmware should be able to distinguish this by using the channels property. What do you think @popcornmix ?

[popcornmix]

Sounds reasonable. Hopefully no one is using the passthrough mode for non-passthrough audio and will complain about the loss of audio.

I've not tested this. Is it possible you could check if it behaves as expected:
https://dl.dropboxusercontent.com/u/3669512/temp/firmware_alsa_passthrough.zip

[julianscheel]

@popcornmix They wouldn't loose the audio, but just the ability to attenuate the audio. Setting the mixer to 0.00dB means no attenuation/amplification, not muting it.

[popcornmix]

Sorry - I meant loss of audio volume control - I just stopped typing too soon...

[ghost]

This sounds perfectly acceptable, as long as outputting normal PCM via normal ALSA API usage switches back to PCM with processing mode.

By the way, does anyone know how to set the AES0 flag on a "normal" PCM device? It seems the ALSA API rejects the AES0 parameter in this case. Only the iec958 wrapper device (from bcm2835.conf) works. This makes it a bit hard to make device selection and ac3/dts passthrough orthogonal in a high level application. (This is probably not RPI specific.)

[julianscheel]

@wm4 I don't think that is possible. You have to make use of the iec958 device to be able to select AES0. So your application should select the audio device according to what you want to output.

[ghost]

That's pretty weird. What if there are multiple devices which can do passthrough? What device would you use then? (I was just assuming all hw devices can parse the AES parameters. In fact, it doesn't make sense to me that ALSA would require some wrapper device.)

[ghost]

I've not tested this. Is it possible you could check if it behaves as expected:
https://dl.dropboxusercontent.com/u/3669512/temp/firmware_alsa_passthrough.zip

I tried it, and it works as expected. When outputting via the iec958 device, it just works, even if the volume control is not at 0db. Changing between PCM and compressed repeatedly also works. I suppose this fixes the issue completely.

[popcornmix]

Okay, this should appear in the next rpi-update firmware.

[ghost]

To expand on the iec958 issue: when I try on a laptop with the HDMI output connected to a receiver, the HDMI output doesn't even have a corresponding iec958 device (at least it's not listed by the ALSA utils and API). Instead, it happily seems to accept the AES0 parameter directly.

I suppose the ALSA API is just a bit inconsistent or too low level here. Is there a good explanation for this difference in behavior and requirements?

[ghost]

https://gist.githubusercontent.com/julianscheel/9094131/raw/af99299b11d32693abb07481698b1f963a423076/bcm2835.conf

Does this file have any kind of license?

[julianscheel]

No, feel free to do whatever you want with it :)
I think it's trivial enough anyway...

[Ruffio]

@wm4 has your issue been resolved? If so, please close this issue. Thanks.

[ghost]

Sort of, yes. We simply added that config file, as far as I know.

[bennettpeter]

Following recent updates to raspberry pi stretch, the bcm2835.conf file no longer works. I do not get the iec958 device created and no longer see it with aplay -L. Is there something I can do to get this working again?

[RaNo99]

I confirm, it is no longer working.

Guys on this thread, you are the experts! Is there any new solution to get DTS from VLC over HDMI on Pi?