From: Shan Hai <haishan.bai@gmail.com>
To: "Nallasellan, Singaravelan" <singaravelan.nallasellan@intel.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Player Thread is not woken after period elapsed
Date: Wed, 14 Sep 2011 17:18:35 +0800 [thread overview]
Message-ID: <4E70716B.3010201@gmail.com> (raw)
In-Reply-To: <3CA6C6D9F70D314CA34352990B57DA1507C420F147@bgsmsx502.gar.corp.intel.com>
On 09/06/2011 01:38 AM, Nallasellan, Singaravelan wrote:
> Hi,
>
> When I tried to root cause a glitch in the audio playback, I found a weird behavior.
>
> User thread which invokes the writei function which in turn invokes a kernel function which waits for the free buffer to write the audio data. This kernel function adds this thread to a wake(sleep) queue and calls a schedule_timeout (msecs_to_jiffies(10000)).
>
> When the audio playback of a period is completed, the hardware generates an interrupt. The handler in the path wake_up the thread added to the sleep queue. Most of the time, the playback thread is woken up.
>
> During this error case, the thread is not getting woken up. However the sleep queue is not empty. This continues until the playback enter into underrun due to all the periods in the buffer are played back. Audio playback continues after recovery from xrun.
>
Its possible that your user thread was woken up by the IRQ handler but
it found out the 'free buffer' is not available and go back to sleep.
- check the /proc/<pid of user thread>/schedstat for whether the thread
was scheduled
- your shared buffer design might has problems in it, it seemed there is
a race between
your IRQ handler and 'free buffer' checking logic.
- ftrace might be helpful
Cheers
Shan Hai
> Will you provide some hint on how to go about identifying the root cause?
>
> Thanks
> -Sing
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
prev parent reply other threads:[~2011-09-14 9:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-05 17:38 Player Thread is not woken after period elapsed Nallasellan, Singaravelan
2011-09-05 17:52 ` Arjan van de Ven
2011-09-05 18:08 ` Nallasellan, Singaravelan
2011-09-05 18:22 ` Arjan van de Ven
2011-09-06 14:19 ` Nallasellan, Singaravelan
2011-09-07 3:06 ` Arjan van de Ven
2011-09-07 12:02 ` Nallasellan, Singaravelan
2011-09-08 2:13 ` Yong Zhang
2011-09-08 7:29 ` Yong Zhang
2011-09-08 9:45 ` Nallasellan, Singaravelan
2011-09-09 6:07 ` Yong Zhang
2011-09-09 12:42 ` Nallasellan, Singaravelan
2011-09-14 8:39 ` Yong Zhang
2011-09-14 9:18 ` Shan Hai [this message]
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=4E70716B.3010201@gmail.com \
--to=haishan.bai@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=linux-kernel@vger.kernel.org \
--cc=singaravelan.nallasellan@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox