* Question on wait_for_avail function @ 2013-06-05 8:28 gsantosh 2013-06-05 9:17 ` Clemens Ladisch 0 siblings, 1 reply; 6+ messages in thread From: gsantosh @ 2013-06-05 8:28 UTC (permalink / raw) To: alsa-devel, tiwai, lgirdwood Hi Liam, Consider an use case 1) Write is blocked as there is no space to write the data, after the return from snd_pcm_playback_avail()function in wait_for_avail 2) HAL issues pause in parallel to the write I see that the following function snd_pcm_post_pause unblock the write wake_up(&runtime->sleep); wake_up(&runtime->tsleep); But i do not see any case handling for the pause state in the wait_for_avail function, it is not coming out of the for loop as there will not be any change in the buffer states. Please explain what is the intention behind the wake in pause callback. Want to understand why there is no handling of pause in wait_for_avail function. and also is there any restriction from ALSA framework that we should not issue pause while write is blocked or going on. Regards, Santosh M G. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question on wait_for_avail function 2013-06-05 8:28 Question on wait_for_avail function gsantosh @ 2013-06-05 9:17 ` Clemens Ladisch 2013-06-06 6:25 ` Patrick Lai 0 siblings, 1 reply; 6+ messages in thread From: Clemens Ladisch @ 2013-06-05 9:17 UTC (permalink / raw) To: gsantosh; +Cc: tiwai, alsa-devel, lgirdwood gsantosh@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. Regards, Clemens ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question on wait_for_avail function 2013-06-05 9:17 ` Clemens Ladisch @ 2013-06-06 6:25 ` Patrick Lai 2013-06-06 6:53 ` Takashi Iwai 0 siblings, 1 reply; 6+ messages in thread From: Patrick Lai @ 2013-06-06 6:25 UTC (permalink / raw) To: Clemens Ladisch, perex; +Cc: tiwai, alsa-devel, lgirdwood, gsantosh + << Jaroslav >> On 6/5/2013 2:17 AM, Clemens Ladisch wrote: > gsantosh@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? Thanks Patrick > > Regards, > Clemens > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question on wait_for_avail function 2013-06-06 6:25 ` Patrick Lai @ 2013-06-06 6:53 ` Takashi Iwai 2013-06-06 18:29 ` gsantosh 0 siblings, 1 reply; 6+ messages in thread From: Takashi Iwai @ 2013-06-06 6:53 UTC (permalink / raw) To: Patrick Lai; +Cc: alsa-devel, gsantosh, Clemens Ladisch, lgirdwood At Wed, 05 Jun 2013 23:25:15 -0700, Patrick Lai wrote: > > + << Jaroslav >> > On 6/5/2013 2:17 AM, Clemens Ladisch wrote: > > gsantosh@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. Takashi ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question on wait_for_avail function 2013-06-06 6:53 ` Takashi Iwai @ 2013-06-06 18:29 ` gsantosh 2013-06-07 10:55 ` Takashi Iwai 0 siblings, 1 reply; 6+ messages in thread From: gsantosh @ 2013-06-06 18:29 UTC (permalink / raw) To: Takashi Iwai Cc: lgirdwood, Patrick Lai, Clemens Ladisch, alsa-devel, gsantosh > At Wed, 05 Jun 2013 23:25:15 -0700, > Patrick Lai wrote: >> >> + << Jaroslav >> >> On 6/5/2013 2:17 AM, Clemens Ladisch wrote: >> > gsantosh@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. 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@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Question on wait_for_avail function 2013-06-06 18:29 ` gsantosh @ 2013-06-07 10:55 ` Takashi Iwai 0 siblings, 0 replies; 6+ messages in thread From: Takashi Iwai @ 2013-06-07 10:55 UTC (permalink / raw) To: gsantosh; +Cc: Patrick Lai, Clemens Ladisch, lgirdwood, alsa-devel At Thu, 6 Jun 2013 18:29:35 -0000, gsantosh@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@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@alsa-project.org > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > > > > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-06-07 10:55 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-06-05 8:28 Question on wait_for_avail function gsantosh 2013-06-05 9:17 ` Clemens Ladisch 2013-06-06 6:25 ` Patrick Lai 2013-06-06 6:53 ` Takashi Iwai 2013-06-06 18:29 ` gsantosh 2013-06-07 10:55 ` Takashi Iwai
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.