[alsa-devel] Player Thread is not woken after period elapsed
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.
Will you provide some hint on how to go about identifying the root cause?
Thanks -Sing
On Mon, 5 Sep 2011 23:08:53 +0530 "Nallasellan, Singaravelan" singaravelan.nallasellan@intel.com 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)).
actually it doesn't... you must be on some really really old kernel or something.
Will you provide some hint on how to go about identifying the root cause?
https://lkml.org/lkml/2011/9/5/201
Sorry, I have not provided the kernel version. Kernel version is 2.6.35. However, wait_for_avail() does not have the code similar to the one provided in the patch below. I will give a try.
-----Original Message----- From: Arjan van de Ven [mailto:arjan@infradead.org] Sent: Monday, September 05, 2011 11:23 PM To: Nallasellan, Singaravelan Cc: alsa-devel@alsa-project.org; linux-kernel@vger.kernel.org Subject: Re: Player Thread is not woken after period elapsed
On Mon, 5 Sep 2011 23:08:53 +0530 "Nallasellan, Singaravelan" singaravelan.nallasellan@intel.com 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)).
actually it doesn't... you must be on some really really old kernel or something.
Will you provide some hint on how to go about identifying the root cause?
https://lkml.org/lkml/2011/9/5/201
On Mon, 5 Sep 2011 23:38:49 +0530 "Nallasellan, Singaravelan" singaravelan.nallasellan@intel.com wrote:
please do not top post!
correcting that mistake for you for this time
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)).
actually it doesn't... you must be on some really really old kernel or something.
Sorry, I have not provided the kernel version. Kernel version is 2.6.35.
Please always test bugs like this with a recent kernel. 2.6.35 is pretty much 6 versions (and 18 months) behind and at that point you really have to test with something newer first before asking others to help you and spend their time on your problem.
Will you provide some hint on how to go about identifying the root cause?
However, wait_for_avail() does not have the code similar to the one provided in the patch below.
the patch is against a recent kernel; no surprise that the code has changed in the last 18 months....
please do not top post!
Ok.
correcting that mistake for you for this time
Thanks so much.
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)).
actually it doesn't... you must be on some really really old kernel or something.
Sorry, I have not provided the kernel version. Kernel version is 2.6.35.
Please always test bugs like this with a recent kernel. 2.6.35 is pretty much 6 versions (and 18 months) behind and at that point you really have to test with something newer first before asking others to help you and spend their time on your problem.
Unfortunately, I am stuck with that version as the product that I work on is on that version.
Will you provide some hint on how to go about identifying the root cause?
I manually ported the changes and verified. I still see the issue. Found more information which might throw more light into the problem. p->state in try_to_wake_up() is 0 when it is expected to be 2 or 3.
However, wait_for_avail() does not have the code similar to the one provided in the patch below.
the patch is against a recent kernel; no surprise that the code has changed in the last 18 months....
-- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org
Please always test bugs like this with a recent kernel. 2.6.35 is pretty much 6 versions (and 18 months) behind and at that point you really have to test with something newer first before asking others to help you and spend their time on your problem.
Unfortunately, I am stuck with that version as the product that I work on is on that version.
and that is everyone elses problem ... how?
if you can't be bothered to try at least a recent kernel, why would anyone else be bothered to help you on their own time?????
Please always test bugs like this with a recent kernel. 2.6.35 is pretty much 6 versions (and 18 months) behind and at that point you really have to test with something newer first before asking others to help you and spend their time on your problem.
Unfortunately, I am stuck with that version as the product that I work on is on that version.
and that is everyone elses problem ... how?
if you can't be bothered to try at least a recent kernel, why would anyone else be bothered to help you on their own time?????
I completely agree with you. Sorry for the inconvenience. But I have no choice. Further investigation of this issue shows that the thread is in running state and it is not scheduled. I am not sure how I will go about debugging this issue. Any pointer would help.
--
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/
participants (3)
-
Arjan van de Ven -
Nallasellan, Singaravelan -
Shan Hai