On 11/13/2014 12:00 PM, Tomi Valkeinen wrote:
Hi,
On 13/11/14 11:17, Jean-Francois Moine wrote:
On Thu, 13 Nov 2014 10:05:28 +0200
Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote:
...
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?
There was the 4th option: the driver forcing pause on the pcm when the
cable is disconnected or screen is blanked and resuming it automatically
when the picture is back. But I think that is maybe too hackish solution.
Considering the big picture, including the userspace. I think we would
need some way to tell the userspace when the HDMI device is available.
The problem is the same for both a and c cases. Maybe a read only alsa
mixer could be used for that.
Cheers,
Jyri
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...
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
