add Steinberg UR44 USB Audio Interface support to quirks-table
diff mbox

Message ID 1394388767-23658-1-git-send-email-cyrus@bobobeach.com
State Accepted
Headers show

Commit Message

Cyrus Harmon March 9, 2014, 6:12 p.m. UTC
Signed-off-by: Cyrus Harmon <cyrus@bobobeach.com>
---
 sound/usb/quirks-table.h | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

Comments

Takashi Iwai March 10, 2014, 9:42 a.m. UTC | #1
At Sun,  9 Mar 2014 11:12:47 -0700,
Cyrus Harmon wrote:
> 
> Signed-off-by: Cyrus Harmon <cyrus@bobobeach.com>

Could you give more words about the patch?
Why the patch is needed, and what the patch provides? (e.g. does it
support the all features of the device?)


thanks,

Takashi

> ---
>  sound/usb/quirks-table.h | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h
> index f652b10..987ca01 100644
> --- a/sound/usb/quirks-table.h
> +++ b/sound/usb/quirks-table.h
> @@ -436,6 +436,36 @@ YAMAHA_DEVICE(0x105d, NULL),
>  		}
>  	}
>  },
> +{
> +	USB_DEVICE(0x0499, 0x150e),
> +	.driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) {
> +		/* .vendor_name = "Yamaha", */
> +		/* .product_name = "Steinberg UR44", */
> +		.ifnum = QUIRK_ANY_INTERFACE,
> +		.type = QUIRK_COMPOSITE,
> +		.data = (const struct snd_usb_audio_quirk[]) {
> +			{
> +				.ifnum = 1,
> +				.type = QUIRK_AUDIO_STANDARD_INTERFACE
> +			},
> +			{
> +				.ifnum = 2,
> +				.type = QUIRK_AUDIO_STANDARD_INTERFACE
> +			},
> +			{
> +				.ifnum = 3,
> +				.type = QUIRK_MIDI_YAMAHA
> +			},
> +			{
> +				.ifnum = 4,
> +				.type = QUIRK_IGNORE_INTERFACE
> +			},
> +			{
> +				.ifnum = -1
> +			}
> +		}
> +	}
> +},
>  YAMAHA_DEVICE(0x2000, "DGP-7"),
>  YAMAHA_DEVICE(0x2001, "DGP-5"),
>  YAMAHA_DEVICE(0x2002, NULL),
> -- 
> 1.8.3.2
>
Clemens Ladisch March 10, 2014, 12:07 p.m. UTC | #2
Cyrus Harmon wrote:
> Signed-off-by: Cyrus Harmon <cyrus@bobobeach.com>
> ---
>  sound/usb/quirks-table.h | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)

What kernel version did you test this patch with?


Regards,
Clemens

>
> diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h
> index f652b10..987ca01 100644
> --- a/sound/usb/quirks-table.h
> +++ b/sound/usb/quirks-table.h
> @@ -436,6 +436,36 @@ YAMAHA_DEVICE(0x105d, NULL),
>  		}
>  	}
>  },
> +{
> +	USB_DEVICE(0x0499, 0x150e),
> +	.driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) {
> +		/* .vendor_name = "Yamaha", */
> +		/* .product_name = "Steinberg UR44", */
> +		.ifnum = QUIRK_ANY_INTERFACE,
> +		.type = QUIRK_COMPOSITE,
> +		.data = (const struct snd_usb_audio_quirk[]) {
> +			{
> +				.ifnum = 1,
> +				.type = QUIRK_AUDIO_STANDARD_INTERFACE
> +			},
> +			{
> +				.ifnum = 2,
> +				.type = QUIRK_AUDIO_STANDARD_INTERFACE
> +			},
> +			{
> +				.ifnum = 3,
> +				.type = QUIRK_MIDI_YAMAHA
> +			},
> +			{
> +				.ifnum = 4,
> +				.type = QUIRK_IGNORE_INTERFACE
> +			},
> +			{
> +				.ifnum = -1
> +			}
> +		}
> +	}
> +},
>  YAMAHA_DEVICE(0x2000, "DGP-7"),
>  YAMAHA_DEVICE(0x2001, "DGP-5"),
>  YAMAHA_DEVICE(0x2002, NULL),
>
Cyrus Harmon March 10, 2014, 3:26 p.m. UTC | #3
The attached patch provides support for the Steinberg UR44 USB Audio Interface. It’s nothing more than Clemens’ patch to support the UR22 (http://linuxaudio.org/mailarchive/lad/2013/2/23/197831), with the device ID modified for the UR44. The patch was tested with kernel versions 3.12.11 and 3.12.12 and I have primarily used it with a PREEMPT RT-patched 3.12.12-rt kernel. I would imagine there are additional features of this audio interface that aren’t supported by the patch, but basic recording and playback seems to work.

I should note that on one of the systems that I used to test the patch I was never able to achieve xrun-free JACK performance at -p256 -n3 as I would invariably see xruns roughly once every minute. But this is a new box (Intel haswell NUC) and it seems there are many possible sources of the unacceptable latency. The good news is that an older i3 box, the performance was much better. Still, at some point it would be nice to understand if the problem lies in 1) the device, 2) the ALSA drivers, 3) the USB drivers, 4) IRQ handling, 5) CPU-specific features (power saving modes, SMIs, etc…) or 6) somewhere else. In the meantime, the patch at least makes the kernel recognize and talk to the UR44.

Thanks in advance for any comments/suggestions on the patch.

Cyrus

On Mar 10, 2014, at 5:07 AM, Clemens Ladisch <clemens@ladisch.de> wrote:

> Cyrus Harmon wrote:
>> Signed-off-by: Cyrus Harmon <cyrus@bobobeach.com>
>> ---
>> sound/usb/quirks-table.h | 30 ++++++++++++++++++++++++++++++
>> 1 file changed, 30 insertions(+)
> 
> What kernel version did you test this patch with?
> 
> 
> Regards,
> Clemens
> 
>> 
>> diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h
>> index f652b10..987ca01 100644
>> --- a/sound/usb/quirks-table.h
>> +++ b/sound/usb/quirks-table.h
>> @@ -436,6 +436,36 @@ YAMAHA_DEVICE(0x105d, NULL),
>> 		}
>> 	}
>> },
>> +{
>> +	USB_DEVICE(0x0499, 0x150e),
>> +	.driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) {
>> +		/* .vendor_name = "Yamaha", */
>> +		/* .product_name = "Steinberg UR44", */
>> +		.ifnum = QUIRK_ANY_INTERFACE,
>> +		.type = QUIRK_COMPOSITE,
>> +		.data = (const struct snd_usb_audio_quirk[]) {
>> +			{
>> +				.ifnum = 1,
>> +				.type = QUIRK_AUDIO_STANDARD_INTERFACE
>> +			},
>> +			{
>> +				.ifnum = 2,
>> +				.type = QUIRK_AUDIO_STANDARD_INTERFACE
>> +			},
>> +			{
>> +				.ifnum = 3,
>> +				.type = QUIRK_MIDI_YAMAHA
>> +			},
>> +			{
>> +				.ifnum = 4,
>> +				.type = QUIRK_IGNORE_INTERFACE
>> +			},
>> +			{
>> +				.ifnum = -1
>> +			}
>> +		}
>> +	}
>> +},
>> YAMAHA_DEVICE(0x2000, "DGP-7"),
>> YAMAHA_DEVICE(0x2001, "DGP-5"),
>> YAMAHA_DEVICE(0x2002, NULL),
>> 
> 
>
Takashi Iwai March 10, 2014, 3:30 p.m. UTC | #4
At Mon, 10 Mar 2014 08:26:15 -0700,
Cyrus Harmon wrote:
> 
> 
> The attached patch provides support for the Steinberg UR44 USB Audio Interface. It’s nothing more than Clemens’ patch to support the UR22 (http://linuxaudio.org/mailarchive/lad/2013/2/23/197831), with the device ID modified for the UR44. The patch was tested with kernel versions 3.12.11 and 3.12.12 and I have primarily used it with a PREEMPT RT-patched 3.12.12-rt kernel. I would imagine there are additional features of this audio interface that aren’t supported by the patch, but basic recording and playback seems to work.
> 
> I should note that on one of the systems that I used to test the patch I was never able to achieve xrun-free JACK performance at -p256 -n3 as I would invariably see xruns roughly once every minute. But this is a new box (Intel haswell NUC) and it seems there are many possible sources of the unacceptable latency. The good news is that an older i3 box, the performance was much better. Still, at some point it would be nice to understand if the problem lies in 1) the device, 2) the ALSA drivers, 3) the USB drivers, 4) IRQ handling, 5) CPU-specific features (power saving modes, SMIs, etc…) or 6) somewhere else. In the meantime, the patch at least makes the kernel recognize and talk to the UR44.
> 
> Thanks in advance for any comments/suggestions on the patch.

Could you resubmit the patch with these comments (concisely) in
changelog?


Takashi

> 
> Cyrus
> 
> On Mar 10, 2014, at 5:07 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
> 
> > Cyrus Harmon wrote:
> >> Signed-off-by: Cyrus Harmon <cyrus@bobobeach.com>
> >> ---
> >> sound/usb/quirks-table.h | 30 ++++++++++++++++++++++++++++++
> >> 1 file changed, 30 insertions(+)
> > 
> > What kernel version did you test this patch with?
> > 
> > 
> > Regards,
> > Clemens
> > 
> >> 
> >> diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h
> >> index f652b10..987ca01 100644
> >> --- a/sound/usb/quirks-table.h
> >> +++ b/sound/usb/quirks-table.h
> >> @@ -436,6 +436,36 @@ YAMAHA_DEVICE(0x105d, NULL),
> >> 		}
> >> 	}
> >> },
> >> +{
> >> +	USB_DEVICE(0x0499, 0x150e),
> >> +	.driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) {
> >> +		/* .vendor_name = "Yamaha", */
> >> +		/* .product_name = "Steinberg UR44", */
> >> +		.ifnum = QUIRK_ANY_INTERFACE,
> >> +		.type = QUIRK_COMPOSITE,
> >> +		.data = (const struct snd_usb_audio_quirk[]) {
> >> +			{
> >> +				.ifnum = 1,
> >> +				.type = QUIRK_AUDIO_STANDARD_INTERFACE
> >> +			},
> >> +			{
> >> +				.ifnum = 2,
> >> +				.type = QUIRK_AUDIO_STANDARD_INTERFACE
> >> +			},
> >> +			{
> >> +				.ifnum = 3,
> >> +				.type = QUIRK_MIDI_YAMAHA
> >> +			},
> >> +			{
> >> +				.ifnum = 4,
> >> +				.type = QUIRK_IGNORE_INTERFACE
> >> +			},
> >> +			{
> >> +				.ifnum = -1
> >> +			}
> >> +		}
> >> +	}
> >> +},
> >> YAMAHA_DEVICE(0x2000, "DGP-7"),
> >> YAMAHA_DEVICE(0x2001, "DGP-5"),
> >> YAMAHA_DEVICE(0x2002, NULL),
> >> 
> > 
> > 
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
Clemens Ladisch March 10, 2014, 3:40 p.m. UTC | #5
Cyrus Harmon wrote:
> The attached patch provides support for the Steinberg UR44 USB Audio
> Interface. It’s nothing more than Clemens’ patch to support the UR22,
> with the device ID modified for the UR44. The patch was tested with
> kernel versions 3.12.11 and 3.12.12 and I have primarily used it with
> a PREEMPT RT-patched 3.12.12-rt kernel.

In theory, kernel 3.11 and later should support this device without
a quirk entry.  I guess it actually does not?

> I should note that on one of the systems that I used to test the patch
> I was never able to achieve xrun-free JACK performance at -p256 -n3 as
> I would invariably see xruns roughly once every minute.

This sounds as if the playback stream needs to be synchronized to the
recording stream.

What is the output of "lsusb -v" for this device?


Regards,
Clemens
Cyrus Harmon March 11, 2014, 6:33 a.m. UTC | #6
On Mar 10, 2014, at 8:40 AM, Clemens Ladisch <clemens@ladisch.de> wrote:

> Cyrus Harmon wrote:
>> The attached patch provides support for the Steinberg UR44 USB Audio
>> Interface. It’s nothing more than Clemens’ patch to support the UR22,
>> with the device ID modified for the UR44. The patch was tested with
>> kernel versions 3.12.11 and 3.12.12 and I have primarily used it with
>> a PREEMPT RT-patched 3.12.12-rt kernel.
> 
> In theory, kernel 3.11 and later should support this device without
> a quirk entry.  I guess it actually does not?

I had to rebuild an unpatched kernel on this box to convince myself that the stock 3.12.12 (ft-patched) kernel doesn’t recognize this device and, fortunately for my sanity at least, no, the stock kernel doesn’t support this device.

> I should note that on one of the systems that I used to test the patch
>> I was never able to achieve xrun-free JACK performance at -p256 -n3 as
>> I would invariably see xruns roughly once every minute.
> 
> This sounds as if the playback stream needs to be synchronized to the
> recording stream.

Interesting. I’m not quite sure what that means and why the performance would be different between the two boxes, but if there’s a way to get the latency down, I would be thrilled.

> What is the output of "lsusb -v" for this device?

Here’s the output of lsusb -v (as seen by my patched kernel):

Bus 002 Device 003: ID 0499:150e Yamaha Corp. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass         0 
  bDeviceProtocol       255 
  bMaxPacketSize0        64
  idVendor           0x0499 Yamaha Corp.
  idProduct          0x150e 
  bcdDevice            2.00
  iManufacturer           1 Yamaha Corporation
  iProduct                2 Steinberg UR44
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          442
    bNumInterfaces          5
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      1 
      bInterfaceProtocol      0 
      iInterface              0 
      ** UNRECOGNIZED:  0a 24 01 00 01 34 00 02 01 02
      ** UNRECOGNIZED:  0c 24 02 01 01 01 00 02 03 00 00 00
      ** UNRECOGNIZED:  09 24 03 02 01 03 00 01 00
      ** UNRECOGNIZED:  0c 24 02 03 03 06 00 02 03 00 00 00
      ** UNRECOGNIZED:  09 24 03 04 01 01 00 03 00
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      2 
      bInterfaceProtocol      0 
      iInterface              0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      2 
      bInterfaceProtocol      0 
      iInterface              0 
      ** UNRECOGNIZED:  07 24 01 01 01 01 00
      ** UNRECOGNIZED:  0e 24 02 01 06 03 18 02 44 ac 00 80 bb 00
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x07  EP 7 OUT
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x007e  1x 126 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       2
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      2 
      bInterfaceProtocol      0 
      iInterface              0 
      ** UNRECOGNIZED:  07 24 01 01 01 01 00
      ** UNRECOGNIZED:  0e 24 02 01 06 03 18 02 88 58 01 00 77 01
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x07  EP 7 OUT
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x00ea  1x 234 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       3
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      2 
      bInterfaceProtocol      0 
      iInterface              0 
      ** UNRECOGNIZED:  07 24 01 01 01 01 00
      ** UNRECOGNIZED:  0e 24 02 01 06 03 18 02 10 b1 02 00 ee 02
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x07  EP 7 OUT
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x01c2  1x 450 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      2 
      bInterfaceProtocol      0 
      iInterface              0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      2 
      bInterfaceProtocol      0 
      iInterface              0 
      ** UNRECOGNIZED:  07 24 01 04 01 01 00
      ** UNRECOGNIZED:  0e 24 02 01 06 03 18 02 44 ac 00 80 bb 00
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x86  EP 6 IN
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x007e  1x 126 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       2
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      2 
      bInterfaceProtocol      0 
      iInterface              0 
      ** UNRECOGNIZED:  07 24 01 04 01 01 00
      ** UNRECOGNIZED:  0e 24 02 01 06 03 18 02 88 58 01 00 77 01
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x86  EP 6 IN
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x00ea  1x 234 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       3
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      2 
      bInterfaceProtocol      0 
      iInterface              0 
      ** UNRECOGNIZED:  07 24 01 04 01 01 00
      ** UNRECOGNIZED:  0e 24 02 01 06 03 18 02 10 b1 02 00 ee 02
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x86  EP 6 IN
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x01c2  1x 450 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        3
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      3 
      bInterfaceProtocol    255 
      iInterface              0 
      ** UNRECOGNIZED:  07 24 01 00 01 24 00
      ** UNRECOGNIZED:  06 24 02 02 01 00
      ** UNRECOGNIZED:  09 24 03 02 01 01 01 01 00
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        4
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0 
      ** UNRECOGNIZED:  07 24 01 00 01 24 00
      ** UNRECOGNIZED:  06 24 02 02 01 00
      ** UNRECOGNIZED:  09 24 03 02 01 01 01 01 00
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0001
  Self Powered


Thanks,

Cyrus
Clemens Ladisch March 11, 2014, 8:31 a.m. UTC | #7
Cyrus Harmon wrote:
> On Mar 10, 2014, at 8:40 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
>> In theory, kernel 3.11 and later should support this device without
>> a quirk entry.  I guess it actually does not?
>
> no, the stock kernel doesn’t support this device.

Strange; in theory, the driver should be able to pick up these
descriptors.

Are there any error messages in the system log when you plug it in or
reload the unpatch snd-usb-audio driver?


Regards,
Clemens
Cyrus Harmon March 11, 2014, 9:30 a.m. UTC | #8
On Mar 11, 2014, at 1:31 AM, Clemens Ladisch <clemens@ladisch.de> wrote:

> Cyrus Harmon wrote:
>> On Mar 10, 2014, at 8:40 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
>>> In theory, kernel 3.11 and later should support this device without
>>> a quirk entry.  I guess it actually does not?
>> 
>> no, the stock kernel doesn’t support this device.
> 
> Strange; in theory, the driver should be able to pick up these
> descriptors.
> 
> Are there any error messages in the system log when you plug it in or
> reload the unpatch snd-usb-audio driver?

Here’s what I get with the unpatched kernel:

Mar 11 02:25:11 cbox kernel: [   82.426640] usb 2-1.6: new high-speed USB device number 4 using ehci-pci
Mar 11 02:25:12 cbox kernel: [   82.515364] usb 2-1.6: New USB device found, idVendor=0499, idProduct=150e
Mar 11 02:25:12 cbox kernel: [   82.515368] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mar 11 02:25:12 cbox kernel: [   82.515370] usb 2-1.6: Product: Steinberg UR44
Mar 11 02:25:12 cbox kernel: [   82.515372] usb 2-1.6: Manufacturer: Yamaha Corporation
Mar 11 02:25:12 cbox kernel: [   82.518134] snd-usb-audio: probe of 2-1.6:1.0 failed with error -5
Mar 11 02:25:12 cbox kernel: [   82.523317] snd-usb-audio: probe of 2-1.6:1.1 failed with error -5
Mar 11 02:25:12 cbox mtp-probe: checking bus 2, device 4: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6"
Mar 11 02:25:12 cbox mtp-probe: bus: 2, device: 4 was not an MTP device

thanks for taking a look,

Cyrus

> 
> 
> Regards,
> Clemens
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Cyrus Harmon March 17, 2014, 4:29 p.m. UTC | #9
On Mar 11, 2014, at 1:31 AM, Clemens Ladisch <clemens@ladisch.de> wrote:

> Cyrus Harmon wrote:
>> On Mar 10, 2014, at 8:40 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
>>> In theory, kernel 3.11 and later should support this device without
>>> a quirk entry.  I guess it actually does not?
>> 
>> no, the stock kernel doesn’t support this device.
> 
> Strange; in theory, the driver should be able to pick up these
> descriptors.
> 
> Are there any error messages in the system log when you plug it in or
> reload the unpatch snd-usb-audio driver?

Following up on this from last week, here’s the error message I see with an unpatched kernel:

Mar 11 02:25:11 cbox kernel: [   82.426640] usb 2-1.6: new high-speed USB device number 4 using ehci-pci
Mar 11 02:25:12 cbox kernel: [   82.515364] usb 2-1.6: New USB device found, idVendor=0499, idProduct=150e
Mar 11 02:25:12 cbox kernel: [   82.515368] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mar 11 02:25:12 cbox kernel: [   82.515370] usb 2-1.6: Product: Steinberg UR44
Mar 11 02:25:12 cbox kernel: [   82.515372] usb 2-1.6: Manufacturer: Yamaha Corporation
Mar 11 02:25:12 cbox kernel: [   82.518134] snd-usb-audio: probe of 2-1.6:1.0 failed with error -5
Mar 11 02:25:12 cbox kernel: [   82.523317] snd-usb-audio: probe of 2-1.6:1.1 failed with error -5
Mar 11 02:25:12 cbox mtp-probe: checking bus 2, device 4: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6"
Mar 11 02:25:12 cbox mtp-probe: bus: 2, device: 4 was not an MTP device

Any suggestions for further debugging this?

Also, from an earlier message,

On Mar 10, 2014, at 8:40 AM, Clemens Ladisch <clemens@ladisch.de> wrote:

> This sounds as if the playback stream needs to be synchronized to the
> recording stream

Any pointers on where I might look to figure out how to do this?

thanks again,

Cyrus
Cyrus Harmon Nov. 4, 2014, 12:36 a.m. UTC | #10
Well, it's 7 months on and I'm still using a patched kernel to access my 
UR44. Any chance of either seeing my original patch committed, or some 
suggestions on a more proper fix, if there's something with my original 
patch?

thanks,

Cyrus

On 03/17/2014 09:29 AM, Cyrus Harmon wrote:
> On Mar 11, 2014, at 1:31 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
>
>> Cyrus Harmon wrote:
>>> On Mar 10, 2014, at 8:40 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
>>>> In theory, kernel 3.11 and later should support this device without
>>>> a quirk entry.  I guess it actually does not?
>>> no, the stock kernel doesn’t support this device.
>> Strange; in theory, the driver should be able to pick up these
>> descriptors.
>>
>> Are there any error messages in the system log when you plug it in or
>> reload the unpatch snd-usb-audio driver?
> Following up on this from last week, here’s the error message I see with an unpatched kernel:
>
> Mar 11 02:25:11 cbox kernel: [   82.426640] usb 2-1.6: new high-speed USB device number 4 using ehci-pci
> Mar 11 02:25:12 cbox kernel: [   82.515364] usb 2-1.6: New USB device found, idVendor=0499, idProduct=150e
> Mar 11 02:25:12 cbox kernel: [   82.515368] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> Mar 11 02:25:12 cbox kernel: [   82.515370] usb 2-1.6: Product: Steinberg UR44
> Mar 11 02:25:12 cbox kernel: [   82.515372] usb 2-1.6: Manufacturer: Yamaha Corporation
> Mar 11 02:25:12 cbox kernel: [   82.518134] snd-usb-audio: probe of 2-1.6:1.0 failed with error -5
> Mar 11 02:25:12 cbox kernel: [   82.523317] snd-usb-audio: probe of 2-1.6:1.1 failed with error -5
> Mar 11 02:25:12 cbox mtp-probe: checking bus 2, device 4: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6"
> Mar 11 02:25:12 cbox mtp-probe: bus: 2, device: 4 was not an MTP device
>
> Any suggestions for further debugging this?
>
> Also, from an earlier message,
>
> On Mar 10, 2014, at 8:40 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
>
>> This sounds as if the playback stream needs to be synchronized to the
>> recording stream
> Any pointers on where I might look to figure out how to do this?
>
> thanks again,
>
> Cyrus
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Takashi Iwai Nov. 4, 2014, 6:28 a.m. UTC | #11
At Mon, 03 Nov 2014 16:36:58 -0800,
Cyrus Harmon wrote:
> 
> 
> Well, it's 7 months on and I'm still using a patched kernel to access my 
> UR44. Any chance of either seeing my original patch committed, or some 
> suggestions on a more proper fix, if there's something with my original 
> patch?

Which kernel version are you testing?


Takashi

> 
> thanks,
> 
> Cyrus
> 
> On 03/17/2014 09:29 AM, Cyrus Harmon wrote:
> > On Mar 11, 2014, at 1:31 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
> >
> >> Cyrus Harmon wrote:
> >>> On Mar 10, 2014, at 8:40 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
> >>>> In theory, kernel 3.11 and later should support this device without
> >>>> a quirk entry.  I guess it actually does not?
> >>> no, the stock kernel doesn’t support this device.
> >> Strange; in theory, the driver should be able to pick up these
> >> descriptors.
> >>
> >> Are there any error messages in the system log when you plug it in or
> >> reload the unpatch snd-usb-audio driver?
> > Following up on this from last week, here’s the error message I see with an unpatched kernel:
> >
> > Mar 11 02:25:11 cbox kernel: [   82.426640] usb 2-1.6: new high-speed USB device number 4 using ehci-pci
> > Mar 11 02:25:12 cbox kernel: [   82.515364] usb 2-1.6: New USB device found, idVendor=0499, idProduct=150e
> > Mar 11 02:25:12 cbox kernel: [   82.515368] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> > Mar 11 02:25:12 cbox kernel: [   82.515370] usb 2-1.6: Product: Steinberg UR44
> > Mar 11 02:25:12 cbox kernel: [   82.515372] usb 2-1.6: Manufacturer: Yamaha Corporation
> > Mar 11 02:25:12 cbox kernel: [   82.518134] snd-usb-audio: probe of 2-1.6:1.0 failed with error -5
> > Mar 11 02:25:12 cbox kernel: [   82.523317] snd-usb-audio: probe of 2-1.6:1.1 failed with error -5
> > Mar 11 02:25:12 cbox mtp-probe: checking bus 2, device 4: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6"
> > Mar 11 02:25:12 cbox mtp-probe: bus: 2, device: 4 was not an MTP device
> >
> > Any suggestions for further debugging this?
> >
> > Also, from an earlier message,
> >
> > On Mar 10, 2014, at 8:40 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
> >
> >> This sounds as if the playback stream needs to be synchronized to the
> >> recording stream
> > Any pointers on where I might look to figure out how to do this?
> >
> > thanks again,
> >
> > Cyrus
> >
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
Cyrus Harmon Nov. 4, 2014, 8:55 a.m. UTC | #12
I have used a number of 3.1x kernels. At the moment, I'm writing this 
from a 3.17.0 kernel that doesn't recognize the UR44 without my patch.

thanks,

Cyrus

On 11/03/2014 10:28 PM, Takashi Iwai wrote:
> At Mon, 03 Nov 2014 16:36:58 -0800,
> Cyrus Harmon wrote:
>>
>> Well, it's 7 months on and I'm still using a patched kernel to access my
>> UR44. Any chance of either seeing my original patch committed, or some
>> suggestions on a more proper fix, if there's something with my original
>> patch?
> Which kernel version are you testing?
>
>
> Takashi
>
>> thanks,
>>
>> Cyrus
>>
>> On 03/17/2014 09:29 AM, Cyrus Harmon wrote:
>>> On Mar 11, 2014, at 1:31 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
>>>
>>>> Cyrus Harmon wrote:
>>>>> On Mar 10, 2014, at 8:40 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
>>>>>> In theory, kernel 3.11 and later should support this device without
>>>>>> a quirk entry.  I guess it actually does not?
>>>>> no, the stock kernel doesn’t support this device.
>>>> Strange; in theory, the driver should be able to pick up these
>>>> descriptors.
>>>>
>>>> Are there any error messages in the system log when you plug it in or
>>>> reload the unpatch snd-usb-audio driver?
>>> Following up on this from last week, here’s the error message I see with an unpatched kernel:
>>>
>>> Mar 11 02:25:11 cbox kernel: [   82.426640] usb 2-1.6: new high-speed USB device number 4 using ehci-pci
>>> Mar 11 02:25:12 cbox kernel: [   82.515364] usb 2-1.6: New USB device found, idVendor=0499, idProduct=150e
>>> Mar 11 02:25:12 cbox kernel: [   82.515368] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
>>> Mar 11 02:25:12 cbox kernel: [   82.515370] usb 2-1.6: Product: Steinberg UR44
>>> Mar 11 02:25:12 cbox kernel: [   82.515372] usb 2-1.6: Manufacturer: Yamaha Corporation
>>> Mar 11 02:25:12 cbox kernel: [   82.518134] snd-usb-audio: probe of 2-1.6:1.0 failed with error -5
>>> Mar 11 02:25:12 cbox kernel: [   82.523317] snd-usb-audio: probe of 2-1.6:1.1 failed with error -5
>>> Mar 11 02:25:12 cbox mtp-probe: checking bus 2, device 4: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6"
>>> Mar 11 02:25:12 cbox mtp-probe: bus: 2, device: 4 was not an MTP device
>>>
>>> Any suggestions for further debugging this?
>>>
>>> Also, from an earlier message,
>>>
>>> On Mar 10, 2014, at 8:40 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
>>>
>>>> This sounds as if the playback stream needs to be synchronized to the
>>>> recording stream
>>> Any pointers on where I might look to figure out how to do this?
>>>
>>> thanks again,
>>>
>>> Cyrus
>>>
>>> _______________________________________________
>>> Alsa-devel mailing list
>>> Alsa-devel@alsa-project.org
>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>> _______________________________________________
>> Alsa-devel mailing list
>> Alsa-devel@alsa-project.org
>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Clemens Ladisch Nov. 4, 2014, 8:59 a.m. UTC | #13
Cyrus Harmon wrote:
> Any chance of either seeing my original patch committed?

There are enough other similar quirks, so:

Acked-by: Clemens Ladisch <clemens@ladisch.de>
Takashi Iwai Nov. 5, 2014, 11:14 p.m. UTC | #14
At Tue, 04 Nov 2014 00:55:11 -0800,
Cyrus Harmon wrote:
> 
> 
> I have used a number of 3.1x kernels. At the moment, I'm writing this 
> from a 3.17.0 kernel that doesn't recognize the UR44 without my patch.

OK, could you repost the patch (and put me to Cc) so that I can apply
to for-next branch?


thanks,

Takashi


> 
> thanks,
> 
> Cyrus
> 
> On 11/03/2014 10:28 PM, Takashi Iwai wrote:
> > At Mon, 03 Nov 2014 16:36:58 -0800,
> > Cyrus Harmon wrote:
> >>
> >> Well, it's 7 months on and I'm still using a patched kernel to access my
> >> UR44. Any chance of either seeing my original patch committed, or some
> >> suggestions on a more proper fix, if there's something with my original
> >> patch?
> > Which kernel version are you testing?
> >
> >
> > Takashi
> >
> >> thanks,
> >>
> >> Cyrus
> >>
> >> On 03/17/2014 09:29 AM, Cyrus Harmon wrote:
> >>> On Mar 11, 2014, at 1:31 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
> >>>
> >>>> Cyrus Harmon wrote:
> >>>>> On Mar 10, 2014, at 8:40 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
> >>>>>> In theory, kernel 3.11 and later should support this device without
> >>>>>> a quirk entry.  I guess it actually does not?
> >>>>> no, the stock kernel doesn’t support this device.
> >>>> Strange; in theory, the driver should be able to pick up these
> >>>> descriptors.
> >>>>
> >>>> Are there any error messages in the system log when you plug it in or
> >>>> reload the unpatch snd-usb-audio driver?
> >>> Following up on this from last week, here’s the error message I see with an unpatched kernel:
> >>>
> >>> Mar 11 02:25:11 cbox kernel: [   82.426640] usb 2-1.6: new high-speed USB device number 4 using ehci-pci
> >>> Mar 11 02:25:12 cbox kernel: [   82.515364] usb 2-1.6: New USB device found, idVendor=0499, idProduct=150e
> >>> Mar 11 02:25:12 cbox kernel: [   82.515368] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> >>> Mar 11 02:25:12 cbox kernel: [   82.515370] usb 2-1.6: Product: Steinberg UR44
> >>> Mar 11 02:25:12 cbox kernel: [   82.515372] usb 2-1.6: Manufacturer: Yamaha Corporation
> >>> Mar 11 02:25:12 cbox kernel: [   82.518134] snd-usb-audio: probe of 2-1.6:1.0 failed with error -5
> >>> Mar 11 02:25:12 cbox kernel: [   82.523317] snd-usb-audio: probe of 2-1.6:1.1 failed with error -5
> >>> Mar 11 02:25:12 cbox mtp-probe: checking bus 2, device 4: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6"
> >>> Mar 11 02:25:12 cbox mtp-probe: bus: 2, device: 4 was not an MTP device
> >>>
> >>> Any suggestions for further debugging this?
> >>>
> >>> Also, from an earlier message,
> >>>
> >>> On Mar 10, 2014, at 8:40 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
> >>>
> >>>> This sounds as if the playback stream needs to be synchronized to the
> >>>> recording stream
> >>> Any pointers on where I might look to figure out how to do this?
> >>>
> >>> thanks again,
> >>>
> >>> Cyrus
> >>>
> >>> _______________________________________________
> >>> Alsa-devel mailing list
> >>> Alsa-devel@alsa-project.org
> >>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >> _______________________________________________
> >> Alsa-devel mailing list
> >> Alsa-devel@alsa-project.org
> >> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >>
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Cyrus Harmon Nov. 6, 2014, 4:39 a.m. UTC | #15
Hi Takashi,

Clemens has sent me another diagnostic/debugging patch to try. Perhaps 
we should wait to see the results of that before pushing to for-next. If 
we don't get a deeper understanding of the problem in the next couple of 
days, I'll send along the original patch.

thanks,

Cyrus

On 11/05/2014 03:14 PM, Takashi Iwai wrote:
> At Tue, 04 Nov 2014 00:55:11 -0800,
> Cyrus Harmon wrote:
>>
>> I have used a number of 3.1x kernels. At the moment, I'm writing this
>> from a 3.17.0 kernel that doesn't recognize the UR44 without my patch.
> OK, could you repost the patch (and put me to Cc) so that I can apply
> to for-next branch?
>
>
> thanks,
>
> Takashi
>
>
>> thanks,
>>
>> Cyrus
>>
>> On 11/03/2014 10:28 PM, Takashi Iwai wrote:
>>> At Mon, 03 Nov 2014 16:36:58 -0800,
>>> Cyrus Harmon wrote:
>>>> Well, it's 7 months on and I'm still using a patched kernel to access my
>>>> UR44. Any chance of either seeing my original patch committed, or some
>>>> suggestions on a more proper fix, if there's something with my original
>>>> patch?
>>> Which kernel version are you testing?
>>>
>>>
>>> Takashi
>>>
>>>> thanks,
>>>>
>>>> Cyrus
>>>>
>>>> On 03/17/2014 09:29 AM, Cyrus Harmon wrote:
>>>>> On Mar 11, 2014, at 1:31 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
>>>>>
>>>>>> Cyrus Harmon wrote:
>>>>>>> On Mar 10, 2014, at 8:40 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
>>>>>>>> In theory, kernel 3.11 and later should support this device without
>>>>>>>> a quirk entry.  I guess it actually does not?
>>>>>>> no, the stock kernel doesn’t support this device.
>>>>>> Strange; in theory, the driver should be able to pick up these
>>>>>> descriptors.
>>>>>>
>>>>>> Are there any error messages in the system log when you plug it in or
>>>>>> reload the unpatch snd-usb-audio driver?
>>>>> Following up on this from last week, here’s the error message I see with an unpatched kernel:
>>>>>
>>>>> Mar 11 02:25:11 cbox kernel: [   82.426640] usb 2-1.6: new high-speed USB device number 4 using ehci-pci
>>>>> Mar 11 02:25:12 cbox kernel: [   82.515364] usb 2-1.6: New USB device found, idVendor=0499, idProduct=150e
>>>>> Mar 11 02:25:12 cbox kernel: [   82.515368] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
>>>>> Mar 11 02:25:12 cbox kernel: [   82.515370] usb 2-1.6: Product: Steinberg UR44
>>>>> Mar 11 02:25:12 cbox kernel: [   82.515372] usb 2-1.6: Manufacturer: Yamaha Corporation
>>>>> Mar 11 02:25:12 cbox kernel: [   82.518134] snd-usb-audio: probe of 2-1.6:1.0 failed with error -5
>>>>> Mar 11 02:25:12 cbox kernel: [   82.523317] snd-usb-audio: probe of 2-1.6:1.1 failed with error -5
>>>>> Mar 11 02:25:12 cbox mtp-probe: checking bus 2, device 4: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6"
>>>>> Mar 11 02:25:12 cbox mtp-probe: bus: 2, device: 4 was not an MTP device
>>>>>
>>>>> Any suggestions for further debugging this?
>>>>>
>>>>> Also, from an earlier message,
>>>>>
>>>>> On Mar 10, 2014, at 8:40 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
>>>>>
>>>>>> This sounds as if the playback stream needs to be synchronized to the
>>>>>> recording stream
>>>>> Any pointers on where I might look to figure out how to do this?
>>>>>
>>>>> thanks again,
>>>>>
>>>>> Cyrus
>>>>>
>>>>> _______________________________________________
>>>>> Alsa-devel mailing list
>>>>> Alsa-devel@alsa-project.org
>>>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>> _______________________________________________
>>>> Alsa-devel mailing list
>>>> Alsa-devel@alsa-project.org
>>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>>
>>> _______________________________________________
>>> Alsa-devel mailing list
>>> Alsa-devel@alsa-project.org
>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>> _______________________________________________
>> Alsa-devel mailing list
>> Alsa-devel@alsa-project.org
>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Vlad Catoi Nov. 6, 2014, 5:28 a.m. UTC | #16
Cyrus, 

Pass it along, I can try it on the UR22 as well.

~Vlad

On Wed, 2014-11-05 at 20:39 -0800, Cyrus Harmon wrote:
> Hi Takashi,
> 
> Clemens has sent me another diagnostic/debugging patch to try. Perhaps 
> we should wait to see the results of that before pushing to for-next. If 
> we don't get a deeper understanding of the problem in the next couple of 
> days, I'll send along the original patch.
> 
> thanks,
> 
> Cyrus
> 
> On 11/05/2014 03:14 PM, Takashi Iwai wrote:
> > At Tue, 04 Nov 2014 00:55:11 -0800,
> > Cyrus Harmon wrote:
> >>
> >> I have used a number of 3.1x kernels. At the moment, I'm writing this
> >> from a 3.17.0 kernel that doesn't recognize the UR44 without my patch.
> > OK, could you repost the patch (and put me to Cc) so that I can apply
> > to for-next branch?
> >
> >
> > thanks,
> >
> > Takashi
> >
> >
> >> thanks,
> >>
> >> Cyrus
> >>
> >> On 11/03/2014 10:28 PM, Takashi Iwai wrote:
> >>> At Mon, 03 Nov 2014 16:36:58 -0800,
> >>> Cyrus Harmon wrote:
> >>>> Well, it's 7 months on and I'm still using a patched kernel to access my
> >>>> UR44. Any chance of either seeing my original patch committed, or some
> >>>> suggestions on a more proper fix, if there's something with my original
> >>>> patch?
> >>> Which kernel version are you testing?
> >>>
> >>>
> >>> Takashi
> >>>
> >>>> thanks,
> >>>>
> >>>> Cyrus
> >>>>
> >>>> On 03/17/2014 09:29 AM, Cyrus Harmon wrote:
> >>>>> On Mar 11, 2014, at 1:31 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
> >>>>>
> >>>>>> Cyrus Harmon wrote:
> >>>>>>> On Mar 10, 2014, at 8:40 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
> >>>>>>>> In theory, kernel 3.11 and later should support this device without
> >>>>>>>> a quirk entry.  I guess it actually does not?
> >>>>>>> no, the stock kernel doesn’t support this device.
> >>>>>> Strange; in theory, the driver should be able to pick up these
> >>>>>> descriptors.
> >>>>>>
> >>>>>> Are there any error messages in the system log when you plug it in or
> >>>>>> reload the unpatch snd-usb-audio driver?
> >>>>> Following up on this from last week, here’s the error message I see with an unpatched kernel:
> >>>>>
> >>>>> Mar 11 02:25:11 cbox kernel: [   82.426640] usb 2-1.6: new high-speed USB device number 4 using ehci-pci
> >>>>> Mar 11 02:25:12 cbox kernel: [   82.515364] usb 2-1.6: New USB device found, idVendor=0499, idProduct=150e
> >>>>> Mar 11 02:25:12 cbox kernel: [   82.515368] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> >>>>> Mar 11 02:25:12 cbox kernel: [   82.515370] usb 2-1.6: Product: Steinberg UR44
> >>>>> Mar 11 02:25:12 cbox kernel: [   82.515372] usb 2-1.6: Manufacturer: Yamaha Corporation
> >>>>> Mar 11 02:25:12 cbox kernel: [   82.518134] snd-usb-audio: probe of 2-1.6:1.0 failed with error -5
> >>>>> Mar 11 02:25:12 cbox kernel: [   82.523317] snd-usb-audio: probe of 2-1.6:1.1 failed with error -5
> >>>>> Mar 11 02:25:12 cbox mtp-probe: checking bus 2, device 4: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6"
> >>>>> Mar 11 02:25:12 cbox mtp-probe: bus: 2, device: 4 was not an MTP device
> >>>>>
> >>>>> Any suggestions for further debugging this?
> >>>>>
> >>>>> Also, from an earlier message,
> >>>>>
> >>>>> On Mar 10, 2014, at 8:40 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
> >>>>>
> >>>>>> This sounds as if the playback stream needs to be synchronized to the
> >>>>>> recording stream
> >>>>> Any pointers on where I might look to figure out how to do this?
> >>>>>
> >>>>> thanks again,
> >>>>>
> >>>>> Cyrus
> >>>>>
> >>>>> _______________________________________________
> >>>>> Alsa-devel mailing list
> >>>>> Alsa-devel@alsa-project.org
> >>>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >>>> _______________________________________________
> >>>> Alsa-devel mailing list
> >>>> Alsa-devel@alsa-project.org
> >>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >>>>
> >>> _______________________________________________
> >>> Alsa-devel mailing list
> >>> Alsa-devel@alsa-project.org
> >>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >> _______________________________________________
> >> Alsa-devel mailing list
> >> Alsa-devel@alsa-project.org
> >> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Patch
diff mbox

diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h
index f652b10..987ca01 100644
--- a/sound/usb/quirks-table.h
+++ b/sound/usb/quirks-table.h
@@ -436,6 +436,36 @@  YAMAHA_DEVICE(0x105d, NULL),
 		}
 	}
 },
+{
+	USB_DEVICE(0x0499, 0x150e),
+	.driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) {
+		/* .vendor_name = "Yamaha", */
+		/* .product_name = "Steinberg UR44", */
+		.ifnum = QUIRK_ANY_INTERFACE,
+		.type = QUIRK_COMPOSITE,
+		.data = (const struct snd_usb_audio_quirk[]) {
+			{
+				.ifnum = 1,
+				.type = QUIRK_AUDIO_STANDARD_INTERFACE
+			},
+			{
+				.ifnum = 2,
+				.type = QUIRK_AUDIO_STANDARD_INTERFACE
+			},
+			{
+				.ifnum = 3,
+				.type = QUIRK_MIDI_YAMAHA
+			},
+			{
+				.ifnum = 4,
+				.type = QUIRK_IGNORE_INTERFACE
+			},
+			{
+				.ifnum = -1
+			}
+		}
+	}
+},
 YAMAHA_DEVICE(0x2000, "DGP-7"),
 YAMAHA_DEVICE(0x2001, "DGP-5"),
 YAMAHA_DEVICE(0x2002, NULL),