The USB audio device 0db0:419c based on the Realtek ALC4080 chip exposes
all playback volume controls as "PCM". This is makes distinguishing the
individual functions hard.
The added mapping distinguishes all playback volume controls as their
respective function:
- Speaker - for back panel output
- Frontpanel Headphone - for front panel output
- IEC958 - for digital output on the back panel
This clarifies the individual volume control functions for users.
Signed-off-by: Johannes Schickel <lordhoto@gmail.com>
Link: https://lore.kernel.org/r/20220115140257.8751-1-lordhoto@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Olivia Mackintosh has posted to alsa-devel reporting that
there's a potential bug that could break mixer quirks for Pioneer
devices introduced by 6d27788160
"ALSA: usb-audio: Add support for the Pioneer DJM 750MK2
Mixer/Soundcard".
This happened because the DJM 750 MK2 was added last to the Pioneer DJM
device table index and defined as 0x4 but was added to snd_djm_devices[]
just after the DJM 750 (MK1) entry instead of last, after the DJM 900
NXS2. This escaped review.
To prevent that from ever happening again, Takashi Iwai suggested to use
C99 array designators in snd_djm_devices[] instead of simply reordering
the entries.
Fixes: 6d27788160 ("ALSA: usb-audio: Add support for the Pioneer DJM 750MK2")
Reported-by: Olivia Mackintosh <livvy@base.nu>
Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Geraldo Nascimento <geraldogabriel@gmail.com>
Link: https://lore.kernel.org/r/Yau46FDzoql0SNnW@geday
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change made mistakenly the stream for capture started at
prepare stage. Add the stream direction check to avoid it.
Fixes: 9c9a3b9da8 ("ALSA: usb-audio: Rename early_playback_start flag with lowlatency_playback")
Link: https://lore.kernel.org/r/20211119102629.7476-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent regression report revealed that the judgment of the
low-latency playback mode based on the runtime->stop_threshold cannot
work reliably at the prepare stage, as sw_params call may happen at
any time, and PCM dmix actually sets it up after the prepare call.
This ended up with the stall of the stream as PCM ack won't be issued
at all.
For addressing this, check the free-wheeling mode again at the PCM
trigger right before starting the stream again, and allow switching to
the non-LL mode at a late stage.
Fixes: d5f871f89e ("ALSA: usb-audio: Improved lowlatency playback support")
Reported-and-tested-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Link: https://lore.kernel.org/r/20211117161855.m45mxcqszkfcetai@box.shutemov.name
Link: https://lore.kernel.org/r/20211119102459.7055-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some devices do mute the volume at the minimal volume, and for such
devices, we need to set SNDRV_CTL_TLVT_DB_MINMAX_MUTE to the TLV
information. It corresponds to setting usb_mixer_elem_info.min_mute
flag in the USB-audio driver.
This patch adds a new field min_mute in usbmix_dB_map so that the
mixer map entry can pass the flag.
Link: https://lore.kernel.org/r/20211116065415.11159-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The values in usbmix_dB_map should be rather signed while we're using
u32. As the copied target (usb_mixer_elem_info.dBmin and dBmax) is
int, let's make them also int.
Link: https://lore.kernel.org/r/20211116065415.11159-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Adding the Line6 HX-Stomp XL USB_ID as it needs this fixed frequency
quirk as well.
The device is basically just the HX-Stomp with some more buttons on
the face. I've done some recording with it after adding it, and it
seems to function properly with this fix. The Midi features appear to
be working as well.
[ a coding style fix and patch reformat by tiwai ]
Signed-off-by: Jason Ormes <skryking@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211030200405.1358678-1-skryking@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add another device ID for JBL Quantum 400. It requires the same quirk as
other JBL Quantum devices.
Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211030174308.1011825-1-alexander@tsoy.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add the missing endpoint max-packet sanity check to probe() to avoid
division by zero in alloc_stream_buffers() in case a malicious device
has broken descriptors (or when doing descriptor fuzz testing).
Note that USB core will reject URBs submitted for endpoints with zero
wMaxPacketSize but that drivers doing packet-size calculations still
need to handle this (cf. commit 2548288b4f ("USB: Fix: Don't skip
endpoint descriptors with maxpacket=0")).
Fixes: 63978ab3e3 ("sound: add Edirol UA-101 support")
Cc: stable@vger.kernel.org # 2.6.34
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20211026095401.26522-1-johan@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
USB control and bulk message timeouts are specified in milliseconds and
should specifically not vary with CONFIG_HZ.
Fixes: c6d43ba816 ("ALSA: usb/6fire - Driver for TerraTec DMX 6Fire USB")
Cc: stable@vger.kernel.org # 2.6.39
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20211025121142.6531-2-johan@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The pointer cs_desc return from snd_usb_find_clock_source could
be null, so there is a potential null pointer dereference issue.
Fix this by adding a null check before dereference.
Signed-off-by: Chengfeng Ye <cyeaa@connect.ust.hk>
Link: https://lore.kernel.org/r/20211024111736.11342-1-cyeaa@connect.ust.hk
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When a Jieli Technology USB Webcam is connected, the video part works
well, but the mic sound is speeded up. On dmesg there are messages
about different rates from the runtime rates, warnings about volume
resolution and lastly, the log is filled, every 5 seconds, with
retire_capture_urb error messages.
The mic works only when ep packet size is set to wMaxPacketSize (normal
sound and no more retire_capture_urb error messages). Skipping reading
sample rate, fixes the messages about different rates and forcing a volume
resolution, fixes warnings about volume range. I have arbitrarily choosed
the value (16): I read in a comment that there should be no more than 255
levels, so 4096 (max volume) / 16 = 0-255.
Signed-off-by: Marco Giunta <giun7a@gmail.com>
Link: https://lore.kernel.org/r/20211018162552.12082-1-giun7a@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As per discussion at: https://github.com/szszoke/sennheiser-gsp670-pulseaudio-profile/issues/13
The GSP670 has 2 playback and 1 recording device that by default are
detected in an incompatible order for alsa. This may have been done to make
it compatible for the console by the manufacturer and only affects the
latest firmware which uses its own ID.
This quirk will resolve this by reordering the channels.
Signed-off-by: Brendan Grieve <brendan@grieve.com.au>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211015025335.196592-1-brendan@grieve.com.au
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20211014130636.17860-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20211014130636.17860-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20211014130636.17860-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: Takashi Iwai <tiwai@suse.de>
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/YWgR3nOI1osvr5Yo@kroah.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: Jonas Hahnfeld <hahnjo@hahnjo.de>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211012200906.3492-1-hahnjo@hahnjo.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: d5f871f89e ("ALSA: usb-audio: Improved lowlatency playback support")
Link: https://lore.kernel.org/r/20211011103650.10182-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The kernel already has support for very similar Pioneer djm products
and this work is based on that.
Added device to quirks-table.h and added control info to
mixer_quirks.c.
Tested on my hardware and all working.
Signed-off-by: William Overton <willovertonuk@gmail.com>
Link: https://lore.kernel.org/r/20211010145841.11907-1-willovertonuk@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: Takashi Iwai <tiwai@suse.de>
The Scarlett device series from Focusrite Novation seem requiring the
sample rate validations as we've done for MOTU devices; otherwise the
driver probes invalid audioformat entries that contain the sample
rates that actually don't work, and this may result in an incomplete
setup as reported recently.
This patch adds the needed quirk flag for enabling the sample rate
validation for Focusrite Novation devices.
Fixes: fe773b8711 ("ALSA: usb-audio: workaround for iface reset issue")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214493
Link: https://lore.kernel.org/r/20211004074050.28241-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Behringer UFX1204 and UFX1604 have Synchronous endpoints to which
current ALSA code applies implicit feedback sync as if they were
Asynchronous endpoints. This breaks UAC compliance and is unneeded.
The commit 5e35dc0338 and subsequent
1a15718b41 were meant to clear up noise.
Unfortunately, noise persisted for those using higher sample rates and
this was only solved by commit d2e8f64125
Since there are no more reports of noise, let's get rid of the
implicit-fb quirks breaking UAC compliance.
Signed-off-by: Geraldo Nascimento <geraldogabriel@gmail.com>
Link: https://lore.kernel.org/r/YVYSnoQ7nxLXT0Dq@geday
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: Takashi Iwai <tiwai@suse.de>
This is another attempt to improve further the handling of playback
stream in the low latency mode. The latest workaround in commit
4267c5a8f3 ("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: 4267c5a8f3 ("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: Takashi Iwai <tiwai@suse.de>
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: Takashi Iwai <tiwai@suse.de>
This is yet more preparation for the upcoming changes.
Extend snd_usb_endpoint_next_packet_size() to check the available
frames and return -EAGAIN if the next packet size is equal or exceeds
the given size. This will be needed for avoiding XRUN during the low
latency operation.
As of this patch, avail=0 is passed, i.e. the check is skipped and no
behavior change.
Link: https://lore.kernel.org/r/20210929080844.11583-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When a playback stream runs in the implicit feedback mode, its
operation is passive and won't start unless the capture packet is
received. This behavior contradicts with the low-latency playback
mode, and we should turn off lowlatency_playback flag accordingly.
In theory, we may take the low-latency mode when the playback-first
quirk is set, but it still conflicts with the later operation with the
fixed packet numbers, so it's disabled all together for now.
Link: https://lore.kernel.org/r/20210929080844.11583-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The free-wheel stream operation like dmix may not update the appl_ptr
appropriately, and it doesn't fit with the low-latency playback mode.
Disable the low-latency playback operation when the stream is set up
in such a mode.
Link: https://lore.kernel.org/r/20210929080844.11583-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a preparation patch for the upcoming low-latency improvement
changes.
Rename early_playback_start flag with lowlatency_playback as it's more
intuitive. The new flag is basically a reverse meaning.
Along with the rename, factor out the code to set the flag to a
function. This makes the complex condition checks simpler.
Also, the same flag is introduced to snd_usb_endpoint, too, that is
carried from the snd_usb_substream flag. Currently the endpoint flag
isn't still referred, but will be used in later patches.
Link: https://lore.kernel.org/r/20210929080844.11583-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
USB-audio driver tries to sync with the clear of all pending URBs in
wait_clear_urbs(), and it waits for all bits in active_mask getting
cleared. This works fine for the normal operations, but when a stream
is managed in the implicit feedback mode, there is still a very thin
race window: namely, in snd_complete_usb(), the active_mask bit for
the current URB is once cleared before re-submitted in
queue_pending_output_urbs(). If wait_clear_urbs() is called during
that period, it may pass the test and go forward even though there may
be a still pending URB.
For covering it, this patch adds a new counter to each endpoint to
keep the number of in-flight URBs, and changes wait_clear_urbs()
checking this number instead. The counter is decremented at the end
of URB complete, hence the reference is kept as long as the URB
complete is in process.
Link: https://lore.kernel.org/r/20210929080844.11583-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When a single clock source is shared among several endpoints, we have
to keep the same rate on all active endpoints as long as the clock is
being used. For dealing with such a case, this patch adds one more
check in the hw params constraint for the rate to take the shared
clocks into account. The current rate is evaluated from the endpoint
list that applies the same clock source.
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1190418
Link: https://lore.kernel.org/r/20210929080844.11583-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_usb_find_clock_source and snd_usb_find_clock_selector are helper
macros that look at an entity id and validate that this entity id is
in fact a clock source or a clock selector. The present comments
inside __uac_clock_find_source give the reader the impression we're
looking for an entity id.
We're looking for an entity id indeed, the clock source, but since
__uac_clock_find_source is recursive, we're also looking *at* the
entity ids, in the search for the one clock source.
Fix the comment so we don't give readers a wrong idea.
Signed-off-by: Geraldo Nascimento <geraldogabriel@gmail.com>
Link: https://lore.kernel.org/r/YU6Kj05oOqRmhJDf@geday
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As noted in the "Deprecated Interfaces, Language Features, Attributes,
and Conventions" documentation [1], size calculations (especially
multiplication) should not be performed in memory allocator (or similar)
function arguments due to the risk of them overflowing. This could lead
to values wrapping around and a smaller allocation being made than the
caller was expecting. Using those allocations could lead to linear
overflows of heap memory and other misbehaviors.
In this case this is not actually dynamic size: all the operands
involved in the calculation are constant values. However it is better to
refactor this anyway, just to keep the open-coded math idiom out of
code.
So, use the struct_size() helper to do the arithmetic instead of the
argument "size + size * count" in the kzalloc() function.
Also, take the opportunity to refactor the declaration variables to make
it more easy to read.
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments
Signed-off-by: Len Baker <len.baker@gmx.com>
Link: https://lore.kernel.org/r/20210919133727.44694-1-len.baker@gmx.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
USB-audio driver assumes that the normal resume would preserve the
device configuration while reset_resume wouldn't, and tries to restore
the mixer elements only at reset_resume callback. However, this seems
too naive, and some devices do behave differently, resetting the
volume at the normal resume; this resulted in the inconsistent volume
that surprised users.
This patch changes the mixer resume code to handle both the normal and
reset resume in the same way, always restoring the original mixer
element values. This allows us to unify the both callbacks as well as
dropping the no longer used reset_resume field, which ends up with a
good code reduction.
A slight behavior change by this patch is that now we assign
restore_mixer_value() as the default resume callback, and the function
is no longer called at reset-resume when the resume callback is
overridden by the quirk function. That is, if needed, the quirk
resume function would have to handle similarly as
restore_mixer_value() by itself.
Reported-by: En-Shuo Hsu <enshuo@chromium.org>
Cc: Yu-Hsuan Hsu <yuhsuan@chromium.org>
Link: https://lore.kernel.org/r/CADDZ45UPsbpAAqP6=ZkTT8BE-yLii4Y7xSDnjK550G2DhQsMew@mail.gmail.com
Link: https://lore.kernel.org/r/20210910105155.12862-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add another device ID for JBL Quantum 800. It requires the same quirk as
other JBL Quantum devices.
Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20210831002531.116957-1-alexander@tsoy.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For making user to switch back to the old playback mode, this patch
adds a new module option 'lowlatency' to snd-usb-audio driver.
When user face a regression due to the recent low-latency playback
support, they can test easily by passing lowlatency=0 option without
rebuilding the kernel.
Fixes: 307cc9baac ("ALSA: usb-audio: Reduce latency at playback start, take#2")
Link: https://lore.kernel.org/r/20210829073830.22686-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: 307cc9baac ("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: Takashi Iwai <tiwai@suse.de>
