09.05.2015, 20:40, Russell King - ARM Linux kirjoitti:
On Sat, May 09, 2015 at 08:07:45PM +0300, Anssi Hannula wrote:
09.05.2015, 19:55, Russell King - ARM Linux kirjoitti:
On Sat, May 09, 2015 at 07:49:44PM +0300, Anssi Hannula wrote:
(Of course having userspace set them requires that the device has a proper entry in /usr/share/alsa/cards and the pcm device is accessed via the standard "hdmi" or "iec958" device names which perform the channel status word setup. I guess the ARM SoC stuff generally doesn't bother with that, explaining a bit why some kernel drivers set them by themselves).
I'm not sure that's sufficient - I haven't yet found where in the ALSA userspace, the AES bits are appropriately set according to the sample rate.
Right, that is left to the applications (e.g. VLC and Kodi do that). I'm under the impression that sinks do not normally care about this value, though, but that could just be because most desktop HW sets it by themselves.
No, that seems totally wrong to me.
What if you open the device using aplay? Or pulseaudio? Or madplay? Or another audio application which thinks it's addressing a standard PCM device.
Then, unless the driver or HW sets it, it is not set.
Why should every audio user have some code in it to generate the IEC bits?
Yeah, it makes zero sense of course, I wasn't claiming otherwise (sorry if it seemed like it).
Even VLC _doesn't_ if it's outputting to a standard audio - in other words, if you don't tick the SPDIF direct output option which defaults to disabled (which, when enabled, opens the device passing the AES bits _and_ permits it to send a compressed audio stream.) I've looked at this in VLC many times...
That is my understanding as well. Same for pulseaudio, it doesn't set any AES bits except for passthrough (and most other applications never set them).
I think you're a little confused about what userspace does here.