Maris found out that the quirk for TEAC devices to work around the
clock setup is needed to apply only when the base clock is changed,
e.g. from 48000-based clocks (48000, 96000, 192000, 384000) to
44100-based clocks (44100, 88200, 176400, 352800), or vice versa,
while switching to another clock with the same base clock doesn't need
the (forcible) interface setup.
This patch implements the optimization for the TEAC clock quirk to
avoid the unnecessary interface re-setup.
Fixes: 5ce0b06ae5e6 ("ALSA: usb-audio: Workaround for clock setup on TEAC devices")
Reported-by: Maris Abele <maris7abele@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220531130749.30357-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Maris reported that TEAC UD-501 (0644:8043) doesn't work with the
typical "clock source 41 is not valid, cannot use" errors on the
recent kernels. The currently known workaround so far is to restore
(partially) what we've done unconditionally at the clock setup;
namely, re-setup the USB interface immediately after the clock is
changed. This patch re-introduces the behavior conditionally for TEAC
devices.
Further notes:
- The USB interface shall be set later in
snd_usb_endpoint_configure(), but this seems to be too late.
- Even calling usb_set_interface() right after
sne_usb_init_sample_rate() doesn't help; so this must be related
with the clock validation, too.
- The device may still spew the "clock source 41 is not valid" error
at the first clock setup. This seems happening at the very first
try of clock setup, but it disappears at later attempts.
The error is likely harmless because the driver retries the clock
setup (such an error is more or less expected on some devices).
Fixes: bf6313a0ff76 ("ALSA: usb-audio: Refactor endpoint management")
Reported-and-tested-by: Maris Abele <maris7abele@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220521064627.29292-1-tiwai@suse.de
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>
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>
There are a couple of device-specific quirks in the clock setup code, and those can be moved gracefully to quirk_flags, too. Link: https://lore.kernel.org/r/20210729073855.19043-7-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
As more and more device-specific workarounds came up and gathered in various places, it becomes harder to manage. Now it's time to clean up and collect workarounds more consistently and make them more easily applicable. This patch is the first step for that: a new field quirk_flags is introduced in snd_usb_audio struct to contain the bit flags for various device-specific quirks. Those are separate one from the quirks in quirks-table.h; the quirks-table.h entries are for more intrusive stuff that needs the descriptor override, while the new quirk_flags is for easier ones that are tied with the vendor:product IDs. In this patch, as the first example, we convert the list of devices and vendors to ignore GET_SAMPLE_RATE, formerly defined in snb_usb_get_sample_rate_quirk(). Link: https://lore.kernel.org/r/20210729073855.19043-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
The following scenario describes an echo test for
Samsung USBC Headset (AKG) with VID/PID (0x04e8/0xa051).
We first start a capture stream(USB IN transfer) in 96Khz/24bit/1ch mode.
In clock find source function, we get value 0x2 for clock selector
and 0x1 for clock source.
Kernel-4.14 behavior
Since clock source is valid so clock selector was not set again.
We pass through this function and start a playback stream(USB OUT transfer)
in 48Khz/32bit/2ch mode. This time we get value 0x1 for clock selector
and 0x1 for clock source. Finally clock id with this setting is 0x9.
Kernel-5.10 behavior
Clock selector was always set one more time even it is valid.
When we start a playback stream, we will get 0x2 for clock selector
and 0x1 for clock source. In this case clock id becomes 0xA.
This is an incorrect clock source setting and results in severe noises.
We see wrong data rate in USB IN transfer.
(From 288 bytes/ms becomes 144 bytes/ms) It should keep in 288 bytes/ms.
This earphone works fine on older kernel version load because
this is a newly-added behavior.
Fixes: d2e8f641257d ("ALSA: usb-audio: Explicitly set up the clock selector")
Signed-off-by: chihhao.chen <chihhao.chen@mediatek.com>
Link: https://lore.kernel.org/r/1627100621-19225-1-git-send-email-chihhao.chen@mediatek.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This provides support for Denon DN-X1600 hardware mixer. The device itself supports 44100, 48000 and 96000 (Hz) sample rates, but switching rates via software is currently not working. Therefore, this patch hardcodes the sample rate to 48000Hz which enables all 8 channels to function correctly when the correct sample rate is selected on the hardware itself. MIDI also tested and works. Signed-off-by: Damien Zammit <damien@zamaudio.com> Tested-by: xalmoxis@gmail.com Link: https://lore.kernel.org/r/20210610083528.603942-2-damien@zamaudio.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
The cur variable indicating the currently selected clock source can be
theoretically used as uninitialized after the recent commit
481f17c41803 ("ALSA: usb-audio: Handle error for the current selector
gracefully"). For addressing it, initialize it before use.
Also, one place seems setting 0 to a wrong variable ret, instead of
cur; otherwise it makes little sense. Since the initialization is
done beforehand, we can get rid of this line, too.
Fixes: 481f17c41803 ("ALSA: usb-audio: Handle error for the current selector gracefully")
Reported-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/4b261d68-f53f-240d-2d8a-2f88b337849d@canonical.com
Link: https://lore.kernel.org/r/s5hfsyhh97t.wl-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently we bail out when the device returns an error or an invalid value for the current clock selector value via uac_clock_selector_get_val(). But it's possible that the device is really uninitialized and waits for the setup of the proper route at first. For handling such a case, this patch lets the driver dealing with the error or the invalid error more gracefully, choosing the clock source automatically instead. Link: https://lore.kernel.org/r/20210518152112.8016-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>