| Age | Commit message (Collapse) | Author |
|---|
|
commit 2e40795c3bf344cfb5220d94566205796e3ef19a upstream.
Plantronics BT600 does not support reading the sample rate which leads
to many lines of "cannot get freq at ep 0x1" and "cannot get freq at
ep 0x82". This patch adds the USB ID of the BT600 to quirks.c and
avoids those error messages.
Signed-off-by: Dennis Kadioglu <denk@post.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4763601a56f155ddf94ef35fc2c41504a2de15f5 upstream.
The function returns -EINVAL even if it builds the stream properly.
The bogus error code sneaked in during the code refactoring, but it
wasn't noticed until now since the returned error code itself is
ignored in anyway. Kill it here, but there is no behavior change by
this patch, obviously.
Fixes: e5779998bf8b ('ALSA: usb-audio: refactor code')
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 1d0f953086f090a022f2c0e1448300c15372db46 upstream.
Commit 16200948d83 ("ALSA: usb-audio: Fix race at stopping the stream") was
incomplete causing another more severe kernel panic, so it got reverted.
This fixes both the original problem and its fallout kernel race/crash.
The original fix is to move the endpoint member NULL clearing logic inside
wait_clear_urbs() so the irq triggering the urb completion doesn't call
retire_capture/playback_urb() after the NULL clearing and generate a panic.
However this creates a new race between snd_usb_endpoint_start()'s call
to wait_clear_urbs() and the irq urb completion handler which again calls
retire_capture/playback_urb() leading to a new NULL dereference.
We keep the EP deactivation code in snd_usb_endpoint_start() because
removing it will break the EP reference counting (see [1] [2] for info),
however we don't need the "can_sleep" mechanism anymore because a new
function was introduced (snd_usb_endpoint_sync_pending_stop()) which
synchronizes pending stops and gets called inside the pcm prepare callback.
It also makes sense to remove can_sleep because it was also removed from
deactivate_urbs() signature in [3] so we benefit from more simplification.
[1] commit 015618b90 ("ALSA: snd-usb: Fix URB cancellation at stream start")
[2] commit e9ba389c5 ("ALSA: usb-audio: Fix scheduling-while-atomic bug in PCM capture stream")
[3] commit ccc1696d5 ("ALSA: usb-audio: simplify endpoint deactivation code")
Fixes: f8114f8583bb ("Revert "ALSA: usb-audio: Fix race at stopping the stream"")
Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 995c6a7fd9b9212abdf01160f6ce3193176be503 upstream.
Sampling rate changes after first set one are not reflected to the
hardware, while driver and ALSA think the rate has been changed.
Fix the problem by properly stopping the interface at the beginning of
prepare call, allowing new rate to be set to the hardware. This keeps
the hardware in sync with the driver.
Signed-off-by: Jussi Laako <jussi@sonarnerd.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 82ffb6fc637150b279f49e174166d2aa3853eaf4 upstream.
The Logitech QuickCam Communicate Deluxe/S7500 microphone fails with the
following warning.
[ 6.778995] usb 2-1.2.2.2: Warning! Unlikely big volume range (=3072),
cval->res is probably wrong.
[ 6.778996] usb 2-1.2.2.2: [5] FU [Mic Capture Volume] ch = 1, val =
4608/7680/1
Adding it to the list of devices in volume_control_quirks makes it work
properly, fixing related typo.
Signed-off-by: Con Kolivas <kernel@kolivas.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit bdc3478f90cd4d2928197f36629d5cf93b64dbe9 upstream.
The stk1160 chip needs QUIRK_AUDIO_ALIGN_TRANSFER. This patch resolves
the issue reported on the mailing list
(http://marc.info/?l=linux-sound&m=139223599126215&w=2) and also fixes
bug 180071 (https://bugzilla.kernel.org/show_bug.cgi?id=180071).
Signed-off-by: Marcel Hasler <mahasler@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
manufacturer ID
commit 8da08ca03b73593d5299893bf29fc08569c3fb5f upstream.
Currently, usb-line6 module exports an array of MIDI manufacturer ID and
usb-pod module uses it. However, the declaration is not the definition in
common header. The difference is explicit length of array. Although
compiler calculates it and everything goes well, it's better to use the
same representation between definition and declaration.
This commit fills the length of array for usb-line6 module. As a small
good sub-effect, this commit suppress below warnings from static analysis
by sparse v0.5.0.
sound/usb/line6/driver.c:274:43: error: cannot size expression
sound/usb/line6/driver.c:275:16: error: cannot size expression
sound/usb/line6/driver.c:276:16: error: cannot size expression
sound/usb/line6/driver.c:277:16: error: cannot size expression
Fixes: 705ececd1c60 ("Staging: add line6 usb driver")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit eb1a74b7bea17eea31915c4f76385cefe69d9795 upstream.
The DragonFly quirk added in 42e3121d90f4 ("ALSA: usb-audio: Add a more
accurate volume quirk for AudioQuest DragonFly") applies a custom dB map
on the volume control when its range is reported as 0..50 (0 .. 0.2dB).
However, there exists at least one other variant (hw v1.0c, as opposed
to the tested v1.2) which reports a different non-sensical volume range
(0..53) and the custom map is therefore not applied for that device.
This results in all of the volume change appearing close to 100% on
mixer UIs that utilize the dB TLV information.
Add a fallback case where no dB TLV is reported at all if the control
range is not 0..50 but still 0..N where N <= 1000 (3.9 dB). Also
restrict the quirk to only apply to the volume control as there is also
a mute control which would match the check otherwise.
Fixes: 42e3121d90f4 ("ALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly")
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Reported-by: David W <regulars@d-dub.org.uk>
Tested-by: David W <regulars@d-dub.org.uk>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 83d9956b7e6b310c1062df7894257251c625b22e upstream.
Avoid getting sample rate on B850V3 CP2114 as it is unsupported and
causes noisy "current rate is different from the runtime rate" messages
when playback starts.
Signed-off-by: Ken Lin <ken.lin@advantech.com.tw>
Signed-off-by: Akshay Bhat <akshay.bhat@timesys.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b027d11263836a0cd335520175257dcb99b43757 upstream.
The commit 02fc76f6a changed base of the sysfs attributes from device to card.
The "show" callbacks dereferenced wrong objects because of this.
Fixes: 02fc76f6a7db ('ALSA: line6: Create sysfs via snd_card_add_dev_attr()')
Reviewed-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Andrej Krutak <dev@andree.sk>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit adc8a43a6d6688272ebffa81789fa857e603dec6 upstream.
Done, because line6_stream_stop() locks and calls line6_unlink_audio_urbs(),
which in turn invokes audio_out_callback(), which tries to lock 2nd time.
Fixes:
=============================================
[ INFO: possible recursive locking detected ]
4.4.15+ #15 Not tainted
---------------------------------------------
mplayer/3591 is trying to acquire lock:
(&(&line6pcm->out.lock)->rlock){-.-...}, at: [<bfa27655>] audio_out_callback+0x70/0x110 [snd_usb_line6]
but task is already holding lock:
(&(&line6pcm->out.lock)->rlock){-.-...}, at: [<bfa26aad>] line6_stream_stop+0x24/0x5c [snd_usb_line6]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(&line6pcm->out.lock)->rlock);
lock(&(&line6pcm->out.lock)->rlock);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by mplayer/3591:
#0: (snd_pcm_link_rwlock){.-.-..}, at: [<bf8d49a7>] snd_pcm_stream_lock+0x1e/0x40 [snd_pcm]
#1: (&(&substream->self_group.lock)->rlock){-.-...}, at: [<bf8d49af>] snd_pcm_stream_lock+0x26/0x40 [snd_pcm]
#2: (&(&line6pcm->out.lock)->rlock){-.-...}, at: [<bfa26aad>] line6_stream_stop+0x24/0x5c [snd_usb_line6]
stack backtrace:
CPU: 0 PID: 3591 Comm: mplayer Not tainted 4.4.15+ #15
Hardware name: Generic AM33XX (Flattened Device Tree)
[<c0015d85>] (unwind_backtrace) from [<c001253d>] (show_stack+0x11/0x14)
[<c001253d>] (show_stack) from [<c02f1bdf>] (dump_stack+0x8b/0xac)
[<c02f1bdf>] (dump_stack) from [<c0076f43>] (__lock_acquire+0xc8b/0x1780)
[<c0076f43>] (__lock_acquire) from [<c007810d>] (lock_acquire+0x99/0x1c0)
[<c007810d>] (lock_acquire) from [<c06171e7>] (_raw_spin_lock_irqsave+0x3f/0x4c)
[<c06171e7>] (_raw_spin_lock_irqsave) from [<bfa27655>] (audio_out_callback+0x70/0x110 [snd_usb_line6])
[<bfa27655>] (audio_out_callback [snd_usb_line6]) from [<c04294db>] (__usb_hcd_giveback_urb+0x53/0xd0)
[<c04294db>] (__usb_hcd_giveback_urb) from [<c046388d>] (musb_giveback+0x3d/0x98)
[<c046388d>] (musb_giveback) from [<c04647f5>] (musb_urb_dequeue+0x6d/0x114)
[<c04647f5>] (musb_urb_dequeue) from [<c042ac11>] (usb_hcd_unlink_urb+0x39/0x98)
[<c042ac11>] (usb_hcd_unlink_urb) from [<bfa26a87>] (line6_unlink_audio_urbs+0x6a/0x6c [snd_usb_line6])
[<bfa26a87>] (line6_unlink_audio_urbs [snd_usb_line6]) from [<bfa26acb>] (line6_stream_stop+0x42/0x5c [snd_usb_line6])
[<bfa26acb>] (line6_stream_stop [snd_usb_line6]) from [<bfa26fe7>] (snd_line6_trigger+0xb6/0xf4 [snd_usb_line6])
[<bfa26fe7>] (snd_line6_trigger [snd_usb_line6]) from [<bf8d47b7>] (snd_pcm_do_stop+0x36/0x38 [snd_pcm])
[<bf8d47b7>] (snd_pcm_do_stop [snd_pcm]) from [<bf8d462f>] (snd_pcm_action_single+0x22/0x40 [snd_pcm])
[<bf8d462f>] (snd_pcm_action_single [snd_pcm]) from [<bf8d46f9>] (snd_pcm_action+0xac/0xb0 [snd_pcm])
[<bf8d46f9>] (snd_pcm_action [snd_pcm]) from [<bf8d4b61>] (snd_pcm_drop+0x38/0x64 [snd_pcm])
[<bf8d4b61>] (snd_pcm_drop [snd_pcm]) from [<bf8d6233>] (snd_pcm_common_ioctl1+0x7fe/0xbe8 [snd_pcm])
[<bf8d6233>] (snd_pcm_common_ioctl1 [snd_pcm]) from [<bf8d6779>] (snd_pcm_playback_ioctl1+0x15c/0x51c [snd_pcm])
[<bf8d6779>] (snd_pcm_playback_ioctl1 [snd_pcm]) from [<bf8d6b59>] (snd_pcm_playback_ioctl+0x20/0x28 [snd_pcm])
[<bf8d6b59>] (snd_pcm_playback_ioctl [snd_pcm]) from [<c016714b>] (do_vfs_ioctl+0x3af/0x5c8)
Fixes: 63e20df1e5b2 ('ALSA: line6: Reorganize PCM stream handling')
Reviewed-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Andrej Krutak <dev@andree.sk>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7e4379eae0e31994ea645db1d13006ea8e5ce539 upstream.
If there's an error, pcm is released in line6_pcm_acquire already.
Fixes: 247d95ee6dd2 ('ALSA: line6: Handle error from line6_pcm_acquire()')
Reviewed-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Andrej Krutak <dev@andree.sk>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 41f5e3bdbf706a9e98194bf0c4b62a875c02f170 upstream.
The ELP HD USB Camera (05a3:9420) needs this quirk for suppressing
the unsupported sample rate inquiry.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=98481
Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
(VF0610)
commit 7627e40c66b5547e12b6c5673646ceea84797a74 upstream.
VF0610 does not support reading the sample rate which leads to many
lines of "cannot get freq at ep 0x82". This patch adds the USB ID
(0x041E:4080) to snd_usb_get_sample_rate_quirk() list.
Signed-off-by: Piotr Karasinski <peter.karasinski@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 84add303ef950b8d85f54bc2248c2bc73467c329 upstream.
Phoenix Audio has yet another device with another id (even a different
vendor id, 0556:0014) that requires the same quirk for the sample
rate.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110221
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 2d2c038a9999f423e820d89db2b5d7774b67ba49 upstream.
Phoenix Audio MT202pcs (1de7:0114) and MT202exe (1de7:0013) need the
same workaround as TMX320 for avoiding the firmware bug. It fixes the
frequent error about the sample rate inquiries and the slow device
probe as consequence.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=117321
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit adcdd0d5a1cb779f6d455ae70882c19c527627a8 upstream.
This is Dell usb dock audio workaround.
It was fixed the master volume keep lower.
[Some background: the patch essentially skips the controls of a couple
of FU volumes. Although the firmware exposes the dB and the value
information via the usb descriptor, changing the values (we set the
min volume as default) screws up the device. Although this has been
fixed in the newer firmware, the devices are shipped with the old
firmware, thus we need the workaround in the driver side. -- tiwai]
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b4203ff5464da00b7812e7b480192745b0d66bbf upstream.
Plantronics BT300 does not support reading the sample rate which leads
to many lines of "cannot get freq at ep 0x1". This patch adds the USB
ID of the BT300 to quirks.c and avoids those error messages.
Signed-off-by: Dennis Kadioglu <denk@post.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f03b24a851d32ca85dacab01785b24a7ee717d37 upstream.
Phoenix Audio TMX320 gives the similar error when the sample rate is
asked:
usb 2-1.3: 2:1: cannot get freq at ep 0x85
usb 2-1.3: 1:1: cannot get freq at ep 0x2
....
Add the corresponding USB-device ID (1de7:0014) to
snd_usb_get_sample_rate_quirk() list.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110221
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
snd_usb_add_audio_stream() call
commit 836b34a935abc91e13e63053d0a83b24dfb5ea78 upstream.
create_fixed_stream_quirk(), snd_usb_parse_audio_interface() and
create_uaxx_quirk() functions allocate the audioformat object by themselves
and free it upon error before returning. However, once the object is linked
to a stream, it's freed again in snd_usb_audio_pcm_free(), thus it'll be
double-freed, eventually resulting in a memory corruption.
This patch fixes these failures in the error paths by unlinking the audioformat
object before freeing it.
Based on a patch by Takashi Iwai <tiwai@suse.de>
[Note for stable backports:
this patch requires the commit 902eb7fd1e4a ('ALSA: usb-audio: Minor
code cleanup in create_fixed_stream_quirk()')]
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1283358
Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 902eb7fd1e4af3ac69b9b30f8373f118c92b9729 upstream.
Just a minor code cleanup: unify the error paths.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 0ef21100ae912f76ed89f76ecd894f4ffb3689c1 upstream.
The Microsoft HD-5001 webcam microphone does not support sample rate
reading as the HD-5000 one.
This results in dmesg errors and sound hanging with pulseaudio.
Signed-off-by: Victor Clément <victor.clement@openmailbox.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 447d6275f0c21f6cc97a88b3a0c601436a4cdf2a upstream.
Add some sanity check codes before actually accessing the endpoint via
get_endpoint() in order to avoid the invalid access through a
malformed USB descriptor. Mostly just checking bNumEndpoints, but in
one place (snd_microii_spdif_default_get()), the validity of iface and
altsetting index is checked as well.
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=971125
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 0f886ca12765d20124bd06291c82951fd49a33be upstream.
create_fixed_stream_quirk() may cause a NULL-pointer dereference by
accessing the non-existing endpoint when a USB device with a malformed
USB descriptor is used.
This patch avoids it simply by adding a sanity check of bNumEndpoints
before the accesses.
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=971125
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 17e2df4613be57d0fab68df749f6b8114e453152 upstream.
Plantronics DA45 does not support reading the sample rate which leads
to many lines of "cannot get freq at ep 0x4" and "cannot get freq at
ep 0x84". This patch adds the USB ID of the DA45 to quirks.c and
avoids those error messages.
Signed-off-by: Dennis Kadioglu <denk@post.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 07d86ca93db7e5cdf4743564d98292042ec21af7 upstream.
The 'umidi' object will be free'd on the error path by snd_usbmidi_free()
when tearing down the rawmidi interface. So we shouldn't try to free it
in snd_usbmidi_create() after having registered the rawmidi interface.
Found by KASAN.
Signed-off-by: Andrey Konovalov <andreyknvl@gmail.com>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ad678b4ccd41aa51cf5f142c0e8cffe9d61fc2bf upstream.
This patch adds native DSD support for the PS Audio NuWave DAC.
Signed-off-by: Jurgen Kramer <gtmkramer@xs4all.nl>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5327d6ba975042fd3da50ac6e94d1e9551ebeaec upstream.
In my patch adding native DSD support for the Oppo HA-1, the wrong vendor ID got
through. This patch fixes the vendor ID and aligns the comment.
Fixes: a4eae3a506ea ('ALSA: usb: Add native DSD support for Oppo HA-1')
Signed-off-by: Jurgen Kramer <gtmkramer@xs4all.nl>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 1b3c993a699bed282e47c3f7c49d539c331dae04 upstream.
Microsoft LifeCam HD-6000 (045e:076f) requires the similar quirk for
avoiding the stall due to the invalid sample rate reads.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111491
Signed-off-by: Lev Lybin <lev.lybin@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5a4ff9ec8d6edd2ab1cfe8ce6a080d6e57cbea9a upstream.
TEAC UD-501/UD-503/NT-503 fail to switch properly between different
rate/format. Similar to 'Playback Design', this patch corrects the
invalid clock source error for TEAC products and avoids complete
freeze of the usb interface of 503 series.
Signed-off-by: Guillaume Fougnies <guillaume@eulerian.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c4a359a0049f2e17b012b31e801e96566f6391e5 upstream.
The commit [da6d276957ea: ALSA: usb-audio: Add resume support for
Native Instruments controls] brought a regression where the Native
Instrument audio devices don't get the correct value at update due to
the missing shift at writing. This patch addresses it.
Fixes: da6d276957ea ('ALSA: usb-audio: Add resume support for Native Instruments controls')
Reported-and-tested-by: Owen Williams <owilliams@mixxx.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5c06d68bc2a174a6b82dce9f100f55173b9a5189 upstream.
ALSA PCM may still have a leftover instance after disconnection and
it delays its release. The problem is that the PCM close code path of
USB-audio driver has a call of snd_usb_autosuspend(). This involves
with the call of usb_autopm_put_interface() and it may lead to a
kernel Oops due to the NULL object like:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000190
IP: [<ffffffff815ae7ef>] usb_autopm_put_interface+0xf/0x30 PGD 0
Call Trace:
[<ffffffff8173bd94>] snd_usb_autosuspend+0x14/0x20
[<ffffffff817461bc>] snd_usb_pcm_close.isra.14+0x5c/0x90
[<ffffffff8174621f>] snd_usb_playback_close+0xf/0x20
[<ffffffff816ef58a>] snd_pcm_release_substream.part.36+0x3a/0x90
[<ffffffff816ef6b3>] snd_pcm_release+0xa3/0xb0
[<ffffffff816debb0>] snd_disconnect_release+0xd0/0xe0
[<ffffffff8114d417>] __fput+0x97/0x1d0
[<ffffffff8114d589>] ____fput+0x9/0x10
[<ffffffff8109e452>] task_work_run+0x72/0x90
[<ffffffff81088510>] do_exit+0x280/0xa80
[<ffffffff8108996a>] do_group_exit+0x3a/0xa0
[<ffffffff8109261f>] get_signal+0x1df/0x540
[<ffffffff81040903>] do_signal+0x23/0x620
[<ffffffff8114c128>] ? do_readv_writev+0x128/0x200
[<ffffffff810012e1>] prepare_exit_to_usermode+0x91/0xd0
[<ffffffff810013ba>] syscall_return_slowpath+0x9a/0x120
[<ffffffff817587cd>] ? __sys_recvmsg+0x5d/0x70
[<ffffffff810d2765>] ? ktime_get_ts64+0x45/0xe0
[<ffffffff8115dea0>] ? SyS_poll+0x60/0xf0
[<ffffffff818d2327>] int_ret_from_sys_call+0x25/0x8f
We have already a check of disconnection in snd_usb_autoresume(), but
the check is missing its counterpart. The fix is just to put the same
check in snd_usb_autosuspend(), too.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109431
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a4eae3a506ea4a7d4474cd74e20b423fa8053d91 upstream.
This patch adds native DSD support for the Oppo HA-1. It uses a XMOS chipset
but they use their own vendor ID.
Signed-off-by: Jurgen Kramer <gtmkramer@xs4all.nl>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Avoid getting sample rate on AudioQuest DragonFly as it is unsupported
and causes noisy "cannot get freq at ep 0x1" messages when playback
starts.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
AudioQuest DragonFly DAC reports a volume control range of 0..50
(0x0000..0x0032) which in USB Audio means a range of 0 .. 0.2dB, which
is obviously incorrect and would cause software using the dB information
in e.g. volume sliders to have a massive volume difference in 100..102%
range.
Commit 2d1cb7f658fb ("ALSA: usb-audio: add dB range mapping for some
devices") added a dB range mapping for it with range 0..50 dB.
However, the actual volume mapping seems to be neither linear volume nor
linear dB scale, but instead quite close to the cubic mapping e.g.
alsamixer uses, with a range of approx. -53...0 dB.
Replace the previous quirk with a custom dB mapping based on some basic
output measurements, using a 10-item range TLV (which will still fit in
alsa-lib MAX_TLV_RANGE_SIZE).
Tested on AudioQuest DragonFly HW v1.2. The quirk is only applied if the
range is 0..50, so if this gets fixed/changed in later HW revisions it
will no longer be applied.
v2: incorporated Takashi Iwai's suggestion for the quirk application
method
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
One of the many faults of the QinHeng CH345 USB MIDI interface chip is
that it does not handle received SysEx messages correctly -- every second
event packet has a wrong code index number, which is the one from the last
seen message, instead of 4. For example, the two messages "FE F0 01 02 03
04 05 06 07 08 09 0A 0B 0C 0D 0E F7" result in the following event
packets:
correct: CH345:
0F FE 00 00 0F FE 00 00
04 F0 01 02 04 F0 01 02
04 03 04 05 0F 03 04 05
04 06 07 08 04 06 07 08
04 09 0A 0B 0F 09 0A 0B
04 0C 0D 0E 04 0C 0D 0E
05 F7 00 00 05 F7 00 00
A class-compliant driver must interpret an event packet with CIN 15 as
having a single data byte, so the other two bytes would be ignored. The
message received by the host would then be missing two bytes out of six;
in this example, "F0 01 02 03 06 07 08 09 0C 0D 0E F7".
These corrupted SysEx event packages contain only data bytes, while the
CH345 uses event packets with a correct CIN value only for messages with
a status byte, so it is possible to distinguish between these two cases by
checking for the presence of this status byte.
(Other bugs in the CH345's input handling, such as the corruption resulting
from running status, cannot be worked around.)
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Cc: stable@vger.kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The CH345 USB MIDI chip has two output ports. However, they are
multiplexed through one pin, and the number of ports cannot be reduced
even for hardware that implements only one connector, so for those
devices, data sent to either port ends up on the same hardware output.
This becomes a problem when both ports are used at the same time, as
longer MIDI commands (such as SysEx messages) are likely to be
interrupted by messages from the other port, and thus to get lost.
It would not be possible for the driver to detect how many ports the
device actually has, except that in practice, _all_ devices built with
the CH345 have only one port. So we can just ignore the device's
descriptors, and hardcode one output port.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Cc: stable@vger.kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This patch adds native DSD support for the Aune X1S 32BIT/384 DSD DAC
Signed-off-by: Jurgen Kramer <gtmkramer@xs4all.nl>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The device has no mixer (and identifies itself as such), so just skip
the mixer definition.
Signed-off-by: Ricard Wanderlof <ricardw@axis.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
For the Zoom R16/24 (tx_length_quirk set), when calculating the maximum
sample frequency, consideration must be made for the fact that four bytes
of the packet contain a length descriptor and consequently must not be
counted as part of the audio data.
This is corroborated by the wMaxPacketSize for this device, which is 108
bytes according for the USB playback endpoint descriptor. The frame size
is 8 bytes (2 channels of 4 bytes each), and the 108 bytes thus work out
as 13 * 8 + 4, i.e. corresponding to 13 frames plus the additional 4 byte
length descriptor.
Signed-off-by: Ricard Wanderlof <ricardw@axis.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The Zoom R16/24 have a nonstandard playback format where each isochronous
packet contains a length descriptor in the first four bytes. (Curiously,
capture data does not contain this and requires no quirk.)
The quirk involves adding the extra length descriptor whenever outgoing
isochronous packets are generated, both in pcm.c (outgoing audio) and
endpoint.c (silent data).
In order to make the quirk as unintrusive as possible, for
pcm.c:prepare_playback_urb(), the isochronous packet descriptors are
initially set up in the same way no matter if the quirk is enabled or not.
Once it is time to actually copy the data into the outgoing packet buffer
(together with the added length descriptors) the isochronous descriptors
are adjusted in order take the increased payload length into account.
For endpoint.c:prepare_silent_urb() it makes more sense to modify the
actual function, partly because the function is less complex to start with
and partly because it is not as time-critical as prepare_playback_urb()
(whose bulk is run with interrupts disabled), so the (minute) additional
time spent in the non-quirk case is motivated by the simplicity of having
a single function for all cases.
The quirk is controlled by the new tx_length_quirk member in struct
snd_usb_substream and struct snd_usb_audio, which is conveyed to pcm.c
and endpoint.c from quirks.c in a similar manner to the txfr_quirk member
in the same structs.
In contrast to txfr_quirk however, the quirk is enabled directly in
quirks.c:create_standard_audio_quirk() by checking the USB ID in that
function. Another option would be to introduce a new
QUIRK_AUDIO_ZOOM_INTERFACE or somesuch, which would have made the quirk
very plain to see in the quirk table, but it was felt that the additional
code needed to implement it this way would just make the implementation
more complex with no real gain.
Tested with a Zoom R16, both by doing capture and playback separately
using arecord and aplay (8 channel capture and 2 channel playback,
respectively), as well as capture and playback together using Ardour, as
well as Audacity and Qtractor together with jackd.
The R24 is reportedly compatible with the R16 when used as an audio
interface. Both devices share the same USB ID and have the same number of
inputs (8) and outputs (2). Therefore "R16/24" is mentioned throughout the
patch.
Regression tested using an Edirol UA-5 in both class compliant (16-bit)
and "advanced" (24 bit, forces the use of quirks) modes.
Signed-off-by: Ricard Wanderlof <ricardw@axis.com>
Tested-by: Panu Matilainen <pmatilai@laiskiainen.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Preparation for adding Zoom R16/24 quirk.
No functional change.
Signed-off-by: Ricard Wanderlof <ricardw@axis.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Refactoring in preparation for adding Zoom R16/24 quirk.
No functional change.
Signed-off-by: Ricard Wanderlof <ricardw@axis.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Refactoring in preparation for adding Zoom R16/24 quirk.
No functional change.
Signed-off-by: Ricard Wanderlof <ricardw@axis.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Refactoring in preparation for adding Zoom R16/24 quirk.
No functional change.
Signed-off-by: Ricard Wanderlof <ricardw@axis.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The Nocturn needs the MIDI_RAW_BYTES quirk, like other Novation devices.
Tested that the Nocturn shows up in aconnect, and that it can be used
as a control surface (using the xtor synthesizer patch editor).
Signed-off-by: Ricard Wanderlof <ricardw@axis.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Rounding must take place before multiplication with the frame size, since
each packet contains a whole number of frames.
We must also properly consider the data interval, as a larger data
interval will result in larger packets, which, depending on the sampling
frequency, can result in packet sizes that are less than integral
multiples of the packet size for a lower data interval.
Detailed explanation and rationale:
The code before this commit had the following expression on line 613 to
calculate the maximum isochronous packet size:
maxsize = ((ep->freqmax + 0xffff) * (frame_bits >> 3))
>> (16 - ep->datainterval);
Here, ep->freqmax is the maximum assumed sample frequency, calculated from the
nominal sample frequency plus 25%. It is ultimately derived from ep->freqn,
which is in the units of frames per packet, from get_usb_full_speed_rate()
or usb_high_speed_rate(), as applicable, in Q16.16 format.
The expression essentially adds the Q16.16 equivalent of 0.999... (i.e.
the largest number less than one) to the sample rate, in order to get a
rate whose integer part is rounded up from the fractional value. The
multiplication with (frame_bits >> 3) yields the number of bytes in a
packet, and the (16 >> ep->datainterval) then converts it from Q16.16 back
to an integer, taking into consideration the bDataInterval field of the
endpoint descriptor (which describes how often isochronous packets are
transmitted relative to the (micro)frame rate (125us or 1ms, for USB high
speed and full speed, respectively)). For this discussion we will initially
assume a bDataInterval of 0, so the second line of the expression just
converts the Q16.16 value to an integer.
In order to illustrate the problem, we will set frame_bits 64, which
corresponds to a frame size of 8 bytes.
The problem here is twofold. First, the rounding operation consists
of the addition of 0x0.ffff and subsequent conversion to integer, but as the
expression stands, the conversion to integer is done after multiplication
with the frame size, rather than before. This results in the resulting
maxsize becoming too large.
Let's take an example. We have a sample rate of 96 kHz, so our ep->freqn is
0xc0000 (see usb_high_speed_rate()). Add 25% (line 612) and we get 0xf0000.
The calculated maxsize is then ((0xf0000 + 0x0ffff) * 8) >> 16 = 127 .
However, if we do the number of bytes calculation in a less obscure way it's
more apparent what the true corresponding packet size is: we get
ceil(96000 * 1.25 / 8000) * 8 = 120, where 1.25 is the 25% from line 612,
and the 8000 is the number of isochronous packets per second on a high
speed USB connection (125 us microframe interval).
This is fixed by performing the complete rounding operation prior to
multiplication with the frame rate.
The second problem is that when considering the ep->datainterval, this
must be done before rounding, in order to take the advantage of the fact
that if the number of bytes per packet is not an integer, the resulting
rounded-up integer is not necessarily a factor of two when the data
interval is increased by the same factor.
For instance, assuming a freqency of 41 kHz, the resulting
bytes-per-packet value for USB high speed is 41 kHz / 8000 = 5.125, or
0x52000 in Q16.16 format. With a data interval of 1 (ep->datainterval = 0),
this means that 6 frames per packet are needed, whereas with a data
interval of 2 we need 10.25, i.e. 11 frames needed.
Rephrasing the maxsize expression to:
maxsize = (((ep->freqmax << ep->datainterval) + 0xffff) >> 16) *
(frame_bits >> 3);
for the above 96 kHz example we instead get
((0xf0000 + 0xffff) >> 16) * 8 = 120 which is the correct value.
We can also do the calculation with a non-integer sample rate which is when
rounding comes into effect: say we have 44.1 kHz (resulting ep->freqn =
0x58333, and resulting ep->freqmax 0x58333 * 1.25 = 0x6e3ff (rounded down)):
Original maxsize = ((0x6e3ff + 0xffff) * 8) << 16 = 63 (63.124.. rounded down)
True maxsize = ceil(44100 * 1.25 / 8000) * 8 = 7 * 8 = 56
New maxsize = ((0x6e3ff + 0xffff) >> 16) * 8 = 7 * 8 = 56
This is also corroborated by the wMaxPacketSize check on line 616. Assume
that wMaxPacketSize = 104, with ep->maxpacksize then having the same value.
As 104 < 127, we get maxsize = 104. ep->freqmax is then recalculated to
(104 / 8) << 16 = 0xd0000 . Putting that rate into the original maxsize
calculation yields a maxsize of ((0xd0000 + 0xffff) * 8) >> 16 = 111
(with decimals 111.99988). Clearly, we should get back the 104 here,
which we would with the new expression: ((0xd0000 + 0xffff) >> 16) * 8 = 104 .
(The error has not been a problem because it only results in maxsize being
a bit too big which just wastes a couple of bytes, either as a result of
the first maxsize calculation, or because the resulting calculation will
hit the wMaxPacketSize value before the packet is too big, resulting in
fixing the size to wMaxPacketSize even though the packet is actually not
too long.)
Tested with an Edirol UA-5 both at 44.1 kHz and 96 kHz.
Signed-off-by: Ricard Wanderlof <ricardw@axis.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
on newer Roland devices
This patch enables interrupt transfer mode for MIDI ports on newer
Boss/Roland devices such as the GT-100/001 which support interrupt
transfer on both IN and OUT MIDI endpoints. Previously this wasn't being
enabled for these devices as the code was specifically looking for the
scenario where the IN endpoint supported interrupt transfer and the OUT
endpoint was bulk transfer. Newer devices support interrupt transfer for
both endpoints.
This has been tested on Boss devices GT-001, BR-80 and JS-8 and Roland
VS-20.
It would benefit from some regresison testing with other devices if
possible.
Signed-off-by: Keith A. Milner <maillist@superlative.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
We want to verify that "value" is either zero or one, so we test if it
is greater than one. Unfortunately, this is a signed int so it could
also be negative. I think this is harmless but it introduces a static
checker warning. Let's make "value" unsigned.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
