Underrun in alsa audio (wake_up() is not working in linux-2.6.25)

[chethangm]

Issue:

If I play the wav file using "aplay", underrun error occurs.

I am suspecting the issue in driver or in kernel code.

I am using the following setup:

a) Application and Library:
aplay in alsa-utils-1.0.16 and alsa-lib-1.0.16.
b) Platform: imx27
c) kernel: linux-2.6.25

Hardware & Software parameters for aplay:

cat /proc/asound/card0/pcm0p/sub0/sw_params
tstamp_mode: NONE
period_step: 1
avail_min: 2048
start_threshold: 8192
stop_threshold: 8192
silence_threshold: 0
silence_size: 0
boundary: 1073741824

cat /proc/asound/card0/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 2048
buffer_size: 8192

observation:

1. When the aplay task going to wait state by calling following set of
functions in the audio driver,

static int wait_for_avail_min(struct snd_pcm_substream *substream,
snd_pcm_uframes_t *availp)
{
set_current_state(TASK_INTERRUPTIBLE);
snd_pcm_stream_unlock_irq(substream);
tout = schedule_timeout(msecs_to_jiffies(10000));
.
.
}

(file: linux-2.6.25/sound/core/pcm_lib.c)

Its not coming out from "schedule_timeout()" for a while in error
scenario (underrun condition).

2. What I observed is, in "try_to_wake_up()" of kernel/sched.c
its not enqueueing the "aplay" task in the "runqueue".

3. When the audio buffer is free the callback function
"snd_pcm_update_hw_ptr_post()" is calling "wake_up" to schedule,
here in error scenario its not actually
enqueueing our task in the "runqueue"

4. And Here I observed old_state and current task state (p->state)
mismatch for "aplay" context.

Is any one faced similar problem?

Can any one suggest me if any kernel patch for this issue.

I am stuck up here.

Thanks in advance
Chethan

[chethangm]

Issue:

If I play the wav file using "aplay", underrun error occurs.

I am suspecting the issue in driver or in kernel code.

I am using the following setup:

a) Application and Library:
aplay in alsa-utils-1.0.16 and alsa-lib-1.0.16.
b) Platform: imx27
c) kernel: linux-2.6.25

Hardware & Software parameters for aplay:

cat /proc/asound/card0/pcm0p/sub0/sw_params
tstamp_mode: NONE
period_step: 1
avail_min: 2048
start_threshold: 8192
stop_threshold: 8192
silence_threshold: 0
silence_size: 0
boundary: 1073741824

cat /proc/asound/card0/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 2048
buffer_size: 8192

observation:

1. When the aplay task going to wait state by calling following set of
functions in the audio driver,

static int wait_for_avail_min(struct snd_pcm_substream *substream,
snd_pcm_uframes_t *availp)
{
set_current_state(TASK_INTERRUPTIBLE);
snd_pcm_stream_unlock_irq(substream);
tout = schedule_timeout(msecs_to_jiffies(10000));
.
.
}

(file: linux-2.6.25/sound/core/pcm_lib.c)

Its not coming out from "schedule_timeout()" for a while in error
scenario (underrun condition).

2. What I observed is, in "try_to_wake_up()" of kernel/sched.c
its not enqueueing the "aplay" task in the "runqueue".

3. When the audio buffer is free the callback function
"snd_pcm_update_hw_ptr_post()" is calling "wake_up" to schedule,
here in error scenario its not actually
enqueueing our task in the "runqueue"

4. And Here I observed old_state and current task state (p->state)
mismatch for "aplay" context.

Is any one faced similar problem?

Can any one suggest me if any kernel patch for this issue.

I am stuck up here.

Thanks in advance
Chethan

Now, I found exact place in kernel where it is lagging,

in "linux/kernel/sched.c"

1. "pick_next_task()" call in "schedule()" function is picking "aplay" task

after around 200ms in error scenario,

2. In success scenario this delay is within 50 ms.

Can any one help me to reduce 200ms to desired.

Cheers
Chethan