Re: [alsa-devel] Jack sensing in snd_usb_audio ?

2016-10-28 Thread Bastien Nocera 
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 ?

2016-10-18 Thread Takashi Iwai 
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 ?

2016-10-18 Thread Felipe Ferreri Tonello 
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 ?

2016-10-18 Thread Takashi Iwai 
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 ?

2016-10-12 Thread Bastien Nocera 
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 Interface

Re: [alsa-devel] Jack sensing in snd_usb_audio ?

2016-10-12 Thread Clemens Ladisch 
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 ?

2016-10-12 Thread Bastien Nocera 
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: [alsa-devel] Jack sensing in snd_usb_audio ?

2016-10-12 Thread Clemens Ladisch 
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