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. Why should every audio user have some code in it to generate the IEC bits? 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... I think you're a little confused about what userspace does here. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
