From: gsantosh@codeaurora.org
To: Takashi Iwai <tiwai@suse.de>
Cc: lgirdwood@gmail.com, Patrick Lai <plai@codeaurora.org>,
Clemens Ladisch <clemens@ladisch.de>,
alsa-devel@alsa-project.org, gsantosh@codeaurora.org
Subject: Re: Question on wait_for_avail function
Date: Thu, 6 Jun 2013 18:29:35 -0000 [thread overview]
Message-ID: <13274fa9cdffd44c4468449b1cde146e.squirrel@www.codeaurora.org> (raw)
In-Reply-To: <s5hwqq7rapq.wl%tiwai@suse.de>
> 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
>
next prev parent reply other threads:[~2013-06-06 18:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2013-06-07 10:55 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=13274fa9cdffd44c4468449b1cde146e.squirrel@www.codeaurora.org \
--to=gsantosh@codeaurora.org \
--cc=alsa-devel@alsa-project.org \
--cc=clemens@ladisch.de \
--cc=lgirdwood@gmail.com \
--cc=plai@codeaurora.org \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.