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 2 commits
    • 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
    • Takashi Iwai's avatar
      ALSA: usb-audio: Fix regression on Sony WALKMAN NW-A45 DAC · 476081ac
      Takashi Iwai authored
      commit 7af5a143 upstream.
      
      We've got a regression report for USB-audio with Sony WALKMAN NW-A45
      DAC device where no sound is audible on recent kernel.  The bisection
      resulted in the code change wrt endpoint management, and the further
      debug session revealed that it was caused by the order of the USB
      audio interface.  In the earlier code, we always set up the USB
      interface at first before other setups, but it was changed to be done
      at the last for UAC2/3, which is more standard way, while keeping the
      old way for UAC1.  OTOH, this device seems requiring the setup of the
      interface at first just like UAC1.
      
      This patch works around the regression by applying the interface setup
      specifically for the WALKMAN at the beginning of the endpoint setup
      procedure.  This change is written straightforwardly to be easily
      backported in old kernels.  A further cleanup to move the workaround
      into a generic quirk section will follow in a later patch.
      
      Fixes: bf6313a0 ("ALSA: usb-audio: Refactor endpoint management")
      Cc: <stable@vger.kernel.org>
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214105
      Link: https://lore.kernel.org/r/20210824054700.8236-1-tiwai@suse.de
      
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      476081ac
  2. 30 Jul, 2021 1 commit
  3. 27 Jul, 2021 1 commit
  4. 26 Jul, 2021 1 commit
  5. 24 Jul, 2021 5 commits
  6. 22 Jul, 2021 1 commit
  7. 14 Jul, 2021 1 commit
  8. 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
  9. 05 Jul, 2021 2 commits
  10. 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
  11. 01 Jul, 2021 3 commits
  12. 22 Jun, 2021 21 commits