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.


Attachment: 0x92698E6A.asc
Description: application/pgp-keys

Reply via email to