[alsa-devel] Jack sensing in snd_usb_audio ?
Hey,
I recently bought some cheap USB soundcards for a computer that doesn't have any audio output other than through the HDMI output, and the screen I'm attaching doesn't have an audio output.
So I'm looking to plug in 2 of those USB soundcards, and switch between them depending on whether I'm using headphones, or want to use the standalone speaker.
Obviously, it would be so much nicer if I didn't have to switch between the outputs by hand, and ignored the "headphones" sound card when not plugged in.
My questions are: - does the USB audio driver support jack sensing? - is this something standard that's just not implemented yet? In which case, I'd be up for at least trying, given specs. - or is it something that depends on the device, and in which case, how would I find out?
Some details about the device itself below.
Cheers
/proc/asound/cards: 4 [Device ]: USB-Audio - USB Audio Device GeneralPlus USB Audio Device at usb-0000:00:14.0-9, full speed
$ amixer -c 4 Simple mixer control 'Speaker',0 Capabilities: pvolume pswitch pswitch-joined Playback channels: Front Left - Front Right Limits: Playback 0 - 30 Mono: Front Left: Playback 16 [53%] [-21.00dB] [on] Front Right: Playback 16 [53%] [-21.00dB] [on] Simple mixer control 'Mic',0 Capabilities: pvolume pvolume-joined cvolume cvolume-joined pswitch pswitch-joined cswitch cswitch-joined Playback channels: Mono Capture channels: Mono Limits: Playback 0 - 14 Capture 0 - 30 Mono: Playback 1 [7%] [-10.50dB] [off] Capture 26 [87%] [27.00dB] [on] Simple mixer control 'Auto Gain Control',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [off]
Hi Bastien,
On 12/10/16 07:10, Bastien Nocera wrote:
Hey,
I recently bought some cheap USB soundcards for a computer that doesn't have any audio output other than through the HDMI output, and the screen I'm attaching doesn't have an audio output.
So I'm looking to plug in 2 of those USB soundcards, and switch between them depending on whether I'm using headphones, or want to use the standalone speaker.
Obviously, it would be so much nicer if I didn't have to switch between the outputs by hand, and ignored the "headphones" sound card when not plugged in.
My questions are:
- does the USB audio driver support jack sensing?
- is this something standard that's just not implemented yet? In which
case, I'd be up for at least trying, given specs.
- or is it something that depends on the device, and in which case, how
would I find out?
What you need is PulseAudio server instead. PulseAudio supports this via kcontrol for quite some time.
Jack is supposed to be a low-latency audio server for audio applications, not for normal desktop usage.
Some details about the device itself below.
Cheers
/proc/asound/cards: 4 [Device ]: USB-Audio - USB Audio Device GeneralPlus USB Audio Device at usb-0000:00:14.0-9, full speed
$ amixer -c 4 Simple mixer control 'Speaker',0 Capabilities: pvolume pswitch pswitch-joined Playback channels: Front Left - Front Right Limits: Playback 0 - 30 Mono: Front Left: Playback 16 [53%] [-21.00dB] [on] Front Right: Playback 16 [53%] [-21.00dB] [on] Simple mixer control 'Mic',0 Capabilities: pvolume pvolume-joined cvolume cvolume-joined pswitch pswitch-joined cswitch cswitch-joined Playback channels: Mono Capture channels: Mono Limits: Playback 0 - 14 Capture 0 - 30 Mono: Playback 1 [7%] [-10.50dB] [off] Capture 26 [87%] [27.00dB] [on] Simple mixer control 'Auto Gain Control',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [off] -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2016-10-12 at 11:14 +0200, Felipe Ferreri Tonello wrote:
<snip>
What you need is PulseAudio server instead. PulseAudio supports this via kcontrol for quite some time.
Jack is supposed to be a low-latency audio server for audio applications, not for normal desktop usage.
I'm not talking about jackd but about jack sensing.
On Oct 12 2016 14:10, Bastien Nocera wrote:
My questions are:
- does the USB audio driver support jack sensing?
- is this something standard that's just not implemented yet? In which
case, I'd be up for at least trying, given specs.
- or is it something that depends on the device, and in which case, how
would I find out?
In ALSA usb-related codes, there's no functions calls for snd_jack_*(), thus none of ALSA drivers for USB support Jack sense feature of ALSA control interface.
The requirement of Jack sense feature is whether hardwares support it. For example, some hardware codecs such as HDA codecs generates signals when plugs are insert to jacks connected to the codecs. Corresponding ALSA drivers catch the signals, then tell it to user land.
If your hardware performs like it, you have a probability to add support for jack sense feature to ALSA drivers for USB. But I don't know exactly that USB related specifications such as USB Audio Device Class 1.0/2.0/3.0 supports the feature.
Regards
Takashi Sakamoto
On Wed, 2016-10-12 at 19:36 +0900, Takashi Sakamoto wrote:
On Oct 12 2016 14:10, Bastien Nocera wrote:
My questions are:
- does the USB audio driver support jack sensing?
- is this something standard that's just not implemented yet? In
which case, I'd be up for at least trying, given specs.
- or is it something that depends on the device, and in which case,
how would I find out?
In ALSA usb-related codes, there's no functions calls for snd_jack_*(), thus none of ALSA drivers for USB support Jack sense feature of ALSA control interface.
The requirement of Jack sense feature is whether hardwares support it. For example, some hardware codecs such as HDA codecs generates signals when plugs are insert to jacks connected to the codecs. Corresponding ALSA drivers catch the signals, then tell it to user land.
If your hardware performs like it, you have a probability to add support for jack sense feature to ALSA drivers for USB. But I don't know exactly that USB related specifications such as USB Audio Device Class 1.0/2.0/3.0 supports the feature.
Looks like whether or not jack sensing works depends on the device itself, but there is a mechanism to propagate the change in setup in the USB Audio 2.0 spec, in the "Interrupts" section: " A change of state in the audio function is most often caused by a certain event that takes place. An event can either be user-initiated or device-initiated. User-initiated jack insertion or removal is a typical example of a user-initiated event. "
I guess I should probably test in another operating system to check whether the hardware I have supports this to start with, and go from there.
Cheers
Bastien Nocera wrote:
Looks like whether or not jack sensing works depends on the device itself, but there is a mechanism to propagate the change in setup in the USB Audio 2.0 spec
Some recent Windows 10 beta added partial support for USB Audio 2.0. Earlier Windowses implement only USB Audio 1.0, which does not mention jacks.
" A change of state in the audio function is most often caused by a certain event that takes place. An event can either be user-initiated or device-initiated. User-initiated jack insertion or removal is a typical example of a user-initiated event. "
There are not many USB Audio 2.0 devices, and I'm not aware of any that actually implements this.
Regards, Clemens
On Wed, 2016-10-12 at 14:43 +0200, Clemens Ladisch wrote:
Bastien Nocera wrote:
Looks like whether or not jack sensing works depends on the device itself, but there is a mechanism to propagate the change in setup in the USB Audio 2.0 spec
Some recent Windows 10 beta added partial support for USB Audio 2.0. Earlier Windowses implement only USB Audio 1.0, which does not mention jacks.
" A change of state in the audio function is most often caused by a certain event that takes place. An event can either be user- initiated or device-initiated. User-initiated jack insertion or removal is a typical example of a user-initiated event. "
There are not many USB Audio 2.0 devices, and I'm not aware of any that actually implements this.
I guess I would see whether there are events if I captured the USB traffic even without special handling/turning on a feature in the drivers, right?
Bastien Nocera wrote:
On Wed, 2016-10-12 at 14:43 +0200, Clemens Ladisch wrote:
Bastien Nocera wrote:
" A change of state in the audio function is most often caused by a certain event that takes place. An event can either be user- initiated or device-initiated. User-initiated jack insertion or removal is a typical example of a user-initiated event. "
There are not many USB Audio 2.0 devices, and I'm not aware of any that actually implements this.
I guess I would see whether there are events if I captured the USB traffic even without special handling/turning on a feature in the drivers, right?
Most devices do not even have the status endpoint (see "lsusb -v"). To check what events arrive, you can add logging to the snd_usb_mixer_interrupt() function.
Regards, Clemens
On Wed, 2016-10-12 at 18:06 +0200, Clemens Ladisch wrote:
Bastien Nocera wrote:
On Wed, 2016-10-12 at 14:43 +0200, Clemens Ladisch wrote:
Bastien Nocera wrote:
" A change of state in the audio function is most often caused by a certain event that takes place. An event can either be user- initiated or device-initiated. User-initiated jack insertion or removal is a typical example of a user-initiated event. "
There are not many USB Audio 2.0 devices, and I'm not aware of any that actually implements this.
I guess I would see whether there are events if I captured the USB traffic even without special handling/turning on a feature in the drivers, right?
Most devices do not even have the status endpoint (see "lsusb -v"). To check what events arrive, you can add logging to the snd_usb_mixer_interrupt() function.
I'm guessing it doesn't support it then (see attached log)
I also checked the input device output when plugging in something, with evtest, and no feedback either.
On Wed, 12 Oct 2016 18:15:04 +0200, Bastien Nocera wrote:
On Wed, 2016-10-12 at 18:06 +0200, Clemens Ladisch wrote:
Bastien Nocera wrote:
On Wed, 2016-10-12 at 14:43 +0200, Clemens Ladisch wrote:
Bastien Nocera wrote:
" A change of state in the audio function is most often caused by a certain event that takes place. An event can either be user- initiated or device-initiated. User-initiated jack insertion or removal is a typical example of a user-initiated event. "
There are not many USB Audio 2.0 devices, and I'm not aware of any that actually implements this.
I guess I would see whether there are events if I captured the USB traffic even without special handling/turning on a feature in the drivers, right?
Most devices do not even have the status endpoint (see "lsusb -v"). To check what events arrive, you can add logging to the snd_usb_mixer_interrupt() function.
I'm guessing it doesn't support it then (see attached log)
So this looks like a HID, not from the audio device class. It's an oft-seen implementation.
I also checked the input device output when plugging in something, with evtest, and no feedback either.
Then at first you need to hack a HID driver to support this device. It'll create an input device, and then we'll need to find some way to couple the given input device and the audio device. We can parse the sysfs device path to figure out, but I'm not sure what's the best way to tell it to applications.
Takashi
Bus 003 Device 035: ID 1b3f:2008 Generalplus Technology Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x1b3f Generalplus Technology Inc. idProduct 0x2008 bcdDevice 1.00 iManufacturer 1 GeneralPlus iProduct 2 USB Audio Device iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 253 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 0 AudioControl Interface Descriptor: bLength 10 bDescriptorType 36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 100 bInCollection 2 baInterfaceNr( 0) 1 baInterfaceNr( 1) 2 AudioControl Interface Descriptor: bLength 12 bDescriptorType 36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength 12 bDescriptorType 36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 4 wTerminalType 0x0201 Microphone bAssocTerminal 0 bNrChannels 1 wChannelConfig 0x0001 Left Front (L) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 3 wTerminalType 0x0301 Speaker bAssocTerminal 0 bSourceID 6 iTerminal 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 2 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bSourceID 9 iTerminal 0 AudioControl Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 5 (SELECTOR_UNIT) bUnitID 9 bNrInPins 1 baSource( 0) 5 iSelector 0 AudioControl Interface Descriptor: bLength 10 bDescriptorType 36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 6 bSourceID 8 bControlSize 1 bmaControls( 0) 0x01 Mute Control bmaControls( 1) 0x02 Volume Control bmaControls( 2) 0x02 Volume Control iFeature 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 5 bSourceID 4 bControlSize 1 bmaControls( 0) 0x43 Mute Control Volume Control Automatic Gain Control bmaControls( 1) 0x00 iFeature 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 7 bSourceID 4 bControlSize 1 bmaControls( 0) 0x03 Mute Control Volume Control bmaControls( 1) 0x00 iFeature 0 AudioControl Interface Descriptor: bLength 13 bDescriptorType 36 bDescriptorSubtype 4 (MIXER_UNIT) bUnitID 8 bNrInPins 2 baSourceID( 0) 1 baSourceID( 1) 7 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 bmControls 0x00 iMixer 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 1 bDelay 1 frames wFormatTag 1 PCM AudioStreaming Interface Descriptor: bLength 14 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 2 bSubframeSize 2 bBitResolution 16 bSamFreqType 2 Discrete tSamFreq[ 0] 44100 tSamFreq[ 1] 48000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x00c0 1x 192 bytes bInterval 1 bRefresh 0 bSynchAddress 0 AudioControl Endpoint Descriptor: bLength 7 bDescriptorType 37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 0 Undefined wLockDelay 0 Undefined Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 2 bDelay 1 frames wFormatTag 1 PCM AudioStreaming Interface Descriptor: bLength 14 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 1 bSubframeSize 2 bBitResolution 16 bSamFreqType 2 Discrete tSamFreq[ 0] 44100 tSamFreq[ 1] 48000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0064 1x 100 bytes bInterval 1 bRefresh 0 bSynchAddress 0 AudioControl Endpoint Descriptor: bLength 7 bDescriptorType 37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 0 Undefined wLockDelay 0 Undefined Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 2.01 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 41 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 32 Device Status: 0x0000 (Bus Powered) _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Hi Takashi
On 18/10/16 13:07, Takashi Iwai wrote:
On Wed, 12 Oct 2016 18:15:04 +0200, Bastien Nocera wrote:
On Wed, 2016-10-12 at 18:06 +0200, Clemens Ladisch wrote:
Bastien Nocera wrote:
On Wed, 2016-10-12 at 14:43 +0200, Clemens Ladisch wrote:
Bastien Nocera wrote:
" A change of state in the audio function is most often caused by a certain event that takes place. An event can either be user- initiated or device-initiated. User-initiated jack insertion or removal is a typical example of a user-initiated event. "
There are not many USB Audio 2.0 devices, and I'm not aware of any that actually implements this.
I guess I would see whether there are events if I captured the USB traffic even without special handling/turning on a feature in the drivers, right?
Most devices do not even have the status endpoint (see "lsusb -v"). To check what events arrive, you can add logging to the snd_usb_mixer_interrupt() function.
I'm guessing it doesn't support it then (see attached log)
So this looks like a HID, not from the audio device class. It's an oft-seen implementation.
I also checked the input device output when plugging in something, with evtest, and no feedback either.
Then at first you need to hack a HID driver to support this device. It'll create an input device, and then we'll need to find some way to couple the given input device and the audio device. We can parse the sysfs device path to figure out, but I'm not sure what's the best way to tell it to applications.
Why not use similar API as a normal ALSA card? This will enable jack detection by default in applications using kcontrol interface.
On Tue, 18 Oct 2016 15:33:42 +0200, Felipe Ferreri Tonello wrote:
Hi Takashi
On 18/10/16 13:07, Takashi Iwai wrote:
On Wed, 12 Oct 2016 18:15:04 +0200, Bastien Nocera wrote:
On Wed, 2016-10-12 at 18:06 +0200, Clemens Ladisch wrote:
Bastien Nocera wrote:
On Wed, 2016-10-12 at 14:43 +0200, Clemens Ladisch wrote:
Bastien Nocera wrote: > " > A change of state in the audio function is most often caused by > a > certain event that takes place. An event can either be user- > initiated > or device-initiated. User-initiated jack insertion or removal > is a > typical example of a user-initiated event. > "
There are not many USB Audio 2.0 devices, and I'm not aware of any that actually implements this.
I guess I would see whether there are events if I captured the USB traffic even without special handling/turning on a feature in the drivers, right?
Most devices do not even have the status endpoint (see "lsusb -v"). To check what events arrive, you can add logging to the snd_usb_mixer_interrupt() function.
I'm guessing it doesn't support it then (see attached log)
So this looks like a HID, not from the audio device class. It's an oft-seen implementation.
I also checked the input device output when plugging in something, with evtest, and no feedback either.
Then at first you need to hack a HID driver to support this device. It'll create an input device, and then we'll need to find some way to couple the given input device and the audio device. We can parse the sysfs device path to figure out, but I'm not sure what's the best way to tell it to applications.
Why not use similar API as a normal ALSA card? This will enable jack detection by default in applications using kcontrol interface.
Are you suggesting to create another sound card object by a HID driver? This would be even less useful. Then you'll have two individual sound cards in the end that have no connection between them.
Takashi
On Tue, 2016-10-18 at 14:07 +0200, Takashi Iwai wrote:
On Wed, 12 Oct 2016 18:15:04 +0200, Bastien Nocera wrote:
On Wed, 2016-10-12 at 18:06 +0200, Clemens Ladisch wrote:
Bastien Nocera wrote:
On Wed, 2016-10-12 at 14:43 +0200, Clemens Ladisch wrote:
Bastien Nocera wrote:
" A change of state in the audio function is most often caused by a certain event that takes place. An event can either be user- initiated or device-initiated. User-initiated jack insertion or removal is a typical example of a user-initiated event. "
There are not many USB Audio 2.0 devices, and I'm not aware of any that actually implements this.
I guess I would see whether there are events if I captured the USB traffic even without special handling/turning on a feature in the drivers, right?
Most devices do not even have the status endpoint (see "lsusb -v"). To check what events arrive, you can add logging to the snd_usb_mixer_interrupt() function.
I'm guessing it doesn't support it then (see attached log)
So this looks like a HID, not from the audio device class. It's an oft-seen implementation.
I also checked the input device output when plugging in something, with evtest, and no feedback either.
Then at first you need to hack a HID driver to support this device. It'll create an input device, and then we'll need to find some way to couple the given input device and the audio device. We can parse the sysfs device path to figure out, but I'm not sure what's the best way to tell it to applications.
You misunderstood. There's no input events on the input device, there's also no hidraw events (hid-recorder didn't see any events) and using usbmon also got me no USB events whatsoever when plugging or unplugging a jack on either the headphones or the microphone jack.
So there's really nothing that we can do for this hardware. Shame, it would have been pretty useful to me :)
Thanks all for your help
Hi Bastien,
On 12/10/16 12:58, Bastien Nocera wrote:
On Wed, 2016-10-12 at 19:36 +0900, Takashi Sakamoto wrote:
On Oct 12 2016 14:10, Bastien Nocera wrote:
My questions are:
- does the USB audio driver support jack sensing?
- is this something standard that's just not implemented yet? In
which case, I'd be up for at least trying, given specs.
- or is it something that depends on the device, and in which case,
how would I find out?
In ALSA usb-related codes, there's no functions calls for snd_jack_*(), thus none of ALSA drivers for USB support Jack sense feature of ALSA control interface.
The requirement of Jack sense feature is whether hardwares support it. For example, some hardware codecs such as HDA codecs generates signals when plugs are insert to jacks connected to the codecs. Corresponding ALSA drivers catch the signals, then tell it to user land.
If your hardware performs like it, you have a probability to add support for jack sense feature to ALSA drivers for USB. But I don't know exactly that USB related specifications such as USB Audio Device Class 1.0/2.0/3.0 supports the feature.
Looks like whether or not jack sensing works depends on the device itself, but there is a mechanism to propagate the change in setup in the USB Audio 2.0 spec, in the "Interrupts" section: " A change of state in the audio function is most often caused by a certain event that takes place. An event can either be user-initiated or device-initiated. User-initiated jack insertion or removal is a typical example of a user-initiated event. "
snd_usb_audio doesn't support control interrupts yet.
It's a nice feature to work on.
participants (5)
-
Bastien Nocera -
Clemens Ladisch -
Felipe Ferreri Tonello -
Takashi Iwai -
Takashi Sakamoto