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: NJesper Juhl <jj@chaosbits.net>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The current code in pcm_lib.c do all checks using only the position
in the ring buffer. Unfortunately, where the interrupts gets delayed or
merged into one, we need another timing source to check when the
buffer size boundary overlaps to avoid the wrong updating of the
ring buffer pointers.

This code uses jiffies to check the right time window without any
performance impact.
Signed-off-by: NJaroslav Kysela <perex@perex.cz>

The current code in pcm_lib.c do all checks using only the position
in the ring buffer. Unfortunately, where the interrupts gets delayed or
merged into one, we need another timing source to check when the
buffer size boundary overlaps to avoid the wrong updating of the
ring buffer pointers.

This code uses jiffies to check the right time window without any
performance impact.
Signed-off-by: NJaroslav Kysela <perex@perex.cz>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In situation when appl_ptr is far greater then hw_ptr, the hw_avail value
can be greater than buffer_size. Check for this.
Signed-off-by: NJaroslav Kysela <perex@perex.cz>

When using poll() to wait for the next period -- or avail_min samples --
one gets a consistent delay for each system call that is usually just a
little short of the selected period time. However, When using
snd_pcm_read/write(), one gets a jittery delay that alternates between
less than a millisecond and approximately two period times. This is
caused by snd_pcm_lib_{read,write}1() transferring any available samples
to the user's buffer and adjusting the application pointer prior to
sleeping to the end of the current period. When the next period
interrupt occurs, there is then less than avail_min samples remaining to
be transferred in the period, so we end up sleeping until a second
period occurs.

This is solved by using runtime->twake as the number of samples needed
for a wakeup in addition to selecting the proper wait queue to wake in
snd_pcm_update_state(). This requires twake to be non-zero when used
by snd_pcm_lib_{read,write}1() even if avail_min is zero.
Signed-off-by: NDave Dillow <dave@thedillows.org>
Signed-off-by: NJaroslav Kysela <perex@perex.cz>

In the cleanup of the hw_ptr update functions in 2.6.33, the calculation
of the delta value was changed to use the modulo operator to protect
against a negative difference due to the pointer wrapping around at the
boundary.

However, the ptr variables are unsigned, so a negative difference would
result in the two complement's value which has no relation to the actual
difference relative to the boundary; the result is typically some value
near LONG_MAX-boundary.  Furthermore, even if the modulo operation would
be done with signed types, the result of a negative dividend could be
negative.

The invalid delta value is then caught by the following checks, but this
means that the pointer update is ignored.

To fix this, use a range check as in the other pointer calculations.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Cc: <stable@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Commit 7910b4a1 in 2.6.34 changed the
runtime->boundary calculation to make this value a multiple of both the
buffer_size and the period_size, because the latter is assumed by the
runtime->hw_ptr_interrupt calculation.

However, due to the lack of a ioctl that could read the software
parameters before they are set, the kernel requires that alsa-lib
calculates the boundary value, too.  The changed algorithm leads to
a different boundary value used by alsa-lib, which makes, e.g., mplayer
fail to play a 44.1 kHz file because the silence_size parameter is now
invalid; bug report:
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5015>.

This patch reverts the change to the boundary calculation, and instead
fixes the hw_ptr_interrupt calculation to be period-aligned regardless
of the boundary value.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Cc: <stable@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The commit 4d96eb25 broke the interrupt
time xrun functionality (stream stop etc.) if the CONFIG_SND_PCM_XRUN_DEBUG
is not set. This is because the xrun() is null defined without it.

Fix this by letting the function xrun() to be always defined as it was
before.
Signed-off-by: NJarkko Nikula <jhnikula@gmail.com>
Cc: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Clemens Ladisch noted for hw_ptr_removal in "cleanup & merge hw_ptr
update functions" commit:

"It is possible for the status/delay ioctls to be called when the sound
card's pointer register alreay shows a position at the beginning of the
new period, but immediately before the interrupt is actually executed.
(This happens regularly on a SMP machine with mplayer.)  When that
happens, the code thinks that the position must be at least one period
ahead of the current position and drops an entire buffer of data."

Return back the hw_ptr_interrupt variable. The last interrupt pointer
is always computed from the latest hw_ptr instead of tracking it
separately (in this case all hw_ptr checks and modifications might
influence also hw_ptr_interrupt and it is difficult to keep it
consistent).
Signed-off-by: NJaroslav Kysela <perex@perex.cz>

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).
Signed-off-by: NJaroslav Kysela <perex@perex.cz>

The previous jiffies delta was 0 in all cases. Use hw_ptr variable to
store and print original value.
Signed-off-by: NJaroslav Kysela <perex@perex.cz>

When runtime->periods == 1 or when pointer crosses end of ring buffer,
the delta might be greater than buffer_size.
Signed-off-by: NJaroslav Kysela <perex@perex.cz>

As noted by pl bossart <bossart.nospam@gmail.com>, the PCM I/O routines
(snd_pcm_lib_write1, snd_pcm_lib_read1) should block wake_up() calls
until all samples are not processed.
Signed-off-by: NJaroslav Kysela <perex@perex.cz>

Do general cleanup in snd_pcm_update_hw_ptr*() routines and merge them.
The main change is hw_ptr_interrupt variable removal to simplify code
logic. This variable can be computed directly from hw_ptr.

Ensure that updated hw_ptr is not lower than previous one (it was possible
with old code in some obscure situations when interrupt was delayed or
the lowlevel driver returns wrong ring buffer position value).
Signed-off-by: NJaroslav Kysela <perex@perex.cz>

In some debug cases, it might be usefull to see previous ring buffer
positions to determine position problems from the lowlevel drivers.
Signed-off-by: NJaroslav Kysela <perex@perex.cz>

To increase code readability, convert send xrun_debug() argument to
use defines.
Signed-off-by: NJaroslav Kysela <perex@perex.cz>

Refine the rate selection by choosing the rate
closer to the requested one in case of selecting
single frequency. Previously, the higher rate was
always selected.

Also, fix problem with the best_diff unsigned int
value wrapping (turning negative).
Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The direction of rounding is incorrect in the snd_interval_ratnum()
It was detected with following parameters (sb8 driver playing
8kHz stereo file):
 - num is always 1000000
 - requested frequency rate is from 7999 to 7999 (single frequency)

The first loop calculates div_down(num, freq->min) which is 125.
Thus, a frequency range's minimum value is 1000000 / 125 = 8000 Hz.
The second loop calculates div_up(num, freq->max) which is 126
The frequency range's maximum value is 1000000 / 126 = 7936 Hz.
The range maximum is lower than the range minimum so the function
fails due to empty result range.
Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

snd_interval_list() expected a sorted list but did not document this, so
there are drivers that give it an unsorted list.  To fix this, change
the algorithm to work with any list.

This fixes the "Slave PCM not usable" error with USB devices that have
multiple alternate settings with sample rates in decreasing order, such
as the Philips Askey VC010 WebCam.

http://bugzilla.kernel.org/show_bug.cgi?id=14028Reported-and-tested-by: NAndrzej <adkadk@gmail.com>
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Cc: <stable@kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The current PCM core has the following problems regarding PCM draining
in non-blocking mode:

- the current f_flags isn't checked in snd_pcm_drain(), thus changing
  the mode dynamically via snd_pcm_nonblock() after open doesn't work.
- calling drain in non-blocking mode just return -EAGAIN error, but
  doesn't provide any way to sync with draining.

This patch fixes these issues.
- check file->f_flags in snd_pcm_drain() properly
- when O_NONBLOCK is set, PCM core sets the stream(s) to DRAIN state
  but quits ioctl immediately without waiting the whole drain; the
  caller can sync the drain manually via poll()
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The fix 79452f0a introduced another
bug due to the missing offset for the overlapped hwptr.
When the hwptr goes back to zero, the delta value has to be corrected
with the buffer size.  Otherwise this causes looping sounds.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add proper cast.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Added the logging functionality to xrun_debug to record the hwptr
updates via snd_pcm_update_hw_ptr() and snd_pcm_update_hwptr_interrupt(),
corresponding to 16 and 8, respectively.

For example,
	# echo 9 > /proc/asound/card0/pcm0p/xrun_debug
will record the position and other parameters at each period interrupt
together with the normal XRUN debugging.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

VMware tends to report PCM positions and period updates at utterly
wrong timing.  This screws up the recent PCM core code that tries
to correct the position based on the irq timing.

Now, when a backward irq position is detected, skip the update
instead of rebasing.  (This is almost the old behavior before
2.6.30.)
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Use a common helper function for the PCM stream name displayed in
XRUN and buffer-pointer debug prints.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The commit 13f040f9 made another
regression, the missing update of runtime->hw_ptr_interrupt.
Since this field is only checked in snd_pcmupdate__hw_ptr_interrupt(),
not in snd_pcm_update_hw_ptr(), it must be updated before the hw_ptr
change check.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Fix a typo in the commit 13f040f9
  ALSA: PCM midlevel: Do not update hw_ptr_jiffies when hw_ptr is not changed
which causes obvious problems with PA.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Replace the house-made div64_32() with the standard div_u64*() functions.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When hardware has large FIFO, it is necessary to lower jiffies margin
by count of queued samples.
Signed-off-by: NJaroslav Kysela <perex@perex.cz>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some hardware might have bigger FIFOs and DMA pointer value will be updated
in large chunks. Do not update hw_ptr_jiffies and position timestamp when
hw_ptr value was not changed.
Signed-off-by: NJaroslav Kysela <perex@perex.cz>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

For debugging purposes, it is better to separate actions.

Bit-values:

	1: show bad PCM ring buffer pointer
	2: show also stack (to debug kernel latency issues)
	4: check pointer against system jiffies

Example:

	5: show bad PCM ring buffer pointer and do jiffies check
Signed-off-by: NJaroslav Kysela <perex@perex.cz>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Move the fifo_size assignment to hw->ioctl callback to allow lowlevel
drivers overwrite the default behaviour.

fifo_size is in frames not bytes as specified in asound.h and alsa-lib's
documentation, but most hardware have fixed byte based FIFOs. Introduce
internal SNDRV_PCM_INFO_FIFO_IN_FRAMES.
Signed-off-by: NJaroslav Kysela <perex@perex.cz>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The PCM hw_ptr jiffies check results sometimes in problems when a
hardware doesn't give smooth hw_ptr updates.  So far, au88x0 and some
other drivers appear not working due to this strict check.
However, this check is a nice debug tool, and the capability should be
still kept.

Hence, we disable this check now as default unless the user enables it
by setting the xrun_debug mode to the specific stream via a proc file.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The hw_ptr_jiffies has to be reset properly to avoid the invalid
check of jiffies delta in snd_pcm_update_hw_ptr*() functions.
Especailly this patch fixes the bogus jiffies check after the puase
and resume.

This patch is a modified version of the original patch by Jaroslav.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The hardware devices with SNDRV_PCM_INFO_BATCH flag can't give the
precise current position.  And such hardwares have often big FIFO
in addition to the ring buffer, and it screws up the jiffies check
in pcm_lib.c.

This patch adds a simple check of info flag so that the driver skips
the jiffies check in snd_pcm_period_elapsed() when BATCH flag is set.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some drivers like Intel8x0 or Intel HDA are broken for some hardware variants.
This patch adds more strict buffer position checks based on jiffies when
internal hw_ptr is updated. Enable xrun_debug to see mangling of wrong
positions.

As a side effect, the hw_ptr interrupt update routine might do slightly better
job when many interrupts are lost.
Signed-off-by: NJaroslav Kysela <perex@perex.cz>

Make the boundary checks a bit safer.
These caese are rare or theoretically won't happen, but nothing
bad to keep the checks safer...
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

When the hw_ptr_interrupt reaches the boundary, it must check whether
the hw_base was already lapped and corret the delta value appropriately.

Also, rebasing the hw_ptr needs a correction because buffer_size isn't
always aligned to period_size.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Always reset the invalind hw_ptr position returned by the pointer
callback.  The behavior should be consitent independently from the
debug option.

Also, add the printk_ratelimit() check to avoid flooding debug
prints.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>