1. 15 Sep, 2022 1 commit
    • Takashi Iwai's avatar
      ALSA: usb-audio: Fix last interface check for registration · 39efc9c8
      Takashi Iwai authored
      The recent fix in commit 6392dcd1 ("ALSA: usb-audio: Register card
      at the last interface") tried to delay the card registration until the
      last found interface is probed.  It assumed that the probe callback
      gets called for those later interfaces, but it's not always true; as
      the driver loops over the descriptor and probes the matching ones,
      it's not separately called via multiple probe calls.  This results in
      the missing card registration, i.e. no sound device.
      
      For addressing this problem, replace the check whether the last
      interface is processed with usb_interface_claimed() instead of the
      comparison with the probe interface number.
      
      Fixes: 6392dcd1 ("ALSA: usb-audio: Register card at the last interface")
      Link: https://lore.kernel.org/r/20220915085947.7922-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      39efc9c8
  2. 13 Sep, 2022 6 commits
  3. 12 Sep, 2022 2 commits
  4. 10 Sep, 2022 1 commit
  5. 09 Sep, 2022 3 commits
  6. 08 Sep, 2022 1 commit
  7. 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
  8. 06 Sep, 2022 8 commits
  9. 05 Sep, 2022 2 commits
  10. 04 Sep, 2022 1 commit
  11. 02 Sep, 2022 1 commit
  12. 01 Sep, 2022 7 commits
    • Takashi Iwai's avatar
      ALSA: usb-audio: Clean up endpoint setups at PCM prepare · 32eeeed9
      Takashi Iwai authored
      This patch cleans up the superfluous checks and calls for setting up
      the endpoints at PCM prepare callback:
      
      - Drop stop_endpoints() and sync_pending_stops() calls; the stream is
        guaranteed to have been already stopped and synced at each PCM
        prepare call by ALSA PCM core
      
      - Call snd_usb_endpoint_prepare() unconditionally;
        the check for endpoint->need_setup is done in
        snd_pcm_hw_endpoint_prepare() itself
      
      - Apply snd_usb_set_format_quirk() only when the endpoint is actually
        set up (i.e. the return code from snd_usb_endpoint_prepare() > 0)
      
      - Move a few lines back into snd_usb_pcm_prepare();
        it's even easier to follow than a small useless function
      
      Link: https://lore.kernel.org/r/20220901130831.6136-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      32eeeed9
    • Takashi Iwai's avatar
      Merge branch 'for-linus' into for-next · 041af768
      Takashi Iwai authored
      041af768
    • 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
    • Valentina Goncharenko's avatar
      ALSA: asihpi - Remove useless code in hpi_meter_get_peak() · f51ba114
      Valentina Goncharenko authored
      The hpi_meter_get_peak() function contains the expression
      "hm.obj_index = hm.obj_index", which does not carry any semantic load.
      
      Found by Linux Verification Center (linuxtesting.org) with SVACE.
      
      Fixes: 719f82d3 ("ALSA: Add support of AudioScience ASI boards")
      Signed-off-by: default avatarValentina Goncharenko <goncharenko.vp@ispras.ru>
      Link: https://lore.kernel.org/r/20220901102814.131855-1-goncharenko.vp@ispras.ruSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f51ba114
    • Takashi Iwai's avatar
      ALSA: usb-audio: Drop superfluous interface setup at parsing · ac5e2fb4
      Takashi Iwai authored
      We reset each interface that is being parsed for each stream, but this
      is superfluous and even can lead to spurious errors.  Since the
      interface is set up properly at opening the endpoint for each actual
      stream operation, let's drop the superfluous one.
      
      Link: https://lore.kernel.org/r/20220831130021.4762-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      ac5e2fb4
    • 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
  13. 30 Aug, 2022 1 commit
  14. 28 Aug, 2022 2 commits
  15. 26 Aug, 2022 1 commit
  16. 25 Aug, 2022 1 commit