Add to the dmix plugin support for the S24_3LE sample format which is
used by 24-bit USB devices.
The optimized assembler version uses only 23 bits for sample data so
that the lowest bit can be used for synchronization because there is no
24-bit cmpxchg instruction.
From: Sascha Sommer <saschasommer@freenet.de>
this is a fix for bug 0001559.
Unlike my first guesses the real problem is not in the kernel driver but in
alsa-lib. Whenever the current dmix status is xrun and snd_pcm_dmix_drain
gets called the process will hang forever in the poll function. The reason is
that poll gets called even though the timer already stopped.
As described in the bugtracking system this bug was not noticable with alsa
versions that used the old IOCTLS because the SNDRV_TIMER_IOCTL_STOP ioctl
never reached the timer kernel module.
Attached patch fixes this problem for alsa-lib 1.0.10 by simply calling
snd_pcm_dmix_drop when snd_pcm_dmix_drain gets called in the state
SND_PCM_STATE_XRUN.
- this patch adds support for suspend & result for dmix and other
direct plugins
- the timer detection / initialization (TREAD support) was redesigned and
the check for proper driver version was moved to the timer_hw.c
- Fix semaphore gid control
- Do semaphore discard for all semaphores (although currently defined as 1)
- Fix the wrong check of return value from shmctl
- Fixed unbalanced semaphores (which may cause deadlock)
- Do semaphore-up before blocking calls for communication with the server
- Don't discard semaphores on the client side
- Open slave PCMs always in non-blocking mode to avoid blocking by semaphore
with the secondary open
dmix transfers data in asynchronously so that it doesn't write on the
last active period. This will allow the arbitrary buffer size in
future, too.
The hwsync call to slave is removed from commit and hwsync callbacks.
This hack was added to fix the noisy output (typically on xmms/bmp)
but it doesn't happen any more. Now the hwsync behavior is as same as
on 1.0.8 (i.e. hwsync is called only when slowptr option is set).
- Fix CPU hang-up during snd_pcm_drain()
A new internal function snd_pcm_wait_nocheck() to force to call poll().
- Clean up, fix status() callback of dmix
More fixes for 100% CPU hang-up problem with dmix.
- Clear timer queues properly when XRUN happens.
- Don't check XRUN when the stream isn't really running.
- Do hwsync properly for the delayed start state.
Support dmix on generic architectures without atomic operations but
using a semaphore to avoid concurrent accesses. This is less effective
than atomic operations but should work on every system.
Call hwsync of slave PCM on snd_pcm_hwsync() over dmix.
This reduces ocasional output noises, typically seen in xmms and bmp with
multi-threading on SMP/HT systems.
Disabled slowptr of default dmix definition again.
Introducing a private state for the delayed start of PCM stream.
This problem occurs when the rate plugin doesn't feed the data
properly before triggering START. This results in weird problems,
e.g. an inifinte loop of artsd eating 100% CPU time.
To solve this problem, the state is marked as "pending" when no
data appears at the trigger, and the stream is started later at
the mmap commit.
- added link/unlink/link_fd fast_ops callbacks
- moved code from snd_pcm_link to pcm_hw.c
- moved "empty" routines pointing to slave to pcm_generic.c
- introduced snd_pcm_generic_t
snd_pcm_dmix_open() returns success if the open fails attempting
to open not the HW plugin (dmix seems to be limited to use only
the HW plugin right now). This leads to memory corruptions and
eventually a SIGSEGV. The attached patch fixes the omission.
Signed-off-by: Stas Sergeev <stsp@aknet.ru>
