Re: [alsa-devel] [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support

On Thu, 13 Nov 2014 12:00:41 +0200
Tomi Valkeinen [off-list ref] wrote:

	[snip]

Jyri or Peter knows this better, but I think one difference with OMAP
HDMI case and tda998x is that tda998x is an external encoder, and you
transfer audio data to it via i2s or spdif, whereas OMAP HDMI is inside
the SoC, and the HDMI IP gets the audio data via system DMA.

The system DMA transfers are triggered by the HDMI IP, and the HDMI IP
has to be enabled and properly configured for the DMA ports to function.

So, correct me if I'm wrong, but I think this is the fundamental difference:

In your case, the actual audio playback happens with the i2s or spdif
side. You can enable the playback at any time, no matter what is the
status of tda998x. If tda998x is not operational, the audio data will
just go to /dev/null.

In our case, the actual audio playback happens inside the HDMI block. We
need the whole HDMI block to be operational and correctly configured for
(fake or real) playback to be possible.

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.

quoted

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
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...

So, no, actually, once streaming is started, no information go from the
HDMI transmitter to the CODEC.

quoted

- the CODEC must alert the transmitter on audio start and stop.

I don't think that stopping audio streaming on HDMI disconnection is

And you allow audio playback also if the monitor does not support audio,
or the video mode does not supprot audio?

Bug in my patch: audio playback will be rejected if there will be no
audio support.

quoted

useful. I even let audio streaming start when the HDMI cable is
disconnected.

Ah, this is actually unclear thing to me: what should the audio side
behavior be when the HDMI cable is disconnected or the video is blanked?
I believe the options are:

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.

When the HDMI output device is disconnected, the video and audio outputs
don't need to be changed. I often switch off my TV set when I will not
use my computer for a while, letting the computer itself running. When
I get back and switch on back the TV set, video and audio are still
there.

Option a) is a bit problematic for us, as it requires the HDMI IP side
to be fully operational, with the video output configured and enabled,
as that is what drives the audio DMA. If we stop the video, I believe
the audio DMA will freeze, and it'll lead to timeouts on the audio side.

I haven't tried, but I believe we could program the HDMI IP to some safe
default video mode if the cable is disconnected, and turn off the actual
HDMI PHY, so that the audio side could work even if the HDMI stream is
not going anywhere. I think it would be quite big change to how the HDMI
driver works at the moment.

But then, if the cable _is_ connected and the video mode is such that it
cannot not support audio, I wonder if we can still fake the audio
playback or will the HDMI IP get confused...

AFAIK, the HDMI transmitters don't know if the video or audio is
displayed/played by the external device(s). Only the user knows.

BTW, you are talking about video modes without audio support. What are
you thinking about?

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/