Skip to content
  • Alan Stern's avatar
    ALSA: improve buffer size computations for USB PCM audio · 976b6c06
    Alan Stern authored
    
    
    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: default avatarAlan Stern <stern@rowland.harvard.edu>
    CC: Clemens Ladisch <clemens@ladisch.de>
    Tested-by: default avatarDaniel Mack <zonque@gmail.com>
    Tested-by: default avatarEldad Zack <eldad@fogrefinery.com>
    Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
    976b6c06