• Ricard Wanderlof's avatar
    ALSA: USB-audio: Add quirk for Zoom R16/24 playback · e0570446
    Ricard Wanderlof authored
    The Zoom R16/24 have a nonstandard playback format where each isochronous
    packet contains a length descriptor in the first four bytes. (Curiously,
    capture data does not contain this and requires no quirk.)
    The quirk involves adding the extra length descriptor whenever outgoing
    isochronous packets are generated, both in pcm.c (outgoing audio) and
    endpoint.c (silent data).
    In order to make the quirk as unintrusive as possible, for
    pcm.c:prepare_playback_urb(), the isochronous packet descriptors are
    initially set up in the same way no matter if the quirk is enabled or not.
    Once it is time to actually copy the data into the outgoing packet buffer
    (together with the added length descriptors) the isochronous descriptors
    are adjusted in order take the increased payload length into account.
    For endpoint.c:prepare_silent_urb() it makes more sense to modify the
    actual function, partly because the function is less complex to start with
    and partly because it is not as time-critical as prepare_playback_urb()
    (whose bulk is run with interrupts disabled), so the (minute) additional
    time spent in the non-quirk case is motivated by the simplicity of having
    a single function for all cases.
    The quirk is controlled by the new tx_length_quirk member in struct
    snd_usb_substream and struct snd_usb_audio, which is conveyed to pcm.c
    and endpoint.c from quirks.c in a similar manner to the txfr_quirk member
    in the same structs.
    In contrast to txfr_quirk however, the quirk is enabled directly in
    quirks.c:create_standard_audio_quirk() by checking the USB ID in that
    function. Another option would be to introduce a new
    QUIRK_AUDIO_ZOOM_INTERFACE or somesuch, which would have made the quirk
    very plain to see in the quirk table, but it was felt that the additional
    code needed to implement it this way would just make the implementation
    more complex with no real gain.
    Tested with a Zoom R16, both by doing capture and playback separately
    using arecord and aplay (8 channel capture and 2 channel playback,
    respectively), as well as capture and playback together using Ardour, as
    well as Audacity and Qtractor together with jackd.
    The R24 is reportedly compatible with the R16 when used as an audio
    interface. Both devices share the same USB ID and have the same number of
    inputs (8) and outputs (2). Therefore "R16/24" is mentioned throughout the
    Regression tested using an Edirol UA-5 in both class compliant (16-bit)
    and "advanced" (24 bit, forces the use of quirks) modes.
    Signed-off-by: default avatarRicard Wanderlof <ricardw@axis.com>
    Tested-by: default avatarPanu Matilainen <pmatilai@laiskiainen.org>
    Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>