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