On 13/11/14 17:00, Jean-Francois Moine wrote: > When the tda998x is not operational, the CODEC knows it and reports an > error to the audio subsystem on device open. But, once the tda998x has > been started, it always stays operational, even without HDMI connection. What does "started" mean here? tda998x device/driver has been probed? The reason for the above is probably to handle hotplug? I.e. tda998x needs to be enabled always to detect HPD? Usually for OMAP, the HPD detection happens outside the HDMI IP. Thus the HDMI IP is turned fully off when the video is disabled. I believe tda998x could be used the same way, if the HPD pin is connected to a SoC GPIO instead of tda998x. >>> and I saw only a few dependencies between the 2 subsystems: >>> >>> - the CODEC must know the transmitter parameters (DAIs - static -, >>> audio constraints - dynamic -), >> >> The video mode (i.e. availability of audio) or the EDID (i.e. the >> supported audio parameters) may change at any time, so I presume in your >> series the video side will inform the codec of these changes at any point? > > Such changes occur only when the HDMI output device (TV) is replaced by The user can change the video mode at any time. The audio data packets are sent in the video blanking intervals, and if those intervals are too short, the video mode cannot support audio. If I'm not mistaken, officially only certain video modes defined in the HDMI spec support audio. > an other one (manual cable exchange or HDMI switcher). I wonder if > these changes are correctly treated in the HDMI transmitters, DRM core, > DRM drivers, X11/wayland... HPD (which usually equals to cable change, but not always) is handled. >> a) Always keep the audio device operational, no matter what is the >> status of the video side. How should this work if the HDMI videomode or >> the HDMI monitor does not support audio? Is it desirable that the >> userspace has no idea that the audio is not actually going anywhere? >> >> b) Remove the audio device when audio support is not available. This >> kind of makes sense, as, well, there's no possibility for audio output. >> But maybe this is not how linux sound devices are supposed to behave? >> >> c) Return errors when playback is attempted when audio support is not >> available. Again, this kind of makes sense, as audio playback is not >> possible. But maybe this is also not how audio devices generally work. >> >> Jyri, were there some other options we discussed? >> >> Currently, the OMAP HDMI version does c). It's the easiest solution for us. > > Same for me, but checking the audio capability is done on audio streaming > start only. Hmm, I understood you have option a)? You said "I even let audio streaming start when the HDMI cable is disconnected". With "audio support is not available" I mean also the case when the cable is not connected, as then we don't have EDID information, and thus we don't have a HDMI monitor with audio support on the other end. So to clarify, our driver only has "audio support available" if: - we successfully read EDID - EDID shows it's a HDMI monitor - EDID shows it has audio support for the format we support (this we don't actually do yet) Otherwise we default to DVI, which means no audio. If, at any point, the situation changes to "no audio support available", the audio playback is aborted and starting new audio playback fails. > AFAIK, the HDMI transmitters don't know if the video or audio is > displayed/played by the external device(s). Only the user knows. True. But the HDMI transmitter can know if the audio absolutely cannot be played, because there's no cable, or because the monitor says it doesn't support audio, or because the video mode cannot support audio, or because the HDMI output stream is disabled. So the question is, do we want/need to inform the userspace about those situations? Should a HDMI transmitted always look like it can play audio, even if it's clear it cannot? Again, I know very little about audio, but I think it would be nice that if I open the sound configuration window on my desktop, it'd show me that the HDMI audio device is disabled (because there's no cable). But perhaps that's a separate feature. We could have HDMI audio device always there and functional, but the desktop could get the information about HDMI cable connection some other way (DRM). And if the cable is not there, it knows that this particular audio device is also out, and thus doesn't show it (even if it's functional). > BTW, you are talking about video modes without audio support. What are > you thinking about? This I covered above. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
