Re: [alsa-devel] Jack sensing in snd_usb_audio ?
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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] Jack sensing in snd_usb_audio ?
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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] Jack sensing in snd_usb_audio ?
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. -- Felipe 0x92698E6A.asc Description: application/pgp-keys
Re: [alsa-devel] Jack sensing in snd_usb_audio ?
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: > bLength18 > bDescriptorType 1 > bcdUSB 1.10 > bDeviceClass0 > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 8 > idVendor 0x1b3f Generalplus Technology Inc. > idProduct 0x2008 > bcdDevice1.00 > iManufacturer 1 GeneralPlus > iProduct2 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 > bInterfaceNumber0 > bAlternateSetting 0 > bNumEndpoints 0 > bInterfaceClass 1 Audio > bInterfaceSubClass 1 Control Device > bInterfaceProtocol 0 > iInterface 0 > AudioControl Interface Descriptor: > bLength10 > bDescriptorType36 > bDescriptorSubtype 1 (HEADER) > bcdADC 1.00 > wTotalLength 100 > bInCollection 2 > baInterfaceNr( 0) 1 > baInterfaceNr( 1) 2 > AudioControl Interface Descriptor: > bLength12 > bDescriptorType36 > 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: > bLength12 > bDescriptorType36 > 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 > bDescriptorType36 > bDescriptorSubtype 3 (OUTPUT_TERMINAL) > bTerminalID 3 > wTerminalType 0x0301 Speaker > bAssocTerminal 0 > bSourceID 6 > iTerminal 0 > AudioControl Interface Descriptor: > bLength 9 > bDescriptorType36 > bDescriptorSubtype 3 (OUTPUT_TERMINAL) > bTerminalID 2 > wTerminalType 0x0101 USB Streaming > bAssocTerminal 0 > bSourceID 9 > iTerminal 0 > AudioControl Interface Descriptor: > bLength 7 >
Re: [alsa-devel] Jack sensing in snd_usb_audio ?
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. Bus 003 Device 035: ID 1b3f:2008 Generalplus Technology Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x1b3f Generalplus Technology Inc. idProduct 0x2008 bcdDevice1.00 iManufacturer 1 GeneralPlus iProduct2 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 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 0 AudioControl Interface Descriptor: bLength10 bDescriptorType36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 100 bInCollection 2 baInterfaceNr( 0) 1 baInterfaceNr( 1) 2 AudioControl Interface Descriptor: bLength12 bDescriptorType36 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: bLength12 bDescriptorType36 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 bDescriptorType36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 3 wTerminalType 0x0301 Speaker bAssocTerminal 0 bSourceID 6 iTerminal 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 2 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bSourceID 9 iTerminal 0 AudioControl Interface Descriptor: bLength 7 bDescriptorType36 bDescriptorSubtype 5 (SELECTOR_UNIT) bUnitID 9 bNrInPins 1 baSource( 0)5 iSelector 0 AudioControl Interface Descriptor: bLength10 bDescriptorType36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 6 bSourceID 8 bControlSize1 bmaControls( 0) 0x01 Mute Control bmaControls( 1) 0x02 Volume Control bmaControls( 2) 0x02 Volume Control iFeature0 AudioControl
Re: [alsa-devel] Jack sensing in snd_usb_audio ?
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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] Jack sensing in snd_usb_audio ?
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? -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Jack sensing in snd_usb_audio ?
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. -- Felipe 0x92698E6A.asc Description: application/pgp-keys
Re: [alsa-devel] Jack sensing in snd_usb_audio ?
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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Jack sensing in snd_usb_audio ?
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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Jack sensing in snd_usb_audio ?
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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Jack sensing in snd_usb_audio ?
On Wed, 2016-10-12 at 11:14 +0200, Felipe Ferreri Tonello wrote: > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Jack sensing in snd_usb_audio ?
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-: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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Felipe 0x92698E6A.asc Description: application/pgp-keys
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-: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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
