[alsa-devel] [PATCH v2 14/14] OMAPDSS: HDMI: Implement DSS driver interface for audio
tomi.valkeinen at ti.com
Thu May 10 09:54:09 CEST 2012
On Wed, 2012-05-09 at 23:12 -0500, Ricardo Neri wrote:
> Under the new strategy, in addition to not allowing the audio functions
> to be called from multiple threads, audio functions will fail if the
> sequence _CONFIGURED -> _ENABLED -> PLAYING -> DISABLED is not followed.
> This is aligned with the behavior that ALSA follows for the audio
> codecs. Also, it checks the state of the panel to allow the audio
> > But the video and audio paths are probably always separate, and for
> > those we need protection. As you said, using the mutex for the may-sleep
> > audio functions solves the issue for those, leaving start/stop as the
> > only problem case.
> Audio only needs to know if the display is active. Under the improved
Audio also needs to know if the video mode is suitable for audio, right?
So not only disabling the video has to stop audio, but also if the video
mode changes to a non-supported one.
> strategy, audio_start indirectly checks the state of the panel because
> the audio needs to be in AUDIO_ENABLED state to start and this state is
> reached only if the panel is active. The mutex is held to check the
> state of the panel and the audio lock is held to change the audio state.
> Also, the audio transitions to AUDIO_DISABLED if the panel is disabled.
Hmm, I can't see the code that does that. As far as I see, no video
enable/disable/reconfig affects audio in any way. Am I missing a patch?
Could you setup a public git branch so it's easier for me to get the
whole series, instead of sending individual patches.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: This is a digitally signed message part
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20120510/661c8345/attachment-0001.sig
More information about the Alsa-devel