Skip to content
  1. Oct 15, 2021
  3. Oct 14, 2021
    • Takashi Iwai's avatar
      ALSA: usb-audio: Initialize every feature unit once at probe time · b96681bd
      Takashi Iwai authored 
      

So far we used to read the current value of the mixer element
dynamically at the first access, and the error from a GET_CUR message
is treated as a fatal error (unless QUIRK_IGNORE_CTL_ERROR is set).
It's rather inconvenient, as most of GET_CUR errors are no fatal, and
we can continue operation with assumption of some fixed value.

This patch makes the USB-audio driver to change the behavior at probe
time; now it tries to initialize the current value of each mixer
element that is built from a feature unit (those for typically for
mixer volumes and switches).  When a read failure happens, it tries to
set the known minimum value.  After that point, a cached value is used
always, hence we won't hit GET_CUR message error any longer.

The error from GET_CUR message is still shown as a warning normally,
but only once at the probe time, and it'll keep operating.  If the
message is confirmed to be harmless, it can be shut up by
QUIRK_IGNORE_CTL_ERROR quirk flag, too.

Tested-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20211014130636.17860-4-tiwai@suse.de
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      b96681bd
    • Takashi Iwai's avatar
      ALSA: usb-audio: Drop superfluous error message after disconnection · 509975c7
      Takashi Iwai authored 
      

The error from snd_usb_lock_shutdown() indicates that the device is
disconnected, hence it makes no sense to show any further control
message error in get_ctl_value_v2().  Return the error directly
instead.

Tested-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20211014130636.17860-3-tiwai@suse.de
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      509975c7
    • Takashi Iwai's avatar
      ALSA: usb-audio: Downgrade error message in get_ctl_value_v2() · ac9b019d
      Takashi Iwai authored 
      

The error message in get_ctl_value_v2() (for UAC2/3) is shown via
KERN_ERR level but it was intended to be rather a debug message as
seen in get_ctl_value_v1() (for UAC1).  This patch downgrade the
printk level.

Tested-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20211014130636.17860-2-tiwai@suse.de
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      ac9b019d
    • Takashi Iwai's avatar
      Merge branch 'for-linus' into for-next · 6f00d165
      Takashi Iwai authored 
      

A back-merge of 5.15 branch into 5.16-devel branch for further
development of USB and ALSA core stuff that depends on 5.15 fixes.

Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6f00d165
    • Steven Clarkson's avatar
      ALSA: hda/realtek: Add quirk for Clevo PC50HS · aef454b4
      Steven Clarkson authored 
      

Apply existing PCI quirk to the Clevo PC50HS and related models to fix
audio output on the built in speakers.

Signed-off-by: default avatarSteven Clarkson <sc@lambdal.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211014133554.1326741-1-sc@lambdal.com
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      aef454b4
    • Greg Kroah-Hartman's avatar
      ALSA: usb-audio: add Schiit Hel device to quirk table · 22390ce7
      Greg Kroah-Hartman authored 
      

The Shciit Hel device responds to the ctl message for the mic capture
switch with a timeout of -EPIPE:

	usb 7-2.2: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1
	usb 7-2.2: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1
	usb 7-2.2: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1
	usb 7-2.2: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1

This seems safe to ignore as the device works properly with the control
message quirk, so add it to the quirk table so all is good.

Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: alsa-devel@alsa-project.org
Cc: linux-usb@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/YWgR3nOI1osvr5Yo@kroah.com
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      22390ce7
  5. Oct 13, 2021
    • Jonas Hahnfeld's avatar
      ALSA: usb-audio: Add quirk for VF0770 · 48827e1d
      Jonas Hahnfeld authored 
      

The device advertises 8 formats, but only a rate of 48kHz is honored
by the hardware and 24 bits give chopped audio, so only report the
one working combination. This fixes out-of-the-box audio experience
with PipeWire which otherwise attempts to choose S24_3LE (while
PulseAudio defaulted to S16_LE).

Signed-off-by: default avatarJonas Hahnfeld <hahnjo@hahnjo.de>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211012200906.3492-1-hahnjo@hahnjo.de
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      48827e1d
    • Kai Vehmanen's avatar
      ALSA: hda: avoid write to STATESTS if controller is in reset · b37a1518
      Kai Vehmanen authored 
      The snd_hdac_bus_reset_link() contains logic to clear STATESTS register
before performing controller reset. This code dates back to an old
bugfix in commit e8a7f136 ("[ALSA] hda-intel - Improve HD-audio
codec probing robustness"). Originally the code was added to
azx_reset().

The code was moved around in commit a41d1224

 ("ALSA: hda - Embed bus
into controller object") and ended up to snd_hdac_bus_reset_link() and
called primarily via snd_hdac_bus_init_chip().

The logic to clear STATESTS is correct when snd_hdac_bus_init_chip() is
called when controller is not in reset. In this case, STATESTS can be
cleared. This can be useful e.g. when forcing a controller reset to retry
codec probe. A normal non-power-on reset will not clear the bits.

However, this old logic is problematic when controller is already in
reset. The HDA specification states that controller must be taken out of
reset before writing to registers other than GCTL.CRST (1.0a spec,
3.3.7). The write to STATESTS in snd_hdac_bus_reset_link() will be lost
if the controller is already in reset per the HDA specification mentioned.

This has been harmless on older hardware. On newer generation of Intel
PCIe based HDA controllers, if configured to report issues, this write
will emit an unsupported request error. If ACPI Platform Error Interface
(APEI) is enabled in kernel, this will end up to kernel log.

Fix the code in snd_hdac_bus_reset_link() to only clear the STATESTS if
the function is called when controller is not in reset. Otherwise
clearing the bits is not possible and should be skipped.

Signed-off-by: default avatarKai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20211012142935.3731820-1-kai.vehmanen@linux.intel.com
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      b37a1518
  7. Oct 12, 2021
    • Takashi Iwai's avatar
      ALSA: usb-audio: Less restriction for low-latency playback mode · 53451b6d
      Takashi Iwai authored 
      The recent support for the improved low-latency playback mode applied
the SNDRV_PCM_INFO_EXPLICIT_SYNC flag for the target streams, but this
was a slight overkill.  The use of the flag above disables effectively
both PCM status and control mmaps, while basically what we want to
track is only about the appl_ptr update.

For less restriction, use a more proper flag,
SNDRV_PCM_INFO_SYNC_APPLPTR instead, which disables only the control
mmap.

Fixes: d5f871f8

 ("ALSA: usb-audio: Improved lowlatency playback support")
Link: https://lore.kernel.org/r/20211011103650.10182-1-tiwai@suse.de
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      53451b6d
    • Hui Wang's avatar
      ALSA: hda/realtek: Fix the mic type detection issue for ASUS G551JW · a3fd1a98
      Hui Wang authored 
      

We need to define the codec pin 0x1b to be the mic, but somehow
the mic doesn't support hot plugging detection, and Windows also has
this issue, so we set it to phantom headset-mic.

Also the determine_headset_type() often returns the omtp type by a
mistake when we plug a ctia headset, this makes the mic can't record
sound at all. Because most of the headset are ctia type nowadays and
some machines have the fixed ctia type audio jack, it is possible this
machine has the fixed ctia jack too. Here we set this mic jack to
fixed ctia type, this could avoid the mic type detection mistake and
make the ctia headset work stable.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214537
Reported-and-tested-by: default avatarmsd <msd.mmq@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20211012114748.5238-1-hui.wang@canonical.com
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      a3fd1a98
    • Takashi Iwai's avatar
      ALSA: pcm: Workaround for a wrong offset in SYNC_PTR compat ioctl · 228af5a4
      Takashi Iwai authored 
      Michael Forney reported an incorrect padding type that was defined in
the commit 80fe7430 ("ALSA: add new 32-bit layout for
snd_pcm_mmap_status/control") for PCM control mmap data.
His analysis is correct, and this caused the misplacements of PCM
control data on 32bit arch and 32bit compat mode.

The bug is that the __pad2 definition in __snd_pcm_mmap_control64
struct was wrongly with __pad_before_uframe, which should have been
__pad_after_uframe instead.  This struct is used in SYNC_PTR ioctl and
control mmap.  Basically this bug leads to two problems:

- The offset of avail_min field becomes wrong, it's placed right after
  appl_ptr without padding on little-endian

- When appl_ptr and avail_min are read as 64bit values in kernel side,
  the values become either zero or corrupted (mixed up)

One good news is that, because both user-space and kernel
misunderstand the wrong offset, at least, 32bit application running on
32bit kernel works as is.  Also, 64bit applications are unaffected
because the padding size is zero.  The remaining problem is the 32bit
compat mode; as mentioned in the above, avail_min is placed right
after appl_ptr on little-endian archs, 64bit kernel reads bogus values
for appl_ptr updates, which may lead to streaming bugs like jumping,
XRUN or whatever unexpected.
(However, we haven't heard any serious bug reports due to this over
years, so practically seen, it's fairly safe to assume that the impact
by this bug is limited.)

Ideally speaking, we should correct the wrong mmap status control
definition.  But this would cause again incompatibility with the
existing binaries, and fixing it (e.g. by renumbering ioctls) would be
really messy.

So, as of this patch, we only correct the behavior of 32bit compat
mode and keep the rest as is.  Namely, the SYNC_PTR ioctl is now
handled differently in compat mode to read/write the 32bit values at
the right offsets.  The control mmap of 32bit apps on 64bit kernels
has been already disabled (which is likely rather an overlook, but
this worked fine at this time :), so covering SYNC_PTR ioctl should
suffice as a fallback.

Fixes: 80fe7430

 ("ALSA: add new 32-bit layout for snd_pcm_mmap_status/control")
Reported-by: default avatarMichael Forney <mforney@mforney.org>
Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
Cc: <stable@vger.kernel.org>
Cc: Rich Felker <dalias@libc.org>
Link: https://lore.kernel.org/r/29QBMJU8DE71E.2YZSH8IHT5HMH@mforney.org
Link: https://lore.kernel.org/r/20211010075546.23220-1-tiwai@suse.de
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      228af5a4
  9. Oct 11, 2021
  11. Oct 07, 2021
    • Takashi Iwai's avatar
      ALSA: usb-audio: Pass JOINT_DUPLEX info flag for implicit fb streams · 59d7f5f6
      Takashi Iwai authored 
      

When a stream is in the implicit feedback mode, it's more or less tied
with a capture stream.  Passing SNDRV_PCM_INFO_JOINT_DUPLEX may help
for user-space to understand the situation.

Link: https://lore.kernel.org/r/20211007083528.4184-1-tiwai@suse.de
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      59d7f5f6
    • Takashi Iwai's avatar
      ALSA: pcm: Add more disconnection checks at file ops · 36df2427
      Takashi Iwai authored 
      

In the case of hot-disconnection of a PCM device, all file operations
except for close should be rejected.  This patch adds more sanity
checks in the file operation code paths.

Link: https://lore.kernel.org/r/20211006142214.3089-1-tiwai@suse.de
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      36df2427
    • Takashi Iwai's avatar
      ALSA: hda: intel: Allow repeatedly probing on codec configuration errors · c0f1886d
      Takashi Iwai authored 
      

It seems that a few recent AMD systems show the codec configuration
errors at the early boot, while loading the driver at a later stage
works magically.  Although the root cause of the error isn't clear,
it's certainly not bad to allow retrying the codec probe in such a
case if that helps.

This patch adds the capability for retrying the probe upon codec probe
errors on the certain AMD platforms.  The probe_work is changed to a
delayed work, and at the secondary call, it'll jump to the codec
probing.

Note that, not only adding the re-probing, this includes the behavior
changes in the codec configuration function.  Namely,
snd_hda_codec_configure() won't unregister the codec at errors any
longer.  Instead, its caller, azx_codec_configure() unregisters the
codecs with the probe failures *if* any codec has been successfully
configured.  If all codec probe failed, it doesn't unregister but let
it re-probed -- which is the most case we're seeing and this patch
tries to improve.

Even if the driver doesn't re-probe or give up, it will go to the
"free-all" error path, hence the leftover codecs shall be disabled /
deleted in anyway.

BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1190801
Link: https://lore.kernel.org/r/20211006141940.2897-1-tiwai@suse.de
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      c0f1886d
  13. Oct 06, 2021
    • Werner Sembach's avatar
      ALSA: hda/realtek: Add quirk for TongFang PHxTxX1 · dd6dd6e3
      Werner Sembach authored 
      

This applies a SND_PCI_QUIRK(...) to the TongFang PHxTxX1 barebone. This
fixes the issue of the internal Microphone not working after booting
another OS.

When booting a certain another OS this barebone keeps some coeff settings
even after a cold shutdown. These coeffs prevent the microphone detection
from working in Linux, making the Laptop think that there is always an
external microphone plugged-in and therefore preventing the use of the
internal one.

The relevant indexes and values where gathered by naively diff-ing and
reading a working and a non-working coeff dump.

Signed-off-by: default avatarWerner Sembach <wse@tuxedocomputers.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211006130415.538243-1-wse@tuxedocomputers.com
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      dd6dd6e3
  15. Oct 05, 2021
  17. Oct 04, 2021
  19. Oct 01, 2021
  21. Sep 30, 2021
    • Takashi Iwai's avatar
      ALSA: seq: Fix a potential UAF by wrong private_free call order · 1f8763c5
      Takashi Iwai authored 
      John Keeping reported and posted a patch for a potential UAF in
rawmidi sequencer destruction: the snd_rawmidi_dev_seq_free() may be
called after the associated rawmidi object got already freed.
After a deeper look, it turned out that the bug is rather the
incorrect private_free call order for a snd_seq_device.  The
snd_seq_device private_free gets called at the release callback of the
sequencer device object, while this was rather expected to be executed
at the snd_device call chains that runs at the beginning of the whole
card-free procedure.  It's been broken since the rewrite of
sequencer-device binding (although it hasn't surfaced because the
sequencer device release happens usually right along with the card
device release).

This patch corrects the private_free call to be done in the right
place, at snd_seq_device_dev_free().

Fixes: 7c37ae5c

 ("ALSA: seq: Rewrite sequencer device binding with standard bus")
Reported-and-tested-by: default avatarJohn Keeping <john@metanate.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210930114114.8645-1-tiwai@suse.de
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      1f8763c5
    • Takashi Iwai's avatar
      ALSA: usb-audio: Avoid killing in-flight URBs during draining · 813a17ca
      Takashi Iwai authored 
      

While draining a stream, ALSA PCM core stops the stream by issuing
snd_pcm_stop() after all data has been sent out.  And, at PCM trigger
stop, currently USB-audio driver kills the in-flight URBs explicitly,
then at sync-stop ops, sync with the finish of all remaining URBs.
This might result in a drop of the drained samples as most of
USB-audio devices / hosts allow relatively long in-flight samples (as
a sort of FIFO).

For avoiding the trimming, this patch changes the stream-stop behavior
during PCM draining state.  Under that condition, the pending URBs
won't be killed.  The leftover in-flight URBs are caught by the
sync-stop operation that shall be performed after the trigger-stop
operation.

Link: https://lore.kernel.org/r/20210929080844.11583-10-tiwai@suse.de
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      813a17ca
    • Takashi Iwai's avatar
      ALSA: usb-audio: Improved lowlatency playback support · d5f871f8
      Takashi Iwai authored 
      This is another attempt to improve further the handling of playback
stream in the low latency mode.  The latest workaround in commit
4267c5a8 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily.  In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.

Now, in this patch, instead of the previous workaround, we take a
similar approach as used in the implicit feedback mode.  The URBs are
queued at the PCM trigger start like before, but we check whether the
buffer has been already filled enough before each submission, and
stop queuing if the data overcomes the threshold.  The remaining URBs
are kept in the ready list, and they will be retrieved in the URB
complete callback of other (already queued) URBs.  In the complete
callback, we try to fill the data and submit as much as possible
again.  When there is no more available in-flight URBs that may handle
the pending data, we'll check in PCM ack callback and submit and
process URBs there in addition.  In this way, the amount of in-flight
URBs may vary dynamically and flexibly depending on the available data
without hitting XRUN.

The following things are changed to achieve the behavior above:

* The endpoint prepare callback is changed to return an error code;
  when there is no enough data available, it may return -EAGAIN.
  Currently only prepare_playback_urb() returns the error.

  The evaluation of the available data is a bit messy here; we can't
  check with snd_pcm_avail() at the point of prepare callback (as
  runtime->status->hwptr hasn't been updated yet), hence we manually
  estimate the appl_ptr and compare with the internal hwptr_done to
  calculate the available frames.

* snd_usb_endpoint_start() doesn't submit full URBs if the prepare
  callback returns -EAGAIN, and puts the remaining URBs to the ready
  list for the later submission.

* snd_complete_urb() treats the URBs in the low-latency mode similarly
  like the implicit feedback mode, and submissions are done in
  (now exported) snd_usb_queue_pending_output_urbs().

* snd_usb_queue_pending_output_urbs() again checks the error value
  from the prepare callback.  If it's -EAGAIN for the normal stream
  (i.e. not implicit feedback mode), we push it back to the ready list
  again.

* PCM ack callback is introduced for the playback stream, and it calls
  snd_usb_queue_pending_output_urbs() if there is no in-flight URB
  while the stream is running.  This corresponds to the case where the
  system needs the appl_ptr update for re-submitting a new URB.

* snd_usb_queue_pending_output_urbs() and the prepare EP callback
  receive in_stream_lock argument, which is a bool flag indicating the
  call path from PCM ack.  It's needed for avoiding the deadlock of
  snd_pcm_period_elapsed() calls.

* Set the new SNDRV_PCM_INFO_EXPLICIT_SYNC flag when the new
  low-latency mode is deployed.  This assures catching each applptr
  update even in the mmap mode.

Fixes: 4267c5a8

 ("ALSA: usb-audio: Work around for XRUN with low latency playback")
Link: https://lore.kernel.org/r/20210929080844.11583-9-tiwai@suse.de
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d5f871f8
    • Takashi Iwai's avatar
      ALSA: usb-audio: Add spinlock to stop_urbs() · 0ef74366
      Takashi Iwai authored 
      

In theory, stop_urbs() may be called concurrently.
Although we have the state check beforehand, it's safer to apply
ep->lock during the critical list head manipulations.

Link: https://lore.kernel.org/r/20210929080844.11583-8-tiwai@suse.de
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      0ef74366