On Fri, Jan 08, 2016 at 11:57:11AM +0200, Jyri Sarha wrote:
On 01/08/16 10:43, Philipp Zabel wrote:
Possibly the HDMI driver itself should just mute if the format is not supported, and userspace should be notified?
Another option would be simply aborting the playback. However having a mute control, that is forced to mute if the current stream is not supported, is an interesting idea. That would provide a way to notify the userspace without intrusively killing the stream.
Firstly, remember that the sequence you'll likely see is:
- disconnect - connect - new edid - new eld
The disconnect/connect cycle is HDMI protocol for "please re-read the EDID" and is used (eg) by AV receivers to signal a change. When they change from HDMI pass-through mode in standby, to being powered on, they typically switch from passing the displays EDID through unmodified, to a modified version with their audio capabilities included - and vice versa when they're placed back into standby.
The kernel's audio driver doesn't have any knowledge about the kind of audio being passed through it: while it knows the alleged sample rate, bits per sample, and number of channels, these are PCM details, and not compressed audio details. Compressed audio is normally sent with the kernel driver configured for 16 bit, 2 channel and an appropriate sample rate, with the IEC958 channel status data setup by the application (via libasound) to indicate non-audio amongst other details. Therefore, the kernel driver doesn't know a nature of the compressed audio stream, and can't "mute" the stream if the ELD indicates that the compressed audio stream has gone away.
Given that, I'd like to throw in here another detail: iirc, i915's HDMI exports the ELD to userspace via a control called "ELD" - see eld_bytes_ctl in sound/pci/hda/patch_hdmi.c. This allows userspace to monitor, and read the ELD including which compressed audio formats are supported. I'm not currently aware of anything that makes use of this, but as there is this precedent for exporting this information, maybe it should become a standard way, so that video playback applications can then select an appropriate audio stream depending on the current properties of the connected device?