summaryrefslogtreecommitdiff
path: root/sound/usb/endpoint.h
diff options
context:
space:
mode:
authorAlan Stern <stern@rowland.harvard.edu>2013-09-24 15:51:58 -0400
committerTakashi Iwai <tiwai@suse.de>2013-09-26 10:25:31 +0200
commit976b6c064a957445eb0573b270f2d0282630e9b9 (patch)
tree3a80a94273feeb9c30ac6f2e23976d020dc44aaf /sound/usb/endpoint.h
parente8bc99425e8159cd5f56bb76419158857bd358ed (diff)
ALSA: improve buffer size computations for USB PCM audio
This patch changes the way URBs are allocated and their sizes are determined for PCM playback in the snd-usb-audio driver. Currently the driver allocates too few URBs for endpoints that don't use implicit sync, making underruns more likely to occur. This may be a holdover from before I/O delays could be measured accurately; in any case, it is no longer necessary. The patch allocates as many URBs as possible, subject to four limitations: The total number of URBs for the endpoint is not allowed to exceed MAX_URBS (which the patch increases from 8 to 12). The total number of packets per URB is not allowed to exceed MAX_PACKS (or MAX_PACKS_HS for high-speed devices), which is decreased from 20 to 6. The total duration of queued data is not allowed to exceed MAX_QUEUE, which is decreased from 24 ms to 18 ms. The total number of ALSA frames in the output queue is not allowed to exceed the ALSA buffer size. The last requirement is the hardest to implement. Currently the number of URBs needed to fill a buffer cannot be determined in advance, because a buffer contains a fixed number of frames whereas the number of frames in an URB varies to match shifts in the device's clock rate. To solve this problem, the patch changes the logic for deciding how many packets an URB should contain. Rather than using as many as possible without exceeding an ALSA period boundary, now the driver uses only as many packets as needed to transfer a predetermined number of frames. As a result, unless the device's clock has an exceedingly variable rate, the number of URBs making up each period (and hence each buffer) will remain constant. The overall effect of the patch is that playback works better in low-latency settings. The user can still specify values for frames/period and periods/buffer that exceed the capabilities of the hardware, of course. But for values that are within those capabilities, the performance will be improved. For example, testing shows that a high-speed device can handle 32 frames/period and 3 periods/buffer at 48 KHz, whereas the current driver starts to get glitchy at 64 frames/period and 2 periods/buffer. A side effect of these changes is that the "nrpacks" module parameter is no longer used. The patch removes it. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Clemens Ladisch <clemens@ladisch.de> Tested-by: Daniel Mack <zonque@gmail.com> Tested-by: Eldad Zack <eldad@fogrefinery.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Diffstat (limited to 'sound/usb/endpoint.h')
-rw-r--r--sound/usb/endpoint.h2
1 files changed, 2 insertions, 0 deletions
diff --git a/sound/usb/endpoint.h b/sound/usb/endpoint.h
index 2287adf5ca59..3bd02f0d226c 100644
--- a/sound/usb/endpoint.h
+++ b/sound/usb/endpoint.h
@@ -12,6 +12,8 @@ int snd_usb_endpoint_set_params(struct snd_usb_endpoint *ep,
snd_pcm_format_t pcm_format,
unsigned int channels,
unsigned int period_bytes,
+ unsigned int period_frames,
+ unsigned int buffer_periods,
unsigned int rate,
struct audioformat *fmt,
struct snd_usb_endpoint *sync_ep);