linux-toradex.git/sound/core/pcm_lib.c, branch v3.0.44

ALSA: pcm - fix race condition in wait_for_avail()

2011-10-03T18:40:31+00:00

commit 763437a9e7737535b2fc72175ad4974048769be6 upstream.

wait_for_avail() in pcm_lib.c has a race in it (observed in practice by an
Intel validation group).

The function is supposed to return once space in the buffer has become
available, or if some timeout happens.  The entity that creates space (irq
handler of sound driver and some such) will do a wake up on a waitqueue
that this function registers for.

However there are two races in the existing code

1) If space became available between the caller noticing there was no
   space and this function actually sleeping, the wakeup is missed and the
   timeout condition will happen instead

2) If a wakeup happened but not sufficient space became available, the
   code will loop again and wait for more space.  However, if the second
   wake comes in prior to hitting the schedule_timeout_interruptible(), it
   will be missed, and potentially you'll wait out until the timeout
   happens.

The fix consists of using more careful setting of the current state (so
that if a wakeup happens in the main loop window, the schedule_timeout()
falls through) and by checking for available space prior to going into the
schedule_timeout() loop, but after being on the waitqueue and having the
state set to interruptible.

[tiwai: the following changes have been added to Arjan's original patch:
 - merged akpm's fix for waitqueue adding order into a single patch
 - reduction of duplicated code of avail check
]

Signed-off-by: Arjan van de Ven 
Signed-off-by: Andrew Morton 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman

ALSA: PCM - Don't check DMA time-out too shortly

2011-05-26T06:09:38+00:00

When the PCM period size is set larger than 10 seconds, currently the
PCM core may abort the operation with DMA-error due to the fixed timeout
for 10 seconds.  A similar problem is seen in the drain operation that
has a fixed timeout of 10 seconds, too.

This patch fixes the timeout length depending on the period size and
rate, also including the consideration of no_period_wakeup flag.

Reported-by: Raymond Yau 
Signed-off-by: Takashi Iwai

ALSA: sound, core, pcm_lib: fix xrun_log

2011-05-19T05:18:56+00:00

The xrun_log function was augmented with the in_interrupt parameter whereas the
empty macro definition used when xrun logging is disabled was not.

Add a third parameter to the empty macro definition so as to not cause compiler
errors when xrun logging (CONFIG_SND_PCM_XRUN_DEBUG) is disabled.

Signed-off-by: Ben Gardiner 
Signed-off-by: Takashi Iwai

ALSA: sound, core, pcm_lib: xrun_log: log also in_interrupt

2011-05-18T15:12:39+00:00

When debugging pcm drivers I found the "period" or "hw" prefix printed
by either XRUN_DEBUG_PERIODUPDATE or XRUN_DEBUG_PERIODUPDATE events,
respectively to be very useful is observing the interplay between
interrupt-context updates and syscall-context updates.

Similarly, when debugging overruns with XRUN_DEBUG_LOG it is useful to
see the context of the last 10 positions.

Add an in_interrupt member to hwptr_log_entry which stores the value of
the in_interrupt parameter of snd_pcm_update_hw_ptr0 when the log entry
is created. Print a "[Q]" prefix when dumping the log entries if
in_interrupt was true.

Signed-off-by: Ben Gardiner 
Signed-off-by: Takashi Iwai

ALSA: pcm: fix infinite loop in snd_pcm_update_hw_ptr0()

2011-04-01T16:01:23+00:00

When period interrupts are disabled, snd_pcm_update_hw_ptr0() compares
the current time against the time estimated for the current hardware
pointer to detect xruns.  The somewhat fuzzy threshold in the while loop
makes it possible that hdelta becomes negative; the comparison being
done with unsigned types then makes the loop go through the entire 263
negative range, and, depending on the value, never reach an unsigned
value that is small enough to stop the loop.  Doing this with interrupts
disabled results in the machine locking up.

To prevent this, ensure that the loop condition uses signed types for
both operands so that the comparison is correctly done.

Many thanks to Kelly Anderson for debugging this.

Reported-by: Nix 
Reported-by: "Christopher K." 
Reported-and-tested-by: Kelly Anderson 
Signed-off-by: Kelly Anderson 
[cl: remove unneeded casts; use a temp variable]
Signed-off-by: Clemens Ladisch 
Cc: 2.6.38 

Signed-off-by: Takashi Iwai

Merge branch 'topic/misc' into for-linus

2011-01-13T07:37:14+00:00

ALSA: pcm: remember to always call va_end() on stuff that we va_start()

2010-12-21T07:03:09+00:00

The Coverity checker spotted that we do not always remember to call
va_end() on 'args' in failure paths in snd_pcm_hw_rule_add().
Here's a patch to fix that up (compile tested only) - it also removes
some annoying trailing whitespace that caught my eye while I was in the
area..

Signed-off-by: Jesper Juhl 
Signed-off-by: Takashi Iwai

ALSA: pcm: optimize xrun detection in no-period-wakeup mode

2010-11-22T07:14:17+00:00

Add a lightweight condition on top of the xrun checking so that we can
avoid the division when the application is calling the update function
often enough.

Suggested-by: Jaroslav Kysela 
Signed-off-by: Clemens Ladisch 
Signed-off-by: Takashi Iwai

ALSA: pcm: detect xruns in no-period-wakeup mode

2010-11-22T07:14:06+00:00

When period wakeups are disabled, successive calls to the pointer update
function do not have a maximum allowed distance, so xruns cannot be
detected with the pointer value only.

To detect xruns, compare the actually elapsed time with the time that
should have theoretically elapsed since the last update.  When the
hardware pointer has wrapped around due to an xrun, the actually elapsed
time will be too big by about hw_ptr_buffer_jiffies.

Signed-off-by: Clemens Ladisch 
Signed-off-by: Takashi Iwai

ALSA: pcm: support for period wakeup disabling

2010-11-22T07:13:16+00:00

This patch allows to disable period interrupts which are
not needed when the application relies on a system timer
to wake-up and refill the ring buffer. The behavior of
the driver is left unchanged, and interrupts are only
disabled if the application requests this configuration.
The behavior in case of underruns is slightly different,
instead of being detected during the period interrupts the
underruns are detected when the application calls
snd_pcm_update_avail, which in turns forces a refresh of the
hw pointer and shows the buffer is empty.

More specifically this patch makes a lot of sense when
PulseAudio relies on timer-based scheduling to access audio
devices such as HDAudio or Intel SST. Disabling interrupts
removes two unwanted wake-ups due to period elapsed events
in low-power playback modes. It also simplifies PulseAudio
voice modules used for speech calls.

To quote Lennart "This patch looks very interesting and
desirable. This is something have long been waiting for."

Support for this in hardware drivers is optional.

Signed-off-by: Pierre-Louis Bossart 
Signed-off-by: Clemens Ladisch 
Signed-off-by: Takashi Iwai