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

[Tomi Valkeinen]

Hi,

On 13/11/14 11:17, Jean-Francois Moine wrote:
> On Thu, 13 Nov 2014 10:05:28 +0200
> Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> 	[snip]
>> I don't have much knowledge of the asoc architecture, so I probably
>> can't comment much on the sound/ side design. For me the most important
>> things are that 1) it works 2) I can easily unload/load the modules
>> (which was broken in some of the earlier versions).
>>
>> As a more general discussion item, I'm still wondering why it feels like
>> we (OMAP) are doing something totally new here. I'd imagine that almost
>> every device with HDMI would need both video and audio side support, and
>> those sides need to work together. And the audio side would need to get
>> notified of things like cable disconnect (i.e. the video stream is
>> stopped -> audio must be stopped also). But if I've understood right,
>> there was no similar existing code to be found.
> 
> I recently posted a patch on the HDMI CODEC to interface a HDMI
> transmitter
> http://mailman.alsa-project.org/pipermail/alsa-devel/2014-October/082745.html

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.

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

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

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

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

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20141113/4263df79/attachment-0001.sig>