[alsa-devel] Question on wait_for_avail function

[Takashi Iwai]

At Thu, 6 Jun 2013 18:29:35 -0000,
gsantosh at codeaurora.org wrote:
> 
> > At Wed, 05 Jun 2013 23:25:15 -0700,
> > Patrick Lai wrote:
> >>
> >> + << Jaroslav >>
> >> On 6/5/2013 2:17 AM, Clemens Ladisch wrote:
> >> > gsantosh at codeaurora.org wrote:
> >> >> 2) HAL issues pause in parallel to the write
> >> >
> >> > This is illegal.
> >> > <http://www.alsa-project.org/main/index.php/SMP_Design> says:
> >> > | The use of returned handles [such as snd_pcm_t*] must be serialized
> >> in
> >> > | the application using own locking scheme.
> >> >
> >> > If you want to issue a pause while waiting for data to be written, use
> >> > non-blocking writes.
> >> >
> >>
> >> Based on my understanding of SMP_Design and response above, pause and
> >> write to same
> >> PCM device are expected to be serialized. However, my interpretation of
> >> following patch is that pause and stop are expected to wakes up process
> >> waiting in pcm_lib.c wait_for_avail(). It seems to give me the
> >> indication that multiple threads acting on same PCM device is expected.
> >>
> >> ALSA: pcm_core: Fix wake_up() optimization
> >>
> >> This change fixes the "ALSA: pcm_lib - optimize wake_up() calls for PCM
> >> I/O" commit. New sleeping queue is introduced to separate user space
> >> and kernel space wake_ups. runtime->nowake is renamed to twake
> >> (transfer wake).
> >>
> >> Jaroslav: Can you share your thought as you are author of this patch?
> >
> > I don't understand what's the problem in this thread...
> >
> > The behavior of PAUSED stream in wait_for_avail() is clear.  If it's
> > woken up by some events, it simply goes to sleep again without exiting
> > the loop.
> 
> We are facing the following issue and want to understand how ALSA is
> implemented pause, prepare and write if used asynchronously.
> 
> for the every seek operation we issue pause and prepare, till now in all
> the system the issue of (pause + prepare) commands and write are
> serialized.
> we are trying to decouple the write and other operation (pause and
> prepare) to issue in commands asynchronously.
> 
> Assume the case below, write is blocked in wait_for_avail as there is no
> space for the buffer, in between user issued seek on the same session this
> triggers pause and prepare operations.
> 
> pause command will unblock the thread blocked in wait_for_avail, this
> unblocked thread once again check if buffer avail and if buffer is not
> avail it goes for wait in loop.
> after the pause operation is done, HAL issues prepare in prepare we reset
> the buffer but never unblock the thread waiting in the wait_for_avail.
> this results in write thread blocked forever and it never gets unblocked
> as a result the session is blocked.

What do you mean "prepare" in the context above?  Moving to
SND_PCM_STATE_PREPARE?  If so, you can't.  For preparing the stream,
you must stop the stream once.  So, you have to issue snd_pcm_drop(),
so that stream goes to SND_PCM_STATE_SETUP, then you can do prepare,
and restart.

In other words, from the PAUSED state, it can change to only either
RUNNING (via PAUSE_RESUME trigger) or SETUP (via snd_pcm_drop) state.
(There are other possible states like DRAINING, SUSPENDED or
 DISCONNECTED, but let's ignore now. )


Takashi

> please help us to know why the implementation of the pause and prepare is
> this way and are we allowed to do the pause, prepare and write in
> asynchronously on the same session in copy interface.
> 
> 
> 
> 
> >
> >
> > Takashi
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel at alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >
> 
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>