On Sun, May 10, 2015 at 09:59:42PM +0300, Anssi Hannula wrote:
I wonder whether receivers actually care with HDMI (they generally don't with S/PDIF) - that's one tidbit for me to test later... But of course it doesn't change much with the matter at hand, in any case we should strive to get the bits correct if only because the HDMI spec requires them to be (I don't think they were optional in IEC 60958-3 either, though).
I suspect they don't care too much, but the HDMI spec does require them to be correct. If we're trying to aim for best compatibility, setting them correctly is something we should strive to do.
What I'd like to see is arrive at some sort of general consensus on how the AES bits should be handled (i.e. should the driver always set them themselves and disallow/allow the userspace to override the rate bits), which could then be applied to other drivers as well.
But maybe that is for another time, or just a futile effort altogether...
My personal view is that where we're dealing with PCM audio, the driver needs to set these bits correctly as there is nothing in userspace to do this. This provides an identical interface between each audio device which accepts PCM samples - whether it's a SPDIF or non-SPDIF based device.
For non-audio data sent via an audio device, the AES bits need to be conveyed from userspace, and we should respect what userspace gives us. (If it's wrong, it's a userspace bug, and userspace should be fixed, rather than trying to work around the bug by patching the kernel.)
Indeed. I did notice there is a SND(RV)_PCM_FORMAT_SPECIAL but I guess it might not be easily used for this purpose since it doesn't have a specific sample width etc (but I am not familiar enough with this to say whether it could work or not)...
I spent quite a while looking at alsa-lib, wondering whether I could move all the conversions out to userspace, but I couldn't without building them _into_ alsa-lib. This was a while back now, but from what I remember, plugins to alsa-lib which aren't built as part of alsa-lib are not able to do format conversions.
However, in the case of VLC, if it wants to send non-audio, it will open the IEC958 device, which will use the iec958 plugin to configure the AES bits for non-audio, and pass IEC958 data to the kernel (which still needs to be reformatted to the hardware's special format.)
Ah, so the AES bits are actually overridable by userspace, which is what I was initially concerned with :)
Of course, this means that applications opening "iec958" but not setting rate bits (which is common) will get the default 48kHz bits from /usr/share/alsa/pcm/(iec958|hdmi).conf). Not sure how big an issue that is, though. The "iec958" ALSA plugin does seem to have a FIXME comment about setting AES bits according to sample rate.
Note that VLC does set the "sample" rate appropriately:
switch (aout->format.i_rate) { #define FS(freq) \ case freq: aes3 = IEC958_AES3_CON_FS_ ## freq; break; FS( 44100) /* def. */ FS( 48000) FS( 32000) FS( 22050) FS( 24000) FS( 88200) FS(768000) FS( 96000) FS(176400) FS(192000) #undef FS default: aes3 = IEC958_AES3_CON_FS_NOTID; break;
dw-hdmi-ahb-aud.pcm.iec958.0 {
I think you should s/iec958/hdmi/ for the above two lines. HDMI devices should be using "hdmi" instead of "iec958" by convention (the latter is used for optical/coaxial S/PDIF).
Except doing that kills VLC's passthrough option (denoted by "spdif"), which explicitly wants the iec958 device:
/* Choose the IEC device for S/PDIF output: if the device is overridden by the user then it will be the one. Otherwise we compute the default device based on the output format. */ if (spdif && !strcmp (device, "default")) { ... if (asprintf (&device, "iec958:AES0=0x%x,AES1=0x%x,AES2=0x%x,AES3=0x%x", IEC958_AES0_CON_EMPHASIS_NONE | IEC958_AES0_NONAUDIO, IEC958_AES1_CON_ORIGINAL | IEC958_AES1_CON_PCM_CODER, 0, aes3) == -1)
Yes, technically an application bug, since VLC should allow the device to be selectable and/or detect hdmi devices. I wonder if that's something which has changed between 2.0.8 and the latest vlc.
I did consider having the hdmi output device, but also alias that to the iec958 device name, which I think can be done via:
dw-hdmi-ahb-aud.pcm.hdmi.0 { ... }
dw-hdmi-ahb-aud.pcm.iec958.0 cards.dw-hdmi-ahb-aud.pcm.hdmi.0
However, for HDMI sinks, I haven't seen any way in Linux to allow userspace to know the audio capabilities of the attached HDMI sink, and thus whether the video player can output compressed MPEG audio. Anyone know?