[alsa-devel] Fwd: Support for Roland VG-99 (working code, but could use help)
Hi,
I tried posting this a couple of days ago, but no response... I'm wondering if the (text) attachment stopped people from seeing it, or if there's something else I missed?
It's just a request to look over the lsusb output and new quirks-table entry included, with a view to getting this added to a release.
Since the initial post, I've done more testing (I'm using a kernel based on 3.4.11-1.rt19.1.fc17.ccrma.x86_64.rt) and everything seems to work fine (including midi in, which I wasn't sure of at the time of posting) apart from one apparently cosmetic issue - the device name no longer shows up in lsusb output, though it did before applying the quirk. (?)
I'll include the quirk entry as text rather than an attachment this time.
If I actually need to go through the process of generating a patch and sending mail via git, as per the developer page on the alsa-project site, could someone let me know, and I'll give it a go (it's something I was hoping to avoid, I admit!)
Thanks,
- Pete.
---------- Forwarded message ----------
The VG-99 is a guitar processor with a usb interface which offers 2x16bit 44100 pcm in and out streams in its basic usb mode, and 2x24bit 44100 in/out + midi in the advanced mode connection mode.
Basic mode works fine with usb snd driver, but the device isn't recognised when set to advanced mode (this is done under USB on page 2 of the "system" config menu)
I've used the lsusb -v output (below) to guess at an addition to sound/usb/quirks-table.h to try and get this working. On initial (brief) testing, audio in/out at 24bits (as shown by jackd output) and midi (out, at least) are all working.
I'll attach the quirk, and would be pleased if someone could look at it, and the lsusb output, and fix up any deficiencies (it's purely voodoo here :-D) and maybe get it or something like it into the official source... please let me know if changes need to be tested.
Cheers,
- Pete.
Here's the lsusb output:
Bus 001 Device 007: ID 0582:00b2 Roland Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 8 idVendor 0x0582 Roland Corp. idProduct 0x00b2 bcdDevice 1.00 iManufacturer 1 Roland iProduct 2 VG-99 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 167 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 06 24 f1 01 00 00 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 03 18 01 44 ac 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 9 Transfer Type Isochronous Synch Type Adaptive Usage Type Data wMaxPacketSize 0x0120 1x 288 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 ** UNRECOGNIZED: 07 24 01 07 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 03 18 01 44 ac 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0120 1x 288 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 06 24 f1 02 02 02 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 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 0x0020 1x 32 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 1 Device Status: 0x0001 Self Powered
------------------------------------
And the quirk entry:
{ USB_DEVICE(0x0582, 0x00b2), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { .vendor_name = "Roland", .product_name = "VG-99", .ifnum = QUIRK_ANY_INTERFACE, .type = QUIRK_COMPOSITE, .data = (const struct snd_usb_audio_quirk[]) { { .ifnum = 0, .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = & (const struct audioformat) { .formats = SNDRV_PCM_FMTBIT_S24_3LE, .channels = 2, .iface = 0, .altsetting = 1, .altset_idx = 1, .attributes = 0, .endpoint = 0x01, .ep_attr = 0x09, .rates = SNDRV_PCM_RATE_CONTINUOUS, .rate_min = 44100, .rate_max = 44100, } }, { .ifnum = 1, .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = & (const struct audioformat) { .formats = SNDRV_PCM_FMTBIT_S24_3LE, .channels = 2, .iface = 1, .altsetting = 1, .altset_idx = 1, .attributes = UAC_EP_CS_ATTR_FILL_MAX, .endpoint = 0x82, .ep_attr = 0x05, .rates = SNDRV_PCM_RATE_CONTINUOUS, .rate_min = 44100, .rate_max = 44100, } }, { .ifnum = 2, .type = QUIRK_MIDI_FIXED_ENDPOINT, .data = & (const struct snd_usb_midi_endpoint_info) { .out_cables = 0x0007, .in_cables = 0x0007 } }, { .ifnum = -1 } } } },
Hi Pete,
On 16.10.2012 01:59, Pete Leigh wrote:
I tried posting this a couple of days ago, but no response... I'm wondering if the (text) attachment stopped people from seeing it, or if there's something else I missed?
It's probably rather that people are too busy to respond :)
It's just a request to look over the lsusb output and new quirks-table entry included, with a view to getting this added to a release.
Since the initial post, I've done more testing (I'm using a kernel based on 3.4.11-1.rt19.1.fc17.ccrma.x86_64.rt) and everything seems to work fine (including midi in, which I wasn't sure of at the time of posting)
Ok, well done :) But are you sure 44100 is the only supported sample rate?
apart from one apparently cosmetic issue - the device name no longer shows up in lsusb output, though it did before applying the quirk. (?)
lsusb -v should still show it. For the normal output, you could submit an entry here: http://www.linux-usb.org/usb-ids.html
I'll include the quirk entry as text rather than an attachment this time.
If I actually need to go through the process of generating a patch and sending mail via git, as per the developer page on the alsa-project site, could someone let me know, and I'll give it a go (it's something I was hoping to avoid, I admit!)
Yes, in order to prepare a proper patch, you'll have to do that please. Check out the latestes sound.git[*] and make sure your patch applies there. Also note that the entries in this file are sorted by VID/PID.
If you want to avoid that by all means, I can do it for you, but I can't test it of course.
Thanks for pushing your work back to mainline!
Daniel
Hi Daniel, thanks for taking the time..
On 16 October 2012 08:40, Daniel M
are you sure 44100 is the only supported sample rate?
Yep, the manual is pretty clear about that. Also, http://www.rolandus.com/products/details/849 in the "specs" section.
the device name no longer shows up in lsusb output [...]
lsusb -v should still show it
Hmm... and now it's there! I guess I must have missed it.
For the normal output, you could submit an entry here: http://www.linux-usb.org/usb-ids.html
Right! I've just done that - the id comes up differently for the two "driver modes", so I put both in.
Check out the latestes sound.git[*] and make sure your patch applies there. Also note that the entries in this file are sorted by VID/PID.
Ok, I'll give this a shot.. Does the quirk definition look sane? Is it worth showing the lsusb -v output with that patch in place (would you expect that to look any different... it still has the "unrecognized" parts)?
Cheers,
- Pete.
On 16.10.2012 10:31, Pete Leigh wrote:
Hi Daniel, thanks for taking the time..
On 16 October 2012 08:40, Daniel M
are you sure 44100 is the only supported sample rate?
Yep, the manual is pretty clear about that. Also, http://www.rolandus.com/products/details/849 in the "specs" section.
Ok then.
the device name no longer shows up in lsusb output [...]
lsusb -v should still show it
Hmm... and now it's there! I guess I must have missed it.
For the normal output, you could submit an entry here: http://www.linux-usb.org/usb-ids.html
Right! I've just done that - the id comes up differently for the two "driver modes", so I put both in.
Check out the latestes sound.git[*] and make sure your patch applies there. Also note that the entries in this file are sorted by VID/PID.
Ok, I'll give this a shot.. Does the quirk definition look sane?
Yes. Note that there are several coding style rules to obey in the kernel (most importantly in your case: tabs are used for indentation). See Documentation/CodingStyle and run scripts/checkpatch.pl on the patch before submitting.
And I missed the annotation in the previous mail, so here it is:
[*] git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
Is it worth showing the lsusb -v output with that patch in place (would you expect that to look any different... it still has the "unrecognized" parts)?
No.
Thanks, Daniel
Hi Daniel,
On 16 October 2012 09:36, Daniel Mack zonque@gmail.com wrote:
Check out the latestes sound.git[*] and make sure your patch applies there.
And I missed the annotation in the previous mail, so here it is:
[*] git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
I've got this kernel (sound.git) booting now, but I find that USB audio isn't working before I touch it.
When I connect my (known working) UA-25, this happens:
[ 248.815369] usb 1-1.6: new full-speed USB device number 6 using ehci_hcd [ 248.913064] usb 1-1.6: New USB device found, idVendor=0582, idProduct=0074 [ 248.913068] usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 248.913071] usb 1-1.6: Product: EDIROL UA-25 [ 248.913074] usb 1-1.6: Manufacturer: Roland mtp-probe: checking bus 1, device 6: "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6" mtp-probe: bus: 1, device: 6 was not an MTP device [ 249.073737] cannot submit urb 0, error -28: not enough bandwidth
Any subsequent attempts to send audio to it result in a single "urb 0 error -28" message
I googled this a bit, and saw that there had been a problem looking like this with USB full speed devices on ehci controllers, which does apply here.
Do you think that's what's biting me?
Cheers,
- Pete.
On 19.10.2012 01:38, Pete Leigh wrote:
Hi Daniel,
On 16 October 2012 09:36, Daniel Mack zonque@gmail.com wrote:
Check out the latestes sound.git[*] and make sure your patch applies there.
And I missed the annotation in the previous mail, so here it is:
[*] git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
I've got this kernel (sound.git) booting now, but I find that USB audio isn't working before I touch it.
When I connect my (known working) UA-25, this happens:
[ 248.815369] usb 1-1.6: new full-speed USB device number 6 using ehci_hcd [ 248.913064] usb 1-1.6: New USB device found, idVendor=0582, idProduct=0074 [ 248.913068] usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 248.913071] usb 1-1.6: Product: EDIROL UA-25 [ 248.913074] usb 1-1.6: Manufacturer: Roland mtp-probe: checking bus 1, device 6: "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6" mtp-probe: bus: 1, device: 6 was not an MTP device [ 249.073737] cannot submit urb 0, error -28: not enough bandwidth
Ok, I have to fix this finally. Are you using a hub or is this device directly connected?
Daniel
On 19 October 2012 08:45, Daniel Mack zonque@gmail.com wrote:
[ 248.815369] usb 1-1.6: new full-speed USB device number 6 using ehci_hcd
[...]]
[ 249.073737] cannot submit urb 0, error -28: not enough bandwidth
Ok, I have to fix this finally. Are you using a hub or is this device directly connected?
Directly connected, I assume to this (from lspci)
:14.0 USB Controller: Intel Corporation Panther Point USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI]) Subsystem: Hewlett-Packard Company Device 179b Flags: bus master, medium devsel, latency 0, IRQ 46 Memory at d4420000 (64-bit, non-prefetchable) [size=64K] Capabilities: [70] Power Management version 2 Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+ Kernel driver in use: xhci_hcd
That is reported by the distro kernel.. I notice it is using an xhci driver, which I think is not enabled in the sound.git kernel I booted. I'll try again after enabling CONFIG_USB_XHCI_HCD, in case that helps.
Cheers,
- Pete.
On 19.10.2012 10:23, Pete Leigh wrote:
On 19 October 2012 08:45, Daniel Mack zonque@gmail.com wrote:
[ 248.815369] usb 1-1.6: new full-speed USB device number 6 using ehci_hcd
[...]]
[ 249.073737] cannot submit urb 0, error -28: not enough bandwidth
Ok, I have to fix this finally. Are you using a hub or is this device directly connected?
Directly connected, I assume to this (from lspci)
:14.0 USB Controller: Intel Corporation Panther Point USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI]) Subsystem: Hewlett-Packard Company Device 179b Flags: bus master, medium devsel, latency 0, IRQ 46 Memory at d4420000 (64-bit, non-prefetchable) [size=64K] Capabilities: [70] Power Management version 2 Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+ Kernel driver in use: xhci_hcd
That is reported by the distro kernel.. I notice it is using an xhci driver, which I think is not enabled in the sound.git kernel I booted. I'll try again after enabling CONFIG_USB_XHCI_HCD, in case that helps.
Yes. You should extract the config of the old kernel (/proc/config.gz) and use this as start for building the upstream.
Daniel
On 19 October 2012 09:24, Daniel Mack zonque@gmail.com wrote:
On 19.10.2012 10:23, Pete Leigh wrote:
On 19 October 2012 08:45, Daniel Mack zonque@gmail.com wrote:
[ 248.815369] usb 1-1.6: new full-speed USB device number 6 using ehci_hcd
[...]]
[ 249.073737] cannot submit urb 0, error -28: not enough bandwidth
Ok, I have to fix this finally. Are you using a hub or is this device directly connected?
Directly connected, I assume to this (from lspci)
:14.0 USB Controller: Intel Corporation Panther Point USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI]) Subsystem: Hewlett-Packard Company Device 179b Flags: bus master, medium devsel, latency 0, IRQ 46 Memory at d4420000 (64-bit, non-prefetchable) [size=64K] Capabilities: [70] Power Management version 2 Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+ Kernel driver in use: xhci_hcd
That is reported by the distro kernel.. I notice it is using an xhci driver, which I think is not enabled in the sound.git kernel I booted. I'll try again after enabling CONFIG_USB_XHCI_HCD, in case that helps.
Yes. You should extract the config of the old kernel (/proc/config.gz) and use this as start for building the upstream.
No dice with xchi enabled. In any case, when I look properly, there's 3 entries in the lspci output for the host controller - one xhci and two ehci.
The ehci ones (reported under sound.git) are:
00:1a.0 USB Controller: Intel Corporation Panther Point USB Enhanced Host Contro ller #2 (rev 04) (prog-if 20 [EHCI]) Subsystem: Hewlett-Packard Company Device 179b Flags: bus master, medium devsel, latency 0, IRQ 16 Memory at d4439000 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port: BAR=1 offset=00a0 Capabilities: [98] PCI Advanced Features Kernel driver in use: ehci_hcd
00:1d.0 USB Controller: Intel Corporation Panther Point USB Enhanced Host Controller #1 (rev 04) (prog-if 20 [EHCI]) Subsystem: Hewlett-Packard Company Device 179b Flags: bus master, medium devsel, latency 0, IRQ 16 Memory at d4438000 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port: BAR=1 offset=00a0 Capabilities: [98] PCI Advanced Features Kernel driver in use: ehci_hcd
It also shows the xhci one, now, too.
There's no change to the behaviour when connecting the UA-25 - still shows "using ehci", which looks like what the distro kernel reports too.
I'll try re-doing the kernel based off config.gz from the distro kernel, as you suggest, probably this evening. What I'd actually done was make defconfig, make localmodconfig and make menuconfig (enabling a few things necessary to boot, and making the sound drivers be modules)
If this problem is confined to the usb subsystem, it seems unlikely I broke anything with my config operations, but I'm no expert certainly.
Cheers,
- Pete.
On 19 October 2012 09:49, Pete Leigh pete.leigh@gmail.com wrote:
On 19 October 2012 09:24, Daniel Mack zonque@gmail.com wrote:
You should extract the config of the old kernel (/proc/config.gz) and use this as start for building the upstream.
I'll try re-doing the kernel based off config.gz from the distro kernel, as you suggest,
[...]
If this problem is confined to the usb subsystem, it seems unlikely I broke anything with my config operations, but I'm no expert certainly.
Perhaps predictably after saying this, I find that using /boot/config-3.5.4-1.fc17.x86_64 as .config, then make localmodconfig and make menuconfig to turn off loads of network device drivers and such that would take hours to compile, usb audio is working on the sound.git kernel :-/
I quickly tested the VG-99 quirk (modified as per Clemens' suggestion) and that works too, so I'll work on generating a patch as per the instructions on alsa-project.org.
If it's any use regarding the urb 0 -ENOSPACE error I was having, I can try and track down the config item difference that makes it work, or provide the config files for you to look at.. Please let me know if this would be useful.
Should there be some dependency in the configs so that whatever item is making the difference is enabled by selecting SND_USB_AUDIO ?
Thanks for the pointers :)
Cheers,
- Pete.
On 19.10.2012 19:02, Pete Leigh wrote:
On 19 October 2012 09:49, Pete Leigh pete.leigh@gmail.com wrote:
On 19 October 2012 09:24, Daniel Mack zonque@gmail.com wrote:
You should extract the config of the old kernel (/proc/config.gz) and use this as start for building the upstream.
I'll try re-doing the kernel based off config.gz from the distro kernel, as you suggest,
[...]
If this problem is confined to the usb subsystem, it seems unlikely I broke anything with my config operations, but I'm no expert certainly.
Perhaps predictably after saying this, I find that using /boot/config-3.5.4-1.fc17.x86_64 as .config, then make localmodconfig and make menuconfig to turn off loads of network device drivers and such that would take hours to compile, usb audio is working on the sound.git kernel :-/
Ok, great.
I quickly tested the VG-99 quirk (modified as per Clemens' suggestion) and that works too, so I'll work on generating a patch as per the instructions on alsa-project.org.
If it's any use regarding the urb 0 -ENOSPACE error I was having, I can try and track down the config item difference that makes it work, or provide the config files for you to look at.. Please let me know if this would be useful.
Absolutely, that would be great. We keep getting reports from users that see this since the driver was reworked, and I still haven't got my head around what really causes it. And none of my machines show the error yet, so it's really hard to track. If you would point me to any specific config option that reproducibly changes the behaviour, that would be of great help.
Should there be some dependency in the configs so that whatever item is making the difference is enabled by selecting SND_USB_AUDIO ?
No, it's really just a bug that must be fixed.
Thanks, Daniel
Hi Daniel
On 19 October 2012 18:46, Daniel Mack zonque@gmail.com wrote:
On 19.10.2012 19:02, Pete Leigh wrote:
I quickly tested the VG-99 quirk (modified as per Clemens' suggestion) and that works too, so I'll work on generating a patch as per the instructions on alsa-project.org.
Actually, I'm struggling a bit with this. I'm guessing (alsa-project.org doesn't seem to say...) that you need to check out the release branch in alsa-driver to work on, and do your commit against that (master branch contains only a README) but the wiki also advises to do a rebase origin/master after your commit. It seemed weird, but I tried it, to no useful effect of course.
As a relative novice, this is pretty confusing stuff. Is there a plain step-by-step of the procedure to generate a patch? Would it be acceptable to send the patch against the sound.git tree?
If it's any use regarding the urb 0 -ENOSPACE error I was having, I can try and track down the config item difference that makes it work, or provide the config files for you to look at.. Please let me know if this would be useful.
Absolutely, that would be great. We keep getting reports from users that see this since the driver was reworked, and I still haven't got my head around what really causes it. And none of my machines show the error yet, so it's really hard to track. If you would point me to any specific config option that reproducibly changes the behaviour, that would be of great help.
Should there be some dependency in the configs so that whatever item is making the difference is enabled by selecting SND_USB_AUDIO ?
No, it's really just a bug that must be fixed.
Ok, I'll try narrowing down the config differences. It might take a while, though:
$ diff ~/3.7.working.config ~/broken.config | grep -v '#' | wc -l $ 1001
Cheers,
- Pete.
On 19.10.2012 20:18, Pete Leigh wrote:
On 19 October 2012 18:46, Daniel Mack zonque@gmail.com wrote:
On 19.10.2012 19:02, Pete Leigh wrote:
I quickly tested the VG-99 quirk (modified as per Clemens' suggestion) and that works too, so I'll work on generating a patch as per the instructions on alsa-project.org.
Actually, I'm struggling a bit with this. I'm guessing (alsa-project.org doesn't seem to say...) that you need to check out the release branch in alsa-driver to work on, and do your commit against that (master branch contains only a README) but the wiki also advises to do a rebase origin/master after your commit. It seemed weird, but I tried it, to no useful effect of course.
As a relative novice, this is pretty confusing stuff. Is there a plain step-by-step of the procedure to generate a patch? Would it be acceptable to send the patch against the sound.git tree?
Yes, sound.git is the reference, and your patch should apply cleanly on top of it.
Daniel
Hi Daniel,
On 19 October 2012 18:46, Daniel Mack zonque@gmail.com wrote:
On 19.10.2012 19:02, Pete Leigh wrote:
If it's any use regarding the urb 0 -ENOSPACE error I was having, I can try and track down the config item difference that makes it work,
If you would point me to any specific config option that reproducibly changes the behaviour, that would be of great help.
If I take the working config, and disable CONFIG_USB_EHCI_TT_NEWSCHED, recompile, make install, reboot, then I get the familiar "cannot submit urb 0, error -28: not enough bandwidth" error, and trying to record off the UA-25 in audacity freezes audacity. If I then re-enable it, recompile, make install, reboot, then I don't see the error, and recording off the UA-25 works normally in audacity.
This (as I guess you know) is the "Improved Transaction Translator scheduling" option under "Device Drivers" -> "USB Support" in menuconfig. The help text even mentions the -28 error, in fact, and suggests using this option in some circumstances.
Cheers,
- Pete
On 19 October 2012 23:24, Pete Leigh pete.leigh@gmail.com wrote:
If I take the working config, and disable CONFIG_USB_EHCI_TT_NEWSCHED, recompile, make install, reboot, then I get the familiar "cannot submit urb 0, error -28: not enough bandwidth" error, and trying to record off the UA-25 in audacity freezes audacity. If I then re-enable it, recompile, make install, reboot, then I don't see the error, and recording off the UA-25 works normally in audacity.
Just to add: I did also make modules_install in the above procedure, if you were wondering..
Also, if there's anything further I can do, in the way of testing patches, etc., please let me know.
Cheers,
- Pete
Hi,
On 19 October 2012 23:24, Pete Leigh pete.leigh@gmail.com wrote:
If I take the working config, and disable CONFIG_USB_EHCI_TT_NEWSCHED, recompile, make install, reboot, then I get the familiar "cannot submit urb 0, error -28: not enough bandwidth" error, and trying to record off the UA-25 in audacity freezes audacity. If I then re-enable it, recompile, make install, reboot, then I don't see the error, and recording off the UA-25 works normally in audacity.
Just a bit more info on how this is happening in ehci-sched.c (with the ...NEWSCHED config unset),
It is hitting the Q_TYPE_QH case in tt_no_collision().
In there, (mask & uf_mask) evaluates to true, and thus 0 is returned to sitd_slot_ok() which in turn returns 0 to iso_stream_schedule().
It goes around this loop 3 times before giving the -ENOSPC error in iso_stream_schedule().
I'm seeing this from some debug printks I inserted:
[ 52.135325] knowsnogap: mask was: 1124206081, uf_mask is: 61444, mask is now: 1128465927 [ 52.135328] returning 0 in tt_no_collision (4) frame: 0, ehci->periodic_size 1024, period 1 [ 52.135329] returning 0 in sitd slot ok [ 52.135330] knowsnogap: mask was: 1124206081, uf_mask is: 30722, mask is now: 1128465927 [ 52.135330] returning 0 in tt_no_collision (4) frame: 0, ehci->periodic_size 1024, period 1 [ 52.135331] returning 0 in sitd slot ok [ 52.135331] knowsnogap: mask was: 1124206081, uf_mask is: 15361, mask is now: 1128465927 [ 52.135332] returning 0 in tt_no_collision (4) frame: 0, ehci->periodic_size 1024, period 1 [ 52.135333] returning 0 in sitd slot ok [ 52.135334] no room: iso resched full ffff8802158b3300 (now 899 max 9091) [ 52.135336] ALSA sound/usb/endpoint.c:877 cannot submit urb 0, error -28: not enough bandwidth
The "knowsnogap" message is from just before the break; in the Q_TYPE_QH case, showing the value of uf_mask and mask before and after "mask |= mask >> 8" is done
(I would have put these in hex.. I thought they'd be small! :)
the "returning 0 in tt_no_collision" are printed just before the return 0, showing the values at that time.
Hope this is somehow useful..
Cheers,
- Pete.
Pete Leigh wrote:
Ok, I'll give this a shot.. Does the quirk definition look sane?
Please check if QUIRK_AUDIO_STANDARD_INTERFACE works. Are you sure there are three MIDI ports per direction, and not two?
Regards, Clemens
Hi Clemens, thanks for looking..
On 16 October 2012 10:19, Clemens Ladisch clemens@ladisch.de wrote:
Please check if QUIRK_AUDIO_STANDARD_INTERFACE works.
It does! :)
Are you sure there are three MIDI ports per direction, and not two?
No, that sounds wrong, in fact I didn't realise I'd set this. I guess the two ports would be one for sysex and one for normal messages? Two seems to fit with what lsusb shows
I've tested with .out_cables and .in_cables both set to 0x0011 (is that two?) and midi in and out continue to work..
Physically, there are two midi connectors, "IN" and "OUT".
Thanks again for the help..
- Pete.
Regards, Clemens
Pete Leigh wrote:
On 16 October 2012 10:19, Clemens Ladisch clemens@ladisch.de wrote:
Are you sure there are three MIDI ports per direction, and not two?
No, that sounds wrong, in fact I didn't realise I'd set this. I guess the two ports would be one for sysex and one for normal messages? Two seems to fit with what lsusb shows
I've tested with .out_cables and .in_cables both set to 0x0011 (is that two?)
These are bit masks; two ports would be 0x0003.
Regards, Clemens
participants (3)
-
Clemens Ladisch -
Daniel Mack -
Pete Leigh