Hello, this is my first ever patch to Linux, hope this helps.

Since it's release, the M-Audio Venom never worked through USB
in Linux, drivers for Windows and Mac OS have been available
for ever, but due to it's short maintenance time, it never got
a Linux driver or any support for Linux users.

Some users across the years have posted about its MIDI usage
but all have pointed out that the USB port was useless for Linux.

So I found a fix for it, but the process went as follows:

The device upon connection without any fix showed the following
through dmesg:

[23824.463792] usb 2-3: New USB device found, idVendor=0763, 
	idProduct=2084, bcdDevice=11.44
[23824.463796] usb 2-3: New USB device strings: Mfr=2, 
	Product=3, SerialNumber=0
[23824.463797] usb 2-3: Product: Venom
[23824.463798] usb 2-3: Manufacturer: M-Audio
[23829.670004] usb 2-3: 1:1: cannot get freq at ep 0x2
[23850.150093] usb 2-3: 2:1: cannot set freq 44100 to ep 0x84
[23855.270162] usb 2-3: Quirk or no altset; falling back to 
	MIDI 1.0
[23901.350369] usb 2-3: 6:0: failed to get current value for 
	ch 0 (-110)
[23911.590383] usb 2-3: 6:0: cannot get min/max values for 
	control 2 (id 6)
[23911.590401] usb 2-3: Warning! Unlikely small volume range (=1), 
		linear volume or custom curve?
[23911.590407] usb 2-3: [6] FU [PCM Playback Volume] ch = 2, 
	val = 0/1/1
[23916.710413] usb 2-3: 5:0: failed to get current value for 
	ch 0 (-110)
[23947.430547] usb 2-3: 6:0: cannot get min/max values for 
	control 2 (id 6) 
	// This happened around 15 times until the next loop.
[24019.111127] usb 2-3: 2:1: usb_set_interface failed (-110) 
	// This started happenning every 5 seconds non stop until 
	// the connection was cut.

As the "get freq" and "set freq" pointed to a problem with the sample
rate, I applied a quirk fix with the following:

options snd-usb-audio quirk_flags=0763:2084:get_sample_rate|
	disable_autosuspend;

And that seemed to work for the sample problems and the
usb_set_interface:

[33121.858400] usb 2-3: new full-speed USB device number 15 
	using xhci_hcd
[33121.983604] usb 2-3: New USB device found, idVendor=0763, 
	idProduct=2084, bcdDevice=11.44
[33121.983608] usb 2-3: New USB device strings: Mfr=2, Product=3, 
	SerialNumber=0
[33121.983610] usb 2-3: Product: Venom
[33121.983611] usb 2-3: Manufacturer: M-Audio
[33121.987805] usb 2-3: Quirk or no altset; falling back to MIDI 1.0

But the device still didn't work in any test. It did show, though, in
various ALSA commands: 

aplay -l; arecord -l; amidi -l; aconnect -l
**** List of PLAYBACK Hardware Devices ****
card 2: Venom [Venom], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
**** List of CAPTURE Hardware Devices ****
card 2: Venom [Venom], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
Dir Device    Name
IO  hw:2,0,0  Venom Synth In
IO  hw:2,0,1  Venom MIDI In
client 24: 'Venom' [type=kernel,card=2]
    0 'Venom Synth Out '
    1 'Venom MIDI Out  '

So I decided to check if Windows was using any weird or propietary
functions in the handshake but it did not (I checked through USBPcap),
so then I made a quick script using pyusb to try and recreate it with no
driver in between, previously disabling the auto-probing, and it worked!

Sending the commands:

dev = usb.core.find(idVendor=0x0763, idProduct=0x2084)

dev.ctrl_transfer(0x80, 0x00, 0, 0, 2, timeout=3000)
dev.ctrl_transfer(0xA1, 0x81, 0x0100, 0x0500, 1, timeout=3000)
dev.ctrl_transfer(0x01, 0x0b, 1, 1, None, timeout=3000)
dev.write(0x0d, b'\x0c\xc0\x05\x00', timeout=3000)
dev.write(0x0d, b'\x09\x90\x3c\x64', timeout=3000)
dev.read(0x8e, 64, timeout=3000)

Not only could I hear the device, which up to this point it didn't emit
any sound when connected to Linux, I was also able to control it through
messages, changing presets and configs.

So the only remaining thing seemed to be the initializer, I programmed a
quick composite quirk to disable the mixer (or at least ignore it) so
that the device configured itself, and it worked outright, so I'm
sending this patch to make it work for anyone's computer.

Thanks for the attention.

Federico Valentín Andrade (2):
  ALSA: usb-audio: Skip reading sample rate on M-Audio Venom
  ALSA: usb-audio: Skip mixer creation on M-Audio Venom

 sound/usb/quirks-table.h | 22 ++++++++++++++++++++++
 sound/usb/quirks.c       |  2 ++
 2 files changed, 24 insertions(+)

-- 
2.55.0

I must have done this in automatic, sorry, as I was testing through
modprobe.d, I didn't check if the code was working correctly :P

Sending the quickfix, thanks.

Changes since v1:
- Patch 1: Fixed typo, QUIRK_FLAG_MIXER_GET_SAMPLE_RATE became
  QUIRK_FLAG_GET_SAMPLE_RATE (reported by Takashi Iwai)

Federico Valentín Andrade (2):
  ALSA: usb-audio: Skip reading sample rate on M-Audio Venom
  ALSA: usb-audio: Skip mixer creation on M-Audio Venom

 sound/usb/quirks-table.h | 22 ++++++++++++++++++++++
 sound/usb/quirks.c       |  2 ++
 2 files changed, 24 insertions(+)

-- 
2.55.0

Sorry, I had some trouble sending these mails through git and
misconfigured my email configs... Fixed it, hopefully that's all!

Sorry for the troubles.

Changes since v2:
- Remove duplicated Signed-off-by lines

Federico Valentín Andrade (2):
  ALSA: usb-audio: Skip reading sample rate on M-Audio Venom
  ALSA: usb-audio: Skip mixer creation on M-Audio Venom

 sound/usb/quirks-table.h | 22 ++++++++++++++++++++++
 sound/usb/quirks.c       |  2 ++
 2 files changed, 24 insertions(+)

-- 
2.55.0

The M-Audio Venom (0763:2084) is an USB Audio Class 1 compliant
synth with an integrated audio interface, it does not implement
GET_CUR on SAMPLING_FREQ_CONTROL, hanging up if requested on
endpoint 0.

The first class request issued by the driver after enumeration is
a GET_CUR on endpoint 0x02, freezing the device's USB microcontroller.
Timing out on every transfer afterwards with -ETIMEDOUT, such as
SET_INTERFACE, so neither the mixer nor any streaming interface is set up.

Analyzing a USBPcap capture of the Windows driver I found it never
requests the sampling frequency, as the synth exposes a single
discrete of 44100Hz on both streaming interfaces, thus asking for it
is unnecessary.

So I applied get_sample_rate to avoid this check, and
disable_autosuspend because the synth doesn't come back from being
suspended.

Signed-off-by: Federico Valentín Andrade <fandrade@frba.utn.edu.ar>
---
 sound/usb/quirks.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index f4e1eac639..64c802bef0 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -2334,6 +2334,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
 		   QUIRK_FLAG_MIXER_GET_CUR_BROKEN | QUIRK_FLAG_GENERIC_IMPLICIT_FB),
 	DEVICE_FLG(0x0763, 0x2081, /* M-Audio Fast Track Ultra */
 		   QUIRK_FLAG_MIXER_GET_CUR_BROKEN | QUIRK_FLAG_GENERIC_IMPLICIT_FB),
+	DEVICE_FLG(0x0763, 0x2084, /* M-Audio Venom */
+		   QUIRK_FLAG_GET_SAMPLE_RATE | QUIRK_FLAG_DISABLE_AUTOSUSPEND),
 	DEVICE_FLG(0x07fd, 0x000b, /* MOTU M Series 2nd hardware revision */
 		   QUIRK_FLAG_CTL_MSG_DELAY_1M),
 	DEVICE_FLG(0x08bb, 0x2702, /* LineX FM Transmitter */
-- 
2.55.0

On Mon, 24 Aug 2026 16:02:10 +0200,
Federico Valentín Andrade wrote:
> 
> The M-Audio Venom (0763:2084) is an USB Audio Class 1 compliant
> synth with an integrated audio interface, it does not implement
> GET_CUR on SAMPLING_FREQ_CONTROL, hanging up if requested on
> endpoint 0.
> 
> The first class request issued by the driver after enumeration is
> a GET_CUR on endpoint 0x02, freezing the device's USB microcontroller.
> Timing out on every transfer afterwards with -ETIMEDOUT, such as
> SET_INTERFACE, so neither the mixer nor any streaming interface is set up.
> 
> Analyzing a USBPcap capture of the Windows driver I found it never
> requests the sampling frequency, as the synth exposes a single
> discrete of 44100Hz on both streaming interfaces, thus asking for it
> is unnecessary.
> 
> So I applied get_sample_rate to avoid this check, and
> disable_autosuspend because the synth doesn't come back from being
> suspended.
> 
> Signed-off-by: Federico Valentín Andrade <fandrade@frba.utn.edu.ar>

Applied both patches now.  Thanks.


Takashi

The M-Audio Venom (0763:2084) does not answer any GET_CUR request
of its feature units, hanging up the USB microcontroller and
"responding" with timeouts. So the mixer building lasts around 47
seconds, and the device does not stream at all.

The same GET_CUR requests issued through libusb (with no kernel
driver bound) complete correctly and blazingly fast. So it seems
to only happen during the initial probe.

I defined an explicit composite quirk to bypass the mixer creation,
as it is not needed (the synth already comes with volume controls).

With both this and the device flag applied, the synth works
flawlessly.

Signed-off-by: Federico Valentín Andrade <fandrade@frba.utn.edu.ar>
---
 sound/usb/quirks-table.h | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h
index 0a3d39b838..dd02c6294e 100644
--- a/sound/usb/quirks-table.h
+++ b/sound/usb/quirks-table.h
@@ -1814,6 +1814,28 @@ YAMAHA_DEVICE(0x7010, "UB99"),
 		}
 	}
 },
+{
+	/*
+	 * M-Audio Venom
+	 *
+	 * The AudioControl interface times out on every GET_CUR request,
+	 * which adds around 47 seconds to the card registration and
+	 * freezes the device, blocking streaming.
+	 * Using an explicit composite quirk to skip the mixer entirely.
+	 */
+	USB_DEVICE_VENDOR_SPEC(0x0763, 0x2084),
+	QUIRK_DRIVER_INFO {
+		.vendor_name = "M-Audio",
+		.product_name = "Venom",
+		QUIRK_DATA_COMPOSITE {
+			{ QUIRK_DATA_IGNORE(0) },
+			{ QUIRK_DATA_STANDARD_AUDIO(1) },
+			{ QUIRK_DATA_STANDARD_AUDIO(2) },
+			{ QUIRK_DATA_STANDARD_MIDI(3) },
+			QUIRK_COMPOSITE_END
+		}
+	}
+},
 
 /* Casio devices */
 {
-- 
2.55.0