This project is mirrored from https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git. Pull mirroring updated .
  1. 08 Sep, 2021 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: Work around for XRUN with low latency playback · 8ab355d6
      Takashi Iwai authored
      commit 4267c5a8 upstream.
      
      The recent change for low latency playback works in most of test cases
      but it turned out still to hit errors on some use cases, most notably
      with JACK with small buffer sizes.  This is because USB-audio driver
      fills up and submits full URBs at the beginning, while the URBs would
      return immediately and try to fill more -- that can easily trigger
      XRUN.  It was more or less expected, but in the small buffer size, the
      problem became pretty obvious.
      
      Fixing this behavior properly would require the change of the
      fundamental driver design, so it's no trivial task, unfortunately.
      Instead, here we work around the problem just by switching back to the
      old method when the given configuration is too fragile with the low
      latency stream handling.  As a threshold, we calculate the total
      buffer bytes in all plus one URBs, and check whether it's beyond the
      PCM buffer bytes.  The one extra URB is needed because XRUN happens at
      the next submission after the first round.
      
      Fixes: 307cc9ba ("ALSA: usb-audio: Reduce latency at playback start, take#2")
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20210827203311.5987-1-tiwai@suse.de
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8ab355d6
  2. 07 Jul, 2021 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: Reduce latency at playback start, take#2 · 307cc9ba
      Takashi Iwai authored
      This is another attempt for the reduction of the latency at the start
      of a USB audio playback stream.  The first attempt in the commit
      9ce650a7 caused an unexpected regression (a deadlock with pipewire
      usage) and was later reverted by the commit 4b820e16.  The devils
      are always living in details, of course; the cause of the deadlock was
      the call of snd_pcm_period_elapsed() inside prepare_playback_urb()
      callback.  In the original code, this callback is never called from
      the stream lock context as it's driven solely from the URB complete
      callback.  Along with the movement of the URB submission into the
      trigger START, this prepare call may be also executed in the stream
      lock context, hence it deadlocked with the another lock in
      snd_pcm_period_elapsed().  (Note that this happens only conditionally
      with a small period size that matches with the URB buffer length,
      which was a reason I overlooked during my tests.  Also, the problem
      wasn't seen in the capture stream because the capture stream handles
      the period-elapsed only at retire callback that isn't executed at the
      trigger.)
      
      If it were only about avoiding the deadlock, it'd be possible to use
      snd_pcm_period_elapsed_under_stream_lock() as a solution.  However, in
      general, the period elapsed notification must be sent after the actual
      stream start, and replacing the call wouldn't satisfy the pattern.
      A better option is to delay the notification after the stream start
      procedure finished, instead.  In the case of USB framework, one of the
      fitting place would be the complete callback of the first URB.
      
      So, as a workaround of the deadlock and the order fixes above, in
      addition to the re-applying the changes in the commit 9ce650a7,
      this patch introduces a new flag indicating the delayed period-elapsed
      handling and sets it under the possible deadlock condition
      (i.e. prepare callback being called before subs->running is set).
      Once when the flag is set, the period-elapsed call is handled at a
      later URB complete call instead.
      
      As a reference for the original motivation for the low-latency change,
      I cite here again:
      
      | USB-audio driver behaves a bit strangely for the playback stream --
      | namely, it starts sending silent packets at PCM prepare state while
      | the actual data is submitted at first when the trigger START is
      | kicked off.  This is a workaround for the behavior where URBs are
      | processed too quickly at the beginning.  That is, if we start
      | submitting URBs at trigger START, the first few URBs will be
      | immediately completed, and this would result in the immediate
      | period-elapsed calls right after the start, which may confuse
      | applications.
      |
      | OTOH, submitting the data after silent URBs would, of course, result
      | in a certain delay of the actual data processing, and this is rather
      | more serious problem on modern systems, in practice.
      |
      | This patch tries to revert the workaround and lets the URB
      | submission starting at PCM trigger for the playback again.  As far
      | as I've tested with various backends (native ALSA, PA, JACK, PW), I
      | haven't seen any problems (famous last words :)
      |
      | Note that the capture stream handling needs no such workaround,
      | since the capture is driven per received URB.
      
      Link: https://lore.kernel.org/r/4e71531f-4535-fd46-040e-506a3c256bbd@marcan.st
      Link: https://lore.kernel.org/r/s5hbl7li0fe.wl-tiwai@suse.de
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Link: https://lore.kernel.org/r/20210707112447.27485-1-tiwai@suse.de
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      307cc9ba
  3. 05 Jul, 2021 1 commit
  4. 02 Jun, 2021 2 commits
    • Takashi Iwai's avatar
      ALSA: usb-audio: Refactoring delay account code · e8a8f09c
      Takashi Iwai authored
      The PCM delay accounting in USB-audio driver is a bit complex to
      follow, and this is an attempt to improve the readability and provide
      some potential fix.
      
      Basically, the PCM position delay is calculated from two factors: the
      in-flight data on URBs and the USB frame counter.  For the playback
      stream, we advance the hwptr already at submitting URBs.  Those
      "in-flight" data amount is now tracked, and this is used as the base
      value for the PCM delay correction.  The in-flight data is decreased
      again at URB completion in return.  For the capture stream, OTOH,
      there is no in-flight data, hence the delay base is zero.
      
      The USB frame counter is used in addition for correcting the current
      position.  The reference frame counter is updated at each submission
      and receiving time, and the difference from the current counter value
      is taken into account.
      
      In this patch, each in-flight data bytes is recorded in the new
      snd_usb_ctx.queued field, and the total in-flight amount is tracked in
      snd_usb_substream.inflight_bytes field, as the replacement of
      last_delay field.
      
      Note that updating the hwptr after URB completion doesn't work for
      PulseAudio who tries to scratch the buffer on the fly; USB-audio is
      basically a double-buffer implementation, hence the scratching the
      buffer can't work for the already submitted data.  So we always update
      hwptr beforehand.  It's not ideal, but the delay account should give
      enough correctness.
      
      Link: https://lore.kernel.org/r/20210601162457.4877-4-tiwai@suse.de
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      e8a8f09c
    • Takashi Iwai's avatar
      ALSA: usb-audio: Pre-calculate buffer byte size · d303c5d3
      Takashi Iwai authored
      There are a bunch of lines calculating the buffer size in bytes at
      each time.  Keep the value in subs->buffer_bytes and use it
      consistently for the code simplicity.
      
      Link: https://lore.kernel.org/r/20210601162457.4877-3-tiwai@suse.de
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d303c5d3
  5. 08 Feb, 2021 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: More strict state change in EP · 5c2b3014
      Takashi Iwai authored
      The endpoint management has bit flags to indicate the current state,
      and we're dealing two things: the running bit and the stopping bit.
      There is a thin window in transition from the running to the stopping
      in stop_urbs(), and as long as the bit flags are used, it's difficult
      to plug.
      
      This patch modifies the state management code to use the atomic int
      and follow the explicit three states, STOPPED, RUNNING and STOPPING.
      The state change is done via atomic_cmpxhg() for avoiding possible
      races, and check the state change more strictly.  The unexpected state
      change is now handled as an error.
      
      Fixes: d0f09d1e ("ALSA: usb-audio: Refactoring endpoint URB deactivation")
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20210206203052.15606-3-tiwai@suse.de
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      5c2b3014
  6. 08 Jan, 2021 2 commits
    • Takashi Iwai's avatar
      ALSA: usb-audio: Annotate the endpoint index in audioformat · eae4d054
      Takashi Iwai authored
      There are devices that have multiple endpoints sharing the same
      iface/altset not only for sync but also for the actual streams, and
      the audioformat for such an endpoint needs to be handled with the
      proper endpoint index; otherwise it confuses the endpoint management.
      
      This patch extends the audioformat to annotate the endpoint index, and
      put the proper ep_idx=1 to Pioneer device quirk entries accordingly.
      
      Fixes: bf6313a0 ("ALSA: usb-audio: Refactor endpoint management")
      Link: https://lore.kernel.org/r/20210108075219.21463-5-tiwai@suse.de
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      eae4d054
    • Takashi Iwai's avatar
      ALSA: usb-audio: Avoid unnecessary interface re-setup · 00272c61
      Takashi Iwai authored
      The current endpoint handling assumed (more or less) a unique 1:1
      relation between the endpoint and the iface/altset.  The exception was
      the sync EP without the implicit feedback which has usually the
      secondary EP of the same altset.  This works fine for most devices,
      but it turned out that some unusual devices like Pinoeer's ones have
      both playback and capture endpoints in the same iface/altsetting and
      use both for the implicit feedback mode.  For handling such a case, we
      need to extend the endpoint management to take the shared interface
      into account.
      
      This patch does that: it adds a new object snd_usb_iface_ref for
      managing the reference counts of the each USB interface that is used
      by each endpoint.  The interface setup is performed only once for the
      (sharing) endpoints, and the doubly initialization is avoided.
      
      Along with this, the resource release of endpoints and interface
      refcounts are put into a single function, snd_usb_endpoint_free_all()
      instead of looping in the caller side.
      
      Fixes: bf6313a0 ("ALSA: usb-audio: Refactor endpoint management")
      Link: https://lore.kernel.org/r/20210108075219.21463-4-tiwai@suse.de
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      00272c61
  7. 23 Nov, 2020 10 commits
  8. 10 Aug, 2020 1 commit
  9. 30 Jun, 2020 1 commit
  10. 15 May, 2020 1 commit
  11. 24 Apr, 2020 1 commit
    • Alexander Tsoy's avatar
      ALSA: usb-audio: Improve frames size computation · f0bd62b6
      Alexander Tsoy authored
      
      
      For computation of the the next frame size current value of fs/fps and
      accumulated fractional parts of fs/fps are used, where values are stored
      in Q16.16 format. This is quite natural for computing frame size for
      asynchronous endpoints driven by explicit feedback, since in this case
      fs/fps is a value provided by the feedback endpoint and it's already in
      the Q format. If an error is accumulated over time, the device can
      adjust fs/fps value to prevent buffer overruns/underruns.
      
      But for synchronous endpoints the accuracy provided by these computations
      is not enough. Due to accumulated error the driver periodically produces
      frames with incorrect size (+/- 1 audio sample).
      
      This patch fixes this issue by implementing a different algorithm for
      frame size computation. It is based on accumulating of the remainders
      from division fs/fps and it doesn't accumulate errors over time. This
      new method is enabled for synchronous and adaptive playback endpoints.
      Signed-off-by: default avatarAlexander Tsoy <alexander@tsoy.me>
      Link: https://lore.kernel.org/r/20200424022449.14972-1-alexander@tsoy.me
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f0bd62b6
  12. 18 Dec, 2019 1 commit
    • Hui Wang's avatar
      ALSA: usb-audio: set the interface format after resume on Dell WD19 · 92adc96f
      Hui Wang authored
      
      
      Recently we found the headset-mic on the Dell Dock WD19 doesn't work
      anymore after s3 (s2i or deep), this problem could be workarounded by
      closing (pcm_close) the app and then reopening (pcm_open) the app, so
      this bug is not easy to be detected by users.
      
      When problem happens, retire_capture_urb() could still be called
      periodically, but the size of captured data is always 0, it could be
      a firmware bug on the dock. Anyway I found after resuming, the
      snd_usb_pcm_prepare() will be called, and if we forcibly run
      set_format() to set the interface and its endpoint, the capture
      size will be normal again. This problem and workaound also apply to
      playback.
      
      To fix it in the kernel, add a quirk to let set_format() run
      forcibly once after resume.
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191218132650.6303-1-hui.wang@canonical.com
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      92adc96f
  13. 22 Apr, 2019 1 commit
    • Shuah Khan's avatar
      media: sound/usb: Use Media Controller API to share media resources · 66354f18
      Shuah Khan authored
      
      
      Media Device Allocator API to allows multiple drivers share a media device.
      This API solves a very common use-case for media devices where one physical
      device (an USB stick) provides both audio and video. When such media device
      exposes a standard USB Audio class, a proprietary Video class, two or more
      independent drivers will share a single physical USB bridge. In such cases,
      it is necessary to coordinate access to the shared resource.
      
      Using this API, drivers can allocate a media device with the shared struct
      device as the key. Once the media device is allocated by a driver, other
      drivers can get a reference to it. The media device is released when all
      the references are released.
      
      Change the ALSA driver to use the Media Controller API to share media
      resources with DVB, and V4L2 drivers on a AU0828 media device.
      
      The Media Controller specific initialization is done after sound card is
      registered. ALSA creates Media interface and entity function graph nodes
      for Control, Mixer, PCM Playback, and PCM Capture devices.
      
      snd_usb_hw_params() will call Media Controller enable source handler
      interface to request the media resource. If resource request is granted,
      it will release it from snd_usb_hw_free(). If resource is busy, -EBUSY is
      returned.
      
      Media specific cleanup is done in usb_audio_disconnect().
      Reviewed-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarShuah Khan <shuah@kernel.org>
      Signed-off-by: default avatarHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      66354f18
  14. 18 Feb, 2019 1 commit
  15. 31 Jul, 2018 1 commit
  16. 13 Jun, 2018 1 commit
  17. 21 Mar, 2018 1 commit
    • Ruslan Bilovol's avatar
      ALSA: usb: initial USB Audio Device Class 3.0 support · 9a2fe9b8
      Ruslan Bilovol authored
      
      
      Recently released USB Audio Class 3.0 specification
      introduces many significant changes comparing to
      previous versions, like
       - new Power Domains, support for LPM/L1
       - new Cluster descriptor
       - changed layout of all class-specific descriptors
       - new High Capability descriptors
       - New class-specific String descriptors
       - new and removed units
       - additional sources for interrupts
       - removed Type II Audio Data Formats
       - ... and many other things (check spec)
      
      It also provides backward compatibility through
      multiple configurations, as well as requires
      mandatory support for BADD (Basic Audio Device
      Definition) on each ADC3.0 compliant device
      
      This patch adds initial support of UAC3 specification
      that is enough for Generic I/O Profile (BAOF, BAIF)
      device support from BADD document.
      Signed-off-by: default avatarRuslan Bilovol <ruslan.bilovol@gmail.com>
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      9a2fe9b8
  18. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      
      
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  19. 22 Aug, 2016 1 commit
  20. 31 Mar, 2016 1 commit
  21. 03 Mar, 2016 1 commit
  22. 19 Oct, 2015 1 commit
    • 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
      patch.
      
      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>
      e0570446
  23. 09 Feb, 2015 1 commit
  24. 02 May, 2014 1 commit
  25. 07 Oct, 2013 1 commit
    • Eldad Zack's avatar
      ALSA: usb-audio: rename alt_idx to altsetting · df23a246
      Eldad Zack authored
      
      
      As Clemens Ladisch kindly explained:
       "Please note that there are two methods to identify alternate settings:
        the number, which is the value in bAlternateSetting, and the index,
        which is the index in the descriptor array.  There might be some wording
        in the USB spec that these two values must be the same, but in reality,
        [insert standard rant about firmware writers], bAlternateSetting
        must be treated as a random ID value."
      
      This patch changes the name to express the correct usage semantics.
      No functional change.
      Signed-off-by: default avatarEldad Zack <eldad@fogrefinery.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      df23a246
  26. 26 Sep, 2013 1 commit
    • 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
  27. 27 Jun, 2013 1 commit
  28. 18 Apr, 2013 2 commits
    • Daniel Mack's avatar
      ALSA: snd-usb: add support for bit-reversed byte formats · 44dcbbb1
      Daniel Mack authored
      
      
      There is quite some confusion around the bit-ordering in DSD samples,
      and no general agreement that defines whether hardware is supposed to
      expect the oldest sample in the MSB or the LSB of a byte.
      
      ALSA will hence set the rule that on the software API layer, bytes
      always carry the oldest bit in the most significant bit of a byte, and
      the driver has to translate that at runtime in order to match the
      hardware layout.
      
      This patch adds support for this by adding a boolean flag to the
      audio format struct.
      Signed-off-by: default avatarDaniel Mack <zonque@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      44dcbbb1
    • Daniel Mack's avatar
      ALSA: snd-usb: add support for DSD DOP stream transport · d24f5061
      Daniel Mack authored
      In order to provide a compatibility way for pushing DSD
      samples through ordinary PCM channels, the "DoP open Standard" was
      invented. See http://www.dsd-guide.com
      
       for the official document.
      
      The host is required to stuff DSD marker bytes (0x05, 0xfa,
      alternating) in the MSB of 24 bit wide samples on the bus, in addition
      to the 16 bits of actual DSD sample payload.
      
      To support this, the hardware and software stride logic in the driver
      has to be tweaked a bit, as we make the userspace believe we're
      operating on 16 bit samples, while we in fact push one more byte per
      channel down to the hardware.
      
      The DOP runtime information is stored in struct snd_usb_substream, so
      we can keep track of our state across multiple calls to
      prepare_playback_urb_dsd_dop().
      Signed-off-by: default avatarDaniel Mack <zonque@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d24f5061