This project is mirrored from https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git. Pull mirroring updated .
  1. 27 Aug, 2021 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: Work around for XRUN with low latency playback · 4267c5a8
      Takashi Iwai authored
      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>
      4267c5a8
  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. 03 Jul, 2021 1 commit
    • Linus Torvalds's avatar
      Revert "ALSA: usb-audio: Reduce latency at playback start" · 4b820e16
      Linus Torvalds authored
      This reverts commit 9ce650a7
      
      .
      
      This commit causes watchdog lockups on my machine, and while I have no
      idea what the cause is, it bisected right to this commit, and reverting
      the change promptly fixes it.
      
      At least occasionally one of the watchdog call traces was
      
        Call Trace:
          _raw_spin_lock_irqsave+0x35/0x40
          snd_pcm_period_elapsed+0x1b/0xa0 [snd_pcm]
          snd_usb_endpoint_start+0x1a0/0x3c0 [snd_usb_audio]
          start_endpoints+0x23/0x90 [snd_usb_audio]
          snd_usb_substream_playback_trigger+0x7b/0x1a0 [snd_usb_audio]
          snd_pcm_common_ioctl+0x1c44/0x2360 [snd_pcm]
          snd_pcm_ioctl+0x2e/0x40 [snd_pcm]
          __se_sys_ioctl+0x72/0xc0
          do_syscall_64+0x4c/0xa0
          entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      so presumably it's a locking error on that substream spinlock that
      snd_pcm_period_elapsed() takes.  But at this point I just want to have a
      working system so that I can continue the merge window work tomorrow.
      
      Cc: Takashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4b820e16
  4. 02 Jun, 2021 5 commits
    • Takashi Iwai's avatar
      ALSA: usb-audio: Reduce latency at playback start · 9ce650a7
      Takashi Iwai authored
      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/20210601162457.4877-6-tiwai@suse.de
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      9ce650a7
    • Takashi Iwai's avatar
      ALSA: usb-audio: Factor out DSD bitrev copy function · 4f083917
      Takashi Iwai authored
      Just minor code refactoring.  Like DOP DSD code, it can be better in a
      separate function for code readability.
      
      Link: https://lore.kernel.org/r/20210601162457.4877-5-tiwai@suse.de
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      4f083917
    • 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
    • Takashi Iwai's avatar
      ALSA: usb-audio: Make snd_usb_pcm_delay() static · cdebd553
      Takashi Iwai authored
      It's a local function, let's make it static.
      
      Link: https://lore.kernel.org/r/20210601162457.4877-2-tiwai@suse.de
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      cdebd553
  5. 28 Feb, 2021 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: Allow modifying parameters with succeeding hw_params calls · 5f5e6a3e
      Takashi Iwai authored
      The recent fix for the hw constraints for implicit feedback streams
      via commit e4ea77f8 ("ALSA: usb-audio: Always apply the hw
      constraints for implicit fb sync") added the check of the matching
      endpoints and whether those EPs are already opened.  This is needed
      and correct, per se, even for the normal streams without the implicit
      feedback, as the endpoint setup is exclusive.
      
      However, it's reported that there seem applications that behave in
      unexpected ways to update the hw_params without clearing the previous
      setup via hw_free, and those hit a problem now: then hw_params is
      called with still the previous EP setup kept, hence it's restricted
      with the previous own setup.  Although the obvious fix is to call
      snd_pcm_hw_free() API in the application side, it's a kind of
      unwelcome change.
      
      This patch tries to ease the situation: in the endpoint check, we add
      a couple of more conditions and now skip the endpoint that is being
      used only by the stream in question itself.  That is, in addition to
      the presence check of ep (ep->cur_audiofmt is non-NULL), when the
      following conditions are met, we skip such an ep:
      - ep->opened == 1, and
      - ep->cur_audiofmt == subs->cur_audiofmt.
      
      subs->cur_audiofmt is non-NULL only if it's a re-setup of hw_params,
      and ep->cur_audiofmt points to the currently set up parameters.  So if
      those match, it must be this stream itself.
      
      Fixes: e4ea77f8 ("ALSA: usb-audio: Always apply the hw constraints for implicit fb sync")
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211941
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20210228080138.9936-1-tiwai@suse.de
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      5f5e6a3e
  6. 08 Feb, 2021 1 commit
  7. 05 Feb, 2021 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: Fix PCM buffer allocation in non-vmalloc mode · fb3c293b
      Takashi Iwai authored
      The commit f274baa4 ("ALSA: usb-audio: Allow non-vmalloc buffer
      for PCM buffers") introduced the mode to allocate coherent pages for
      PCM buffers, and it used bus->controller device as its DMA device.
      It turned out, however, that bus->sysdev is a more appropriate device
      to be used for DMA mapping in HCD code.
      
      This patch corrects the device reference accordingly.
      
      Note that, on most platforms, both point to the very same device,
      hence this patch doesn't change anything practically.  But on
      platforms like xhcd-plat hcd, the change becomes effective.
      
      Fixes: f274baa4 ("ALSA: usb-audio: Allow non-vmalloc buffer for PCM buffers")
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20210205144559.29555-1-tiwai@suse.de
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      fb3c293b
  8. 20 Jan, 2021 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: Fix hw constraints dependencies · 506c203c
      Takashi Iwai authored
      Since the recent refactoring, it's been reported that some USB-audio
      devices (typically webcams) are no longer detected properly by
      PulseAudio.  The debug session revealed that it's failing at probing
      by PA to try the sample rate 44.1kHz while the device has discrete
      sample rates other than 44.1kHz.  But the puzzle was that arecord
      works as is, and some other devices with the discrete rates work,
      either.
      
      After all, this turned out to be the lack of the dependencies in a few
      hw constraint rules: snd_pcm_hw_rule_add() has the (variable)
      arguments specifying the dependent parameters, and some functions
      didn't set the target parameter itself as the dependencies.  This
      resulted in an invalid parameter that could be generated only in a
      certain call pattern.  This bug itself has been present in the code,
      but it didn't trigger errors just because the rules were casually
      avoiding such a corner case.  After the recent refactoring and
      cleanup, however, the hw constraints work "as expected", and the
      problem surfaced now.
      
      For fixing the problem above, this patch adds the missing dependent
      parameters to each snd_pcm_hw_rule() call.
      
      Fixes: bc4e94aa ("ALSA: usb-audio: Handle discrete rates properly in hw constraints")
      BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=1181014
      Link: https://lore.kernel.org/r/20210120204554.30177-1-tiwai@suse.de
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      506c203c
  9. 13 Jan, 2021 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: Always apply the hw constraints for implicit fb sync · e4ea77f8
      Takashi Iwai authored
      Since the commit 5a6c3e11 ("ALSA: usb-audio: Add hw constraint for
      implicit fb sync"), we apply the hw constraints for the implicit
      feedback sync to make the secondary open aligned with the already
      opened stream setup.  This change assumed that the secondary open is
      performed after the first stream has been already set up, and adds the
      hw constraints to sync with the first stream's parameters only when
      the EP setup for the first stream was confirmed at the open time.
      However, most of applications handling the full-duplex operations do
      open both playback and capture streams at first, then set up both
      streams.  This results in skipping the additional hw constraints since
      the counter-part stream hasn't been set up yet at the open of the
      second stream, and it eventually leads to "incompatible EP" error in
      the end.
      
      This patch corrects the behavior by always applying the hw constraints
      for the implicit fb sync.  The hw constraint rules are defined so that
      they check the sync EP dynamically at each invocation, instead.  This
      covers the concurrent stream setups better and lets the hw refine
      calls resolving to the right configuration.
      
      Also this patch corrects a minor error that has existed in the debug
      print that isn't built as default.
      
      Fixes: 5a6c3e11 ("ALSA: usb-audio: Add hw constraint for implicit fb sync")
      Link: https://lore.kernel.org/r/20210111081611.12790-1-tiwai@suse.de
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      e4ea77f8
  10. 23 Nov, 2020 27 commits