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 > transitions. > > > > 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. Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
