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
Attachment:
0x92698E6A.asc
Description: application/pgp-keys
