Re: [alsa-devel] [RFC] ALSA: Reduce delay for a blocking pcm_drain.
This can be worked around in user space as well by using a nonblocking
drain and
sleeping based on how many samples are queued. Would that be the right
thing to
do or is this (or something similar) worth fixing here.
To test this I opened a pcm and set no period wakeups, played a few
samples and
then called drain, which hung indefinitely. Using a USB headset with a max period size of 128k but only 15ms of the buffer filled, having the drain time shorter without losing samples makes a blocking call feasible.
Do you mean that you tested on a patched version of USB audio driver since only three drivers support SNDRV_PCM_INFO_NO_PERIOD_WAKEUP
http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/log/sound?qt=gre...
Raymond Yau wrote:
To test this I opened a pcm and set no period wakeups, played a few samples and then called drain, which hung indefinitely. Using a USB headset with a max period size of 128k but only 15ms of the buffer filled, having the drain time shorter without losing samples makes a blocking call feasible.
Do you mean that you tested on a patched version of USB audio driver since only three drivers support SNDRV_PCM_INFO_NO_PERIOD_WAKEUP
The flag is ignored if not supported.
In this test, the important part was the large period size.
Regards, Clemens
participants (2)
-
Clemens Ladisch -
Raymond Yau