Signed-off-by: Cyrus Harmon cyrus@bobobeach.com --- 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),
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
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),
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),
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
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
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
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
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
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
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
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
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
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
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
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
I think UR22 works! I'm just aping the UR22 support to work for UR44!
But, here it is:
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),
On 11/05/2014 09:28 PM, Vlad Catoi wrote:
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
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Oh! Sorry, I thought you guys were trying to get this to work without needing the quirks :)
~Vlad
On Wed, 2014-11-05 at 21:32 -0800, Cyrus Harmon wrote:
I think UR22 works! I'm just aping the UR22 support to work for UR44!
But, here it is:
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 structsnd_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),
On 11/05/2014 09:28 PM, Vlad Catoi wrote:
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
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 wrote:
Any chance of either seeing my original patch committed?
There are enough other similar quirks, so:
Acked-by: Clemens Ladisch clemens@ladisch.de
Cyrus Harmon wrote:
On Mar 11, 2014, at 1:31 AM, Clemens Ladisch wrote:
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?
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
Please try the patch below to get more information in the log.
Regards, Clemens
--- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -196,19 +196,23 @@ * future ones might change, so ensure that we fail silently if the * interface doesn't look exactly right. */ + dev_info(&iface->dev, "checking PCM interface\n");
/* must have a non-zero altsetting for streaming */ if (iface->num_altsetting < 2) return -ENODEV; + dev_info(&iface->dev, "altsets found\n"); alts = &iface->altsetting[1]; altsd = get_iface_desc(alts);
/* must have an isochronous endpoint for streaming */ if (altsd->bNumEndpoints < 1) return -ENODEV; + dev_info(&iface->dev, "endpoint found\n"); epd = get_endpoint(alts, 0); if (!usb_endpoint_xfer_isoc(epd)) return -ENODEV; + dev_info(&iface->dev, "iso found\n");
/* must have format descriptors */ ashd = snd_usb_find_csint_desc(alts->extra, alts->extralen, NULL, @@ -219,6 +223,7 @@ !fmtd || fmtd->bLength < 8) return -ENODEV;
+ dev_info(&iface->dev, "descriptors found\n"); return create_standard_audio_quirk(chip, iface, driver, NULL); }
Hi Clemens,
When I try that, I see the following in the dmesg log:
[ 2.963091] usb 3-3.2: New USB device found, idVendor=0499, idProduct=150e [ 2.963093] usb 3-3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2.963094] usb 3-3.2: Product: Steinberg UR44 [ 2.963095] usb 3-3.2: Manufacturer: Yamaha Corporation [ 2.963988] nvidia 0000:01:00.0: irq 31 for MSI/MSI-X [ 2.964094] snd-usb-audio 3-3.2:1.0: checking PCM interface [ 2.964104] snd-usb-audio: probe of 3-3.2:1.0 failed with error -5 [ 2.966339] snd-usb-audio 3-3.2:1.1: checking PCM interface [ 2.966341] snd-usb-audio 3-3.2:1.1: altsets found [ 2.966342] snd-usb-audio 3-3.2:1.1: endpoint found [ 2.966343] snd-usb-audio 3-3.2:1.1: iso found [ 2.966344] snd-usb-audio 3-3.2:1.1: descriptors found [ 2.968544] usb 3-3.2:1.0: checking PCM interface [ 2.968546] usb 3-3.2:1.2: checking PCM interface [ 2.968547] usb 3-3.2:1.2: altsets found [ 2.968547] usb 3-3.2:1.2: endpoint found [ 2.968548] usb 3-3.2:1.2: iso found [ 2.968549] usb 3-3.2:1.2: descriptors found [ 2.970657] usb 3-3.2:1.3: checking PCM interface [ 2.970666] usb 3-3.2:1.4: checking PCM interface [ 2.970930] snd-usb-audio: probe of 3-3.2:1.1 failed with error -5 [ 2.974643] systemd-udevd[569]: Failed to apply ACL on /dev/snd/pcmC3D0p: No such file or directory [ 2.974694] systemd-udevd[568]: error opening ATTR{/sys/devices/pci0000:00/0000:00:14.0/usb3/3-3/3-3.2/3-3.2:1.1/sound/card3/controlC3/../uev ent} for writing: No such file or directory [ 2.974710] systemd-udevd[571]: Failed to apply ACL on /dev/snd/midiC3D0: No such file or directory [ 2.974779] systemd-udevd[568]: Failed to apply ACL on /dev/snd/controlC3: No such file or directory [ 2.975019] systemd-udevd[570]: Failed to apply ACL on /dev/snd/pcmC3D0c: No such file or directory
Thanks,
Cyrus
On 11/04/2014 01:00 AM, Clemens Ladisch wrote:
Cyrus Harmon wrote:
On Mar 11, 2014, at 1:31 AM, Clemens Ladisch wrote:
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?
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
Please try the patch below to get more information in the log.
Regards, Clemens
--- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -196,19 +196,23 @@ * future ones might change, so ensure that we fail silently if the * interface doesn't look exactly right. */
dev_info(&iface->dev, "checking PCM interface\n");
/* must have a non-zero altsetting for streaming */ if (iface->num_altsetting < 2) return -ENODEV;
dev_info(&iface->dev, "altsets found\n"); alts = &iface->altsetting[1]; altsd = get_iface_desc(alts);
/* must have an isochronous endpoint for streaming */ if (altsd->bNumEndpoints < 1) return -ENODEV;
dev_info(&iface->dev, "endpoint found\n"); epd = get_endpoint(alts, 0); if (!usb_endpoint_xfer_isoc(epd)) return -ENODEV;
dev_info(&iface->dev, "iso found\n");
/* must have format descriptors */ ashd = snd_usb_find_csint_desc(alts->extra, alts->extralen, NULL,
@@ -219,6 +223,7 @@ !fmtd || fmtd->bLength < 8) return -ENODEV;
- dev_info(&iface->dev, "descriptors found\n"); return create_standard_audio_quirk(chip, iface, driver, NULL); }
Cyrus Harmon wrote:
[ 2.964094] snd-usb-audio 3-3.2:1.0: checking PCM interface [ 2.964104] snd-usb-audio: probe of 3-3.2:1.0 failed with error -5 [ 2.966339] snd-usb-audio 3-3.2:1.1: checking PCM interface [ 2.966341] snd-usb-audio 3-3.2:1.1: altsets found [ 2.966342] snd-usb-audio 3-3.2:1.1: endpoint found [ 2.966343] snd-usb-audio 3-3.2:1.1: iso found [ 2.966344] snd-usb-audio 3-3.2:1.1: descriptors found [ 2.968544] usb 3-3.2:1.0: checking PCM interface [ 2.968546] usb 3-3.2:1.2: checking PCM interface [ 2.968547] usb 3-3.2:1.2: altsets found [ 2.968547] usb 3-3.2:1.2: endpoint found [ 2.968548] usb 3-3.2:1.2: iso found [ 2.968549] usb 3-3.2:1.2: descriptors found [ 2.970657] usb 3-3.2:1.3: checking PCM interface [ 2.970666] usb 3-3.2:1.4: checking PCM interface [ 2.970930] snd-usb-audio: probe of 3-3.2:1.1 failed with error -5
Strange; in theory, this cannot happen.
Please add this patch and try again.
Regards, Clemens
--- a/sound/usb/card.c +++ b/sound/usb/card.c @@ -536,7 +536,9 @@ snd_usb_audio_probe(struct usb_device *dev, err = 1; /* continue */ if (quirk && quirk->ifnum != QUIRK_NO_INTERFACE) { /* need some special handlings */ - if ((err = snd_usb_create_quirk(chip, intf, &usb_audio_driver, quirk)) < 0) + err = snd_usb_create_quirk(chip, intf, &usb_audio_driver, quirk); + dev_info(&intf->dev, "quirk return code: %d\n", err); + if (err < 0) goto __error; }
@@ -547,11 +549,13 @@ snd_usb_audio_probe(struct usb_device *dev, goto __error; } } + dev_info(&intf->dev, "probe step 2\n");
/* we are allowed to call snd_card_register() many times */ if (snd_card_register(chip->card) < 0) { goto __error; } + dev_info(&intf->dev, "probe step 3\n");
usb_chip[chip->index] = chip; chip->num_interfaces++; @@ -560,6 +564,7 @@ snd_usb_audio_probe(struct usb_device *dev, return chip;
__error: + dev_info(&intf->dev, "probe failed\n"); if (chip) { if (!chip->num_interfaces) snd_card_free(chip->card); --- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -367,6 +367,7 @@ static int create_autodetect_quirks(struct snd_usb_audio *chip, err = create_autodetect_quirk(chip, iface, driver); if (err < 0) return err; + dev_info(&iface->dev, "first interface successful\n");
/* * ALSA PCM playback/capture devices cannot be registered in two steps, @@ -385,9 +386,13 @@ static int create_autodetect_quirks(struct snd_usb_audio *chip,
err = create_autodetect_quirk(chip, iface, driver); if (err >= 0) + { usb_driver_claim_interface(driver, iface, (void *)-1L); + dev_info(&iface->dev, "interface %d successful\n", ifnum); + } }
+ dev_info(&iface->dev, "create_autodetect_quirks successful\n"); return 0; }
Clemens,
Here's what I get with the new (and old) patch(es):
[ 2.869556] usb 3-3.2: new high-speed USB device number 6 using xhci_hcd [ 2.970810] usb 3-3.2: New USB device found, idVendor=0499, idProduct=150e [ 2.970813] usb 3-3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2.970814] usb 3-3.2: Product: Steinberg UR44 [ 2.970815] usb 3-3.2: Manufacturer: Yamaha Corporation [ 2.973563] snd-usb-audio 3-3.2:1.0: checking PCM interface [ 2.973565] snd-usb-audio 3-3.2:1.0: quirk return code: -19 [ 2.973566] snd-usb-audio 3-3.2:1.0: probe failed [ 2.973574] snd-usb-audio: probe of 3-3.2:1.0 failed with error -5 [ 2.974003] snd-usb-audio 3-3.2:1.1: checking PCM interface [ 2.974005] snd-usb-audio 3-3.2:1.1: altsets found [ 2.974007] snd-usb-audio 3-3.2:1.1: endpoint found [ 2.974008] snd-usb-audio 3-3.2:1.1: iso found [ 2.974010] snd-usb-audio 3-3.2:1.1: descriptors found [ 2.976115] snd-usb-audio 3-3.2:1.1: first interface successful [ 2.976117] usb 3-3.2:1.0: checking PCM interface [ 2.976117] usb 3-3.2:1.2: checking PCM interface [ 2.976118] usb 3-3.2:1.2: altsets found [ 2.976119] usb 3-3.2:1.2: endpoint found [ 2.976120] usb 3-3.2:1.2: iso found [ 2.976120] usb 3-3.2:1.2: descriptors found [ 2.976641] usb 3-3.2: current rate 192000 is different from the runtime rate 48000 [ 2.978137] snd-usb-audio 3-3.2:1.2: interface 2 successful [ 2.978140] usb 3-3.2:1.3: checking PCM interface [ 2.978148] snd-usb-audio 3-3.2:1.3: interface 3 successful [ 2.978150] usb 3-3.2:1.4: checking PCM interface [ 2.978155] snd-usb-audio 3-3.2:1.4: interface 4 successful [ 2.978157] snd-usb-audio 3-3.2:1.4: create_autodetect_quirks successful [ 2.978158] snd-usb-audio 3-3.2:1.1: quirk return code: 0 [ 2.978159] snd-usb-audio 3-3.2:1.1: probe step 2 [ 2.978334] snd-usb-audio 3-3.2:1.1: probe failed [ 2.978439] snd-usb-audio: probe of 3-3.2:1.1 failed with error -5 [ 2.981241] systemd-udevd[510]: error opening ATTR{/sys/devices/pci0000:00/0000:00:14.0/usb3/3-3/3-3.2/3-3.2:1.1/sound/ card3/controlC3/../uevent} for writing: No such file or directory [ 2.981342] systemd-udevd[511]: Failed to apply ACL on /dev/snd/pcmC3D0p: No such file or directory [ 2.981361] systemd-udevd[510]: Failed to apply ACL on /dev/snd/controlC3: No such file or directory [ 2.981420] systemd-udevd[547]: Failed to apply ACL on /dev/snd/midiC3D0: No such file or directory [ 2.981560] systemd-udevd[546]: Failed to apply ACL on /dev/snd/pcmC3D0c: No such file or directory
thanks for looking into this,
Cyrus
On 11/05/2014 01:17 PM, Clemens Ladisch wrote:
Cyrus Harmon wrote:
[ 2.964094] snd-usb-audio 3-3.2:1.0: checking PCM interface [ 2.964104] snd-usb-audio: probe of 3-3.2:1.0 failed with error -5 [ 2.966339] snd-usb-audio 3-3.2:1.1: checking PCM interface [ 2.966341] snd-usb-audio 3-3.2:1.1: altsets found [ 2.966342] snd-usb-audio 3-3.2:1.1: endpoint found [ 2.966343] snd-usb-audio 3-3.2:1.1: iso found [ 2.966344] snd-usb-audio 3-3.2:1.1: descriptors found [ 2.968544] usb 3-3.2:1.0: checking PCM interface [ 2.968546] usb 3-3.2:1.2: checking PCM interface [ 2.968547] usb 3-3.2:1.2: altsets found [ 2.968547] usb 3-3.2:1.2: endpoint found [ 2.968548] usb 3-3.2:1.2: iso found [ 2.968549] usb 3-3.2:1.2: descriptors found [ 2.970657] usb 3-3.2:1.3: checking PCM interface [ 2.970666] usb 3-3.2:1.4: checking PCM interface [ 2.970930] snd-usb-audio: probe of 3-3.2:1.1 failed with error -5
Strange; in theory, this cannot happen.
Please add this patch and try again.
Regards, Clemens
--- a/sound/usb/card.c +++ b/sound/usb/card.c @@ -536,7 +536,9 @@ snd_usb_audio_probe(struct usb_device *dev, err = 1; /* continue */ if (quirk && quirk->ifnum != QUIRK_NO_INTERFACE) { /* need some special handlings */
if ((err = snd_usb_create_quirk(chip, intf, &usb_audio_driver, quirk)) < 0)
err = snd_usb_create_quirk(chip, intf, &usb_audio_driver, quirk);dev_info(&intf->dev, "quirk return code: %d\n", err);if (err < 0) goto __error;@@ -547,11 +549,13 @@ snd_usb_audio_probe(struct usb_device *dev, goto __error; } }
dev_info(&intf->dev, "probe step 2\n");
/* we are allowed to call snd_card_register() many times */ if (snd_card_register(chip->card) < 0) { goto __error; }
dev_info(&intf->dev, "probe step 3\n");
usb_chip[chip->index] = chip; chip->num_interfaces++;
@@ -560,6 +564,7 @@ snd_usb_audio_probe(struct usb_device *dev, return chip;
__error:
- dev_info(&intf->dev, "probe failed\n"); if (chip) { if (!chip->num_interfaces) snd_card_free(chip->card);
--- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -367,6 +367,7 @@ static int create_autodetect_quirks(struct snd_usb_audio *chip, err = create_autodetect_quirk(chip, iface, driver); if (err < 0) return err;
dev_info(&iface->dev, "first interface successful\n");
/*
- ALSA PCM playback/capture devices cannot be registered in two steps,
@@ -385,9 +386,13 @@ static int create_autodetect_quirks(struct snd_usb_audio *chip,
err = create_autodetect_quirk(chip, iface, driver); if (err >= 0)
{ usb_driver_claim_interface(driver, iface, (void *)-1L);dev_info(&iface->dev, "interface %d successful\n", ifnum);}}
dev_info(&iface->dev, "create_autodetect_quirks successful\n"); return 0; }
(Sorry for the delay.)
Cyrus Harmon wrote:
[ 2.978159] snd-usb-audio 3-3.2:1.1: probe step 2 [ 2.978334] snd-usb-audio 3-3.2:1.1: probe failed
Still mysterious. Please try with this patch instead.
Regards, Clemens
--- a/sound/core/pcm.c +++ b/sound/core/pcm.c @@ -1086,6 +1086,7 @@ static int snd_pcm_dev_register(struct snd_device *device) mutex_lock(®ister_mutex); err = snd_pcm_add(pcm); if (err) { + printk(KERN_ERR "snd_pcm_add(%d) failed\n", pcm->device); mutex_unlock(®ister_mutex); return err; } @@ -1115,6 +1116,7 @@ static int snd_pcm_dev_register(struct snd_device *device) &snd_pcm_f_ops[cidx], pcm, str, dev); if (err < 0) { + dev_err(dev, "snd_register_device_for_dev failed: %d\n", err); list_del(&pcm->list); mutex_unlock(®ister_mutex); return err;
On 11/15/2014 05:00 AM, Clemens Ladisch wrote:
(Sorry for the delay.) Cyrus Harmon wrote:
[ 2.978159] snd-usb-audio 3-3.2:1.1: probe step 2 [ 2.978334] snd-usb-audio 3-3.2:1.1: probe failed
Still mysterious. Please try with this patch instead.
(Sorry for yet another delay)
I'm not sure the debugging patch here was properly applied/installed, but I think so. In any event, perhaps with this patch, and definitely for your previous 2 patches, updated for the 3.19-rc7 sources, I get the following errors when I try to load snd-usb-aduio:
[ 294.270316] snd-usb-audio 1-3.2:1.0: checking PCM interface [ 294.270319] snd-usb-audio 1-3.2:1.0: quirk return code: -19 [ 294.270321] snd-usb-audio 1-3.2:1.0: probe failed [ 294.270773] snd-usb-audio 1-3.2:1.1: checking PCM interface [ 294.270775] snd-usb-audio 1-3.2:1.1: altsets found [ 294.270776] snd-usb-audio 1-3.2:1.1: endpoint found [ 294.270778] snd-usb-audio 1-3.2:1.1: iso found [ 294.270779] snd-usb-audio 1-3.2:1.1: descriptors found [ 294.272941] snd-usb-audio 1-3.2:1.1: first interface successful [ 294.272943] usb 1-3.2:1.0: checking PCM interface [ 294.272945] usb 1-3.2:1.2: checking PCM interface [ 294.272946] usb 1-3.2:1.2: altsets found [ 294.272947] usb 1-3.2:1.2: endpoint found [ 294.272948] usb 1-3.2:1.2: iso found [ 294.272949] usb 1-3.2:1.2: descriptors found [ 294.275044] snd-usb-audio 1-3.2:1.2: interface 2 successful [ 294.275047] usb 1-3.2:1.3: checking PCM interface [ 294.275056] snd-usb-audio 1-3.2:1.3: interface 3 successful [ 294.275057] usb 1-3.2:1.4: checking PCM interface [ 294.275065] snd-usb-audio 1-3.2:1.4: interface 4 successful [ 294.275066] snd-usb-audio 1-3.2:1.4: create_autodetect_quirks successful [ 294.275067] snd-usb-audio 1-3.2:1.1: quirk return code: 0 [ 294.275068] snd-usb-audio 1-3.2:1.1: probe step 2 [ 294.275297] snd-usb-audio 1-3.2:1.1: probe failed [ 294.275465] snd-usb-audio: probe of 1-3.2:1.1 failed with error -16 [ 294.275490] usbcore: registered new interface driver snd-usb-audio [ 294.276043] systemd-udevd[4350]: Failed to apply ACL on /dev/snd/pcmC3D0p: No such file or directory [ 294.276047] systemd-udevd[4350]: Failed to apply ACL on /dev/snd/pcmC3D0p: No such file or directory [ 294.276164] systemd-udevd[4348]: Failed to apply ACL on /dev/snd/controlC3: No such file or directory [ 294.276169] systemd-udevd[4348]: Failed to apply ACL on /dev/snd/controlC3: No such file or directory [ 294.276219] systemd-udevd[4353]: Failed to apply ACL on /dev/snd/pcmC3D0c: No such file or directory [ 294.276223] systemd-udevd[4353]: Failed to apply ACL on /dev/snd/pcmC3D0c: No such file or directory [ 294.276802] systemd-udevd[4354]: Failed to apply ACL on /dev/snd/midiC3D0: No such file or directory [ 294.276806] systemd-udevd[4354]: Failed to apply ACL on /dev/snd/midiC3D0: No such file or directory
So the call that must be failing is:
err = snd_card_register(chip->card);
and of course this all works with the quirks table modified for the ur44. I'm at a loss. Any further debugging suggestions would be greatly appreciated.
thanks,
Cyrus
Regards, Clemens --- a/sound/core/pcm.c +++ b/sound/core/pcm.c @@ -1086,6 +1086,7 @@ static int snd_pcm_dev_register(struct snd_device *device) mutex_lock(®ister_mutex); err = snd_pcm_add(pcm); if (err) { + printk(KERN_ERR "snd_pcm_add(%d) failed\n", pcm->device); mutex_unlock(®ister_mutex); return err; } @@ -1115,6 +1116,7 @@ static int snd_pcm_dev_register(struct snd_device *device) &snd_pcm_f_ops[cidx], pcm, str, dev); if (err < 0) { + dev_err(dev, "snd_register_device_for_dev failed: %d\n", err); list_del(&pcm->list); mutex_unlock(®ister_mutex); return err;
On a somewhat related note, is there a way to apply changes to things in, say, sound/usb and compile/install those changes without a few kernel rebuild/install? Or, even better, without a reboot? Would certainly shorting the debug cycle time for me. In this case I'm interested in finding out what quirk->type is when it gets to snd_usb_create_quirk as it looks like the function in the quirk_funcs table that gets called here produces the first suspect error. Adding a dev_info, followed by a kernel rebuild, reinstall, reboot (and the fact that my broken nvidia drivers require reinstalling the video driver every time I install a new kernel) makes for a tedious process!
thanks!
Cyrus
On 11/05/2014 01:17 PM, Clemens Ladisch wrote:
Cyrus Harmon wrote:
[ 2.964094] snd-usb-audio 3-3.2:1.0: checking PCM interface [ 2.964104] snd-usb-audio: probe of 3-3.2:1.0 failed with error -5 [ 2.966339] snd-usb-audio 3-3.2:1.1: checking PCM interface [ 2.966341] snd-usb-audio 3-3.2:1.1: altsets found [ 2.966342] snd-usb-audio 3-3.2:1.1: endpoint found [ 2.966343] snd-usb-audio 3-3.2:1.1: iso found [ 2.966344] snd-usb-audio 3-3.2:1.1: descriptors found [ 2.968544] usb 3-3.2:1.0: checking PCM interface [ 2.968546] usb 3-3.2:1.2: checking PCM interface [ 2.968547] usb 3-3.2:1.2: altsets found [ 2.968547] usb 3-3.2:1.2: endpoint found [ 2.968548] usb 3-3.2:1.2: iso found [ 2.968549] usb 3-3.2:1.2: descriptors found [ 2.970657] usb 3-3.2:1.3: checking PCM interface [ 2.970666] usb 3-3.2:1.4: checking PCM interface [ 2.970930] snd-usb-audio: probe of 3-3.2:1.1 failed with error -5
Strange; in theory, this cannot happen.
Please add this patch and try again.
Regards, Clemens
--- a/sound/usb/card.c +++ b/sound/usb/card.c @@ -536,7 +536,9 @@ snd_usb_audio_probe(struct usb_device *dev, err = 1; /* continue */ if (quirk && quirk->ifnum != QUIRK_NO_INTERFACE) { /* need some special handlings */
if ((err = snd_usb_create_quirk(chip, intf, &usb_audio_driver, quirk)) < 0)
err = snd_usb_create_quirk(chip, intf, &usb_audio_driver, quirk);dev_info(&intf->dev, "quirk return code: %d\n", err);if (err < 0) goto __error;@@ -547,11 +549,13 @@ snd_usb_audio_probe(struct usb_device *dev, goto __error; } }
dev_info(&intf->dev, "probe step 2\n");
/* we are allowed to call snd_card_register() many times */ if (snd_card_register(chip->card) < 0) { goto __error; }
dev_info(&intf->dev, "probe step 3\n");
usb_chip[chip->index] = chip; chip->num_interfaces++;
@@ -560,6 +564,7 @@ snd_usb_audio_probe(struct usb_device *dev, return chip;
__error:
- dev_info(&intf->dev, "probe failed\n"); if (chip) { if (!chip->num_interfaces) snd_card_free(chip->card);
--- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -367,6 +367,7 @@ static int create_autodetect_quirks(struct snd_usb_audio *chip, err = create_autodetect_quirk(chip, iface, driver); if (err < 0) return err;
dev_info(&iface->dev, "first interface successful\n");
/*
- ALSA PCM playback/capture devices cannot be registered in two steps,
@@ -385,9 +386,13 @@ static int create_autodetect_quirks(struct snd_usb_audio *chip,
err = create_autodetect_quirk(chip, iface, driver); if (err >= 0)
{ usb_driver_claim_interface(driver, iface, (void *)-1L);dev_info(&iface->dev, "interface %d successful\n", ifnum);}}
dev_info(&iface->dev, "create_autodetect_quirks successful\n"); return 0; }
At Thu, 06 Nov 2014 08:05:43 -0800, Cyrus Harmon wrote:
On a somewhat related note, is there a way to apply changes to things in, say, sound/usb and compile/install those changes without a few kernel rebuild/install? Or, even better, without a reboot? Would certainly shorting the debug cycle time for me. In this case I'm interested in finding out what quirk->type is when it gets to snd_usb_create_quirk as it looks like the function in the quirk_funcs table that gets called here produces the first suspect error. Adding a dev_info, followed by a kernel rebuild, reinstall, reboot (and the fact that my broken nvidia drivers require reinstalling the video driver every time I install a new kernel) makes for a tedious process!
It's a standard procedure, something like...
% mkdir /somewhere % cd /somewhere % cp -a /there/linux/sound . % patch -p1 < your-usb.patch % make -C /lib/modules/`uname -r`/build M=$PWD/sound/usb % su # make -C /lib/modules/`uname -r`/build M=$PWD/sound/usb modules_install # modprobe -r snd-usb-audio # modprobe snd-usb-audio
Takashi
That's what I was looking for!
Thanks!
On 11/06/2014 08:49 AM, Takashi Iwai wrote:
At Thu, 06 Nov 2014 08:05:43 -0800, Cyrus Harmon wrote:
On a somewhat related note, is there a way to apply changes to things in, say, sound/usb and compile/install those changes without a few kernel rebuild/install? Or, even better, without a reboot? Would certainly shorting the debug cycle time for me. In this case I'm interested in finding out what quirk->type is when it gets to snd_usb_create_quirk as it looks like the function in the quirk_funcs table that gets called here produces the first suspect error. Adding a dev_info, followed by a kernel rebuild, reinstall, reboot (and the fact that my broken nvidia drivers require reinstalling the video driver every time I install a new kernel) makes for a tedious process!
It's a standard procedure, something like...
% mkdir /somewhere % cd /somewhere % cp -a /there/linux/sound . % patch -p1 < your-usb.patch % make -C /lib/modules/`uname -r`/build M=$PWD/sound/usb % su # make -C /lib/modules/`uname -r`/build M=$PWD/sound/usb modules_install # modprobe -r snd-usb-audio # modprobe snd-usb-audio
Takashi
Cyrus,
There's an automated patcher for the UR22 on Ubuntu @ Steinberg forums - maybe you can adapt it for your purposes.
http://pastebin.com/awiG30Eh http://www.steinberg.net/forums/viewtopic.php?t=62290
~Vlad
On Thu, 2014-11-06 at 08:54 -0800, Cyrus Harmon wrote:
That's what I was looking for!
Thanks!
On 11/06/2014 08:49 AM, Takashi Iwai wrote:
At Thu, 06 Nov 2014 08:05:43 -0800, Cyrus Harmon wrote:
On a somewhat related note, is there a way to apply changes to things in, say, sound/usb and compile/install those changes without a few kernel rebuild/install? Or, even better, without a reboot? Would certainly shorting the debug cycle time for me. In this case I'm interested in finding out what quirk->type is when it gets to snd_usb_create_quirk as it looks like the function in the quirk_funcs table that gets called here produces the first suspect error. Adding a dev_info, followed by a kernel rebuild, reinstall, reboot (and the fact that my broken nvidia drivers require reinstalling the video driver every time I install a new kernel) makes for a tedious process!
It's a standard procedure, something like...
% mkdir /somewhere % cd /somewhere % cp -a /there/linux/sound . % patch -p1 < your-usb.patch % make -C /lib/modules/`uname -r`/build M=$PWD/sound/usb % su # make -C /lib/modules/`uname -r`/build M=$PWD/sound/usb modules_install # modprobe -r snd-usb-audio # modprobe snd-usb-audio
Takashi
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Cyrus,
There's an automated patcher for the UR22 on Ubuntu @ Steinberg forums - maybe you can adapt it for your purposes.
http://pastebin.com/awiG30Eh http://www.steinberg.net/forums/viewtopic.php?t=62290
~Vlad
On Thu, 2014-11-06 at 08:54 -0800, Cyrus Harmon wrote:
That's what I was looking for!
Thanks!
On 11/06/2014 08:49 AM, Takashi Iwai wrote:
At Thu, 06 Nov 2014 08:05:43 -0800, Cyrus Harmon wrote:
On a somewhat related note, is there a way to apply changes to things in, say, sound/usb and compile/install those changes without a few kernel rebuild/install? Or, even better, without a reboot? Would certainly shorting the debug cycle time for me. In this case I'm interested in finding out what quirk->type is when it gets to snd_usb_create_quirk as it looks like the function in the quirk_funcs table that gets called here produces the first suspect error. Adding a dev_info, followed by a kernel rebuild, reinstall, reboot (and the fact that my broken nvidia drivers require reinstalling the video driver every time I install a new kernel) makes for a tedious process!
It's a standard procedure, something like...
% mkdir /somewhere % cd /somewhere % cp -a /there/linux/sound . % patch -p1 < your-usb.patch % make -C /lib/modules/`uname -r`/build M=$PWD/sound/usb % su # make -C /lib/modules/`uname -r`/build M=$PWD/sound/usb modules_install # modprobe -r snd-usb-audio # modprobe snd-usb-audio
Takashi
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Dear Takashi,
Sorry for the delay in getting back to this. Your instructions seem close, but I've run into the following issues:
1. the module is installed in /lib/modules/`uname -r`/extra instead of kernel/sound/usb
2. I can get around that with:
sudo insmod /lib/modules/`uname -r`/extra/snd-usbmidi-lib.ko sudo insmod /lib/modules/`uname -r`/extra/snd-usb-audio.ko
but there's probably a better way.
3. I can't do the same tricks with snd-pcm as I get the following error:
sly@madbox:/lib/modules/3.19.0-rc7-local$ sudo modprobe -r snd-pcm modprobe: FATAL: Module snd_pcm is in use.
Is there a way to disable snd_pcm and reload the module? Barring that, I at least want to be able to install the new snd_pcm and reboot, without having to rebuild the whole kernel, so solving problem 1 would presumably help for that.
Thanks for your help!
Cyrus
On 11/06/2014 08:49 AM, Takashi Iwai wrote:
At Thu, 06 Nov 2014 08:05:43 -0800 Cyrus Harmon wrote:
On a somewhat related note, is there a way to apply changes to things in, say, sound/usb and compile/install those changes without a few kernel rebuild/install? Or, even better, without a reboot? Would certainly shorting the debug cycle time for me. In this case I'm interested in finding out what quirk->type is when it gets to snd_usb_create_quirk as it looks like the function in the quirk_funcs table that gets called here produces the first suspect error. Adding a dev_info, followed by a kernel rebuild, reinstall, reboot (and the fact that my broken nvidia drivers require reinstalling the video driver every time I install a new kernel) makes for a tedious process!
It's a standard procedure, something like... % mkdir /somewhere % cd /somewhere % cp -a /there/linux/sound . % patch -p1 < your-usb.patch % make -C /lib/modules/`uname -r`/build M=$PWD/sound/usb % su # make -C /lib/modules/`uname -r`/build M=$PWD/sound/usb modules_install # modprobe -r snd-usb-audio # modprobe snd-usb-audio Takashi
At Mon, 2 Feb 2015 22:56:31 -0800, Cyrus Harmon wrote:
Dear Takashi,
Sorry for the delay in getting back to this. Your instructions seem close, but I've run into the following issues:
- the module is installed in /lib/modules/`uname -r`/extra instead of
kernel/sound/usb
- I can get around that with:
sudo insmod /lib/modules/`uname -r`/extra/snd-usbmidi-lib.ko sudo insmod /lib/modules/`uname -r`/extra/snd-usb-audio.ko
but there's probably a better way.
modprobe will load from extra directory before others automatically.
- I can't do the same tricks with snd-pcm as I get the following error:
sly@madbox:/lib/modules/3.19.0-rc7-local$ sudo modprobe -r snd-pcm modprobe: FATAL: Module snd_pcm is in use.
Is there a way to disable snd_pcm and reload the module?
Unload the module referring to snd-pcm, in your case, snd-usb-audio at first.
Takashi
Barring that, I at least want to be able to install the new snd_pcm and reboot, without having to rebuild the whole kernel, so solving problem 1 would presumably help for that.
Thanks for your help!
Cyrus
On 11/06/2014 08:49 AM, Takashi Iwai wrote:
At Thu, 06 Nov 2014 08:05:43 -0800 Cyrus Harmon wrote:
On a somewhat related note, is there a way to apply changes to things in, say, sound/usb and compile/install those changes without a few kernel rebuild/install? Or, even better, without a reboot? Would certainly shorting the debug cycle time for me. In this case I'm interested in finding out what quirk->type is when it gets to snd_usb_create_quirk as it looks like the function in the quirk_funcs table that gets called here produces the first suspect error. Adding a dev_info, followed by a kernel rebuild, reinstall, reboot (and the fact that my broken nvidia drivers require reinstalling the video driver every time I install a new kernel) makes for a tedious process!
It's a standard procedure, something like... % mkdir /somewhere % cd /somewhere % cp -a /there/linux/sound . % patch -p1 < your-usb.patch % make -C /lib/modules/`uname -r`/build M=$PWD/sound/usb % su # make -C /lib/modules/`uname -r`/build M=$PWD/sound/usb modules_install # modprobe -r snd-usb-audio # modprobe snd-usb-audio Takashi
Cyrus Harmon wrote:
I'm interested in finding out what quirk->type is when it gets to snd_usb_create_quirk as it looks like the function in the quirk_funcs table that gets called here produces the first suspect error.
[ 2.964094] snd-usb-audio 3-3.2:1.0: checking PCM interface [ 2.964104] snd-usb-audio: probe of 3-3.2:1.0 failed with error -5
The first error is harmless (the control interface is not a PCM interface).
... [ 2.970930] snd-usb-audio: probe of 3-3.2:1.1 failed with error -5
The second error happens during snd_card_register(). In other words, there's probably something about the PCM device that makes snd_pcm_dev_register() unhappy.
Regards, Clemens
-
Clemens Ladisch -
Cyrus Harmon -
Takashi Iwai -
Vlad Catoi -
Vlad Catoi