1. 13 Sep, 2022 1 commit
  2. 10 Sep, 2022 1 commit
  3. 08 Sep, 2022 1 commit
  4. 07 Sep, 2022 2 commits
    • Takashi Iwai's avatar
      ALSA: usb-audio: Clear fixed clock rate at closing EP · 809f44a0
      Takashi Iwai authored
      The recent commit c11117b6 ("ALSA: usb-audio: Refcount multiple
      accesses on the single clock") tries to manage the clock rate shared
      by several endpoints.  This was intended for avoiding the unmatched
      rate by a different endpoint, but unfortunately, it introduced a
      regression for PulseAudio and pipewire, too; those applications try to
      probe the multiple possible rates (44.1k and 48kHz) and setting up the
      normal rate fails but only the last rate is applied.
      
      The cause is that the last sample rate is still left to the clock
      reference even after closing the endpoint, and this value is still
      used at the next open.  It happens only when applications set up via
      PCM prepare but don't start/stop the stream; the rate is reset when
      the stream is stopped, but it's not cleared at close.
      
      This patch addresses the issue above, simply by clearing the rate set
      in the clock reference at the last close of each endpoint.
      
      Fixes: c11117b6 ("ALSA: usb-audio: Refcount multiple accesses on the single clock")
      Reported-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Tested-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/all/YxXIWv8dYmg1tnXP@zx2c4.com/
      Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2620
      Link: https://lore.kernel.org/r/20220907100421.6443-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      809f44a0
    • Tasos Sahanidis's avatar
      ALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc() · d29f5905
      Tasos Sahanidis authored
      The voice allocator sometimes begins allocating from near the end of the
      array and then wraps around, however snd_emu10k1_pcm_channel_alloc()
      accesses the newly allocated voices as if it never wrapped around.
      
      This results in out of bounds access if the first voice has a high enough
      index so that first_voice + requested_voice_count > NUM_G (64).
      The more voices are requested, the more likely it is for this to occur.
      
      This was initially discovered using PipeWire, however it can be reproduced
      by calling aplay multiple times with 16 channels:
      aplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero
      
      UBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40
      index 65 is out of range for type 'snd_emu10k1_voice [64]'
      CPU: 1 PID: 31977 Comm: aplay Tainted: G        W IOE      6.0.0-rc2-emu10k1+ #7
      Hardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002    07/22/2010
      Call Trace:
      <TASK>
      dump_stack_lvl+0x49/0x63
      dump_stack+0x10/0x16
      ubsan_epilogue+0x9/0x3f
      __ubsan_handle_out_of_bounds.cold+0x44/0x49
      snd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1]
      snd_pcm_hw_params+0x29f/0x600 [snd_pcm]
      snd_pcm_common_ioctl+0x188/0x1410 [snd_pcm]
      ? exit_to_user_mode_prepare+0x35/0x170
      ? do_syscall_64+0x69/0x90
      ? syscall_exit_to_user_mode+0x26/0x50
      ? do_syscall_64+0x69/0x90
      ? exit_to_user_mode_prepare+0x35/0x170
      snd_pcm_ioctl+0x27/0x40 [snd_pcm]
      __x64_sys_ioctl+0x95/0xd0
      do_syscall_64+0x5c/0x90
      ? do_syscall_64+0x69/0x90
      ? do_syscall_64+0x69/0x90
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      Signed-off-by: default avatarTasos Sahanidis <tasos@tasossah.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/3707dcab-320a-62ff-63c0-73fc201ef756@tasossah.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d29f5905
  5. 06 Sep, 2022 3 commits
  6. 05 Sep, 2022 2 commits
  7. 04 Sep, 2022 1 commit
  8. 02 Sep, 2022 1 commit
  9. 01 Sep, 2022 3 commits
    • Takashi Iwai's avatar
      ALSA: usb-audio: Split endpoint setups for hw_params and prepare · ff878b40
      Takashi Iwai authored
      One of the former changes for the endpoint management was the more
      consistent setup of endpoints at hw_params.
      snd_usb_endpoint_configure() is a single function that does the full
      setup, and it's called from both PCM hw_params and prepare callbacks.
      Although the EP setup at the prepare phase is usually skipped (by
      checking need_setup flag), it may be still effective in some cases
      like suspend/resume that requires the interface setup again.
      
      As it's a full and single setup, the invocation of
      snd_usb_endpoint_configure() includes not only the USB interface setup
      but also the buffer release and allocation.  OTOH, doing the buffer
      release and re-allocation at PCM prepare phase is rather superfluous,
      and better to be done only in the hw_params phase.
      
      For those optimizations, this patch splits the endpoint setup to two
      phases: snd_usb_endpoint_set_params() and snd_usb_endpoint_prepare(),
      to be called from hw_params and from prepare, respectively.
      
      Note that this patch changes the driver operation slightly,
      effectively moving the USB interface setup again to PCM prepare stage
      instead of hw_params stage, while the buffer allocation and such
      initializations are still done at hw_params stage.
      
      And, the change of the USB interface setup timing (moving to prepare)
      gave an interesting "fix", too: it was reported that the recent
      kernels caused silent output at the beginning on playbacks on some
      devices on Android, and this change casually fixed the regression.
      It seems that those devices are picky about the sample rate change (or
      the interface change?), and don't follow the too immediate rate
      changes.
      
      Meanwhile, Android operates the PCM in the following order:
      - open, then hw_params with the possibly highest sample rate
      - close without prepare
      - re-open, hw_params with the normal sample rate
      - prepare, and start streaming
      This procedure ended up the hw_params twice with different rates, and
      because the recent kernel did set up the sample rate twice one and
      after, it screwed up the device.  OTOH, the earlier kernels didn't set
      up the USB interface at hw_params, hence this problem didn't appear.
      
      Now, with this patch, the USB interface setup is again back to the
      prepare phase, and it works around the problem automagically.
      Although we should address the sample rate problem in a more solid
      way in future, let's keep things working as before for now.
      
      Fixes: bf6313a0 ("ALSA: usb-audio: Refactor endpoint management")
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarchihhao chen <chihhao.chen@mediatek.com>
      Link: https://lore.kernel.org/r/87e6d6ae69d68dc588ac9acc8c0f24d6188375c3.camel@mediatek.com
      Link: https://lore.kernel.org/r/20220901124136.4984-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      ff878b40
    • Takashi Iwai's avatar
      ALSA: usb-audio: Register card again for iface over delayed_register option · 2027f114
      Takashi Iwai authored
      When the delayed registration is specified via either delayed_register
      option or the quirk, we delay the invocation of snd_card_register()
      until the given interface.  But if a wrong value has been set there
      and there are more interfaces over the given interface number,
      snd_card_register() call would be missing for those interfaces.
      
      This patch catches up those missing calls by fixing the comparison of
      the interface number.  Now the call is skipped only if the processed
      interface is less than the given interface, instead of the exact
      match.
      
      Fixes: b70038ef ("ALSA: usb-audio: Add delayed_register option")
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=216082
      Link: https://lore.kernel.org/r/20220831125901.4660-2-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      2027f114
    • Takashi Iwai's avatar
      ALSA: usb-audio: Inform the delayed registration more properly · 7e1afce5
      Takashi Iwai authored
      The info message that was added in the commit a4aad563 ("ALSA:
      usb-audio: Inform devices that need delayed registration") is actually
      useful to know the need for the delayed registration.  However, it
      turned out that this doesn't catch the all cases; namely, this warned
      only when a PCM stream is attached onto the existing PCM instance, but
      it doesn't count for a newly created PCM instance.  This made
      confusion as if there were no further delayed registration.
      
      This patch moves the check to the code path for either adding a stream
      or creating a PCM instance.  Also, make it simpler by checking the
      card->registered flag instead of querying each snd_device state.
      
      Fixes: a4aad563 ("ALSA: usb-audio: Inform devices that need delayed registration")
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=216082
      Link: https://lore.kernel.org/r/20220831125901.4660-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      7e1afce5
  10. 28 Aug, 2022 2 commits
  11. 26 Aug, 2022 1 commit
  12. 25 Aug, 2022 2 commits
  13. 24 Aug, 2022 3 commits
  14. 23 Aug, 2022 13 commits
  15. 22 Aug, 2022 3 commits
  16. 21 Aug, 2022 1 commit