Fwd: Support for Roland VG-99 (working code, but could use help)

Fwd: Support for Roland VG-99 (working code, but could use help)

[Pete Leigh]

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
                        }
                }
        }
},

Re: Fwd: Support for Roland VG-99 (working code, but could use help)

[Daniel Mack]

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

Re: Fwd: Support for Roland VG-99 (working code, but could use help)

[Pete Leigh]

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.

Re: Fwd: Support for Roland VG-99 (working code, but could use help)

[Daniel Mack]

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

Re: Fwd: Support for Roland VG-99 (working code, but could use help)

[Pete Leigh]

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.

Re: Fwd: Support for Roland VG-99 (working code, but could use help)

[Daniel Mack]

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

Re: Fwd: Support for Roland VG-99 (working code, but could use help)

[Pete Leigh]

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.

Re: Fwd: Support for Roland VG-99 (working code, but could use help)

[Daniel Mack]

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

Re: Fwd: Support for Roland VG-99 (working code, but could use help)

[Pete Leigh]

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.

Re: Fwd: Support for Roland VG-99 (working code, but could use help)

[Pete Leigh]

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.

Re: Fwd: Support for Roland VG-99 (working code, but could use help)

[Daniel Mack]

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

Re: Fwd: Support for Roland VG-99 (working code, but could use help)

[Pete Leigh]

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.

Re: Fwd: Support for Roland VG-99 (working code, but could use help)

[Daniel Mack]

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

Re: Fwd: Support for Roland VG-99 (working code, but could use help)

[Pete Leigh]

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

Re: Fwd: Support for Roland VG-99 (working code, but could use help)

[Pete Leigh]

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

Re: Fwd: Support for Roland VG-99 (working code, but could use help)

[Pete Leigh]

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.

Re: Fwd: Support for Roland VG-99 (working code, but could use help)

[Clemens Ladisch]

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

Re: Fwd: Support for Roland VG-99 (working code, but could use help)

[Pete Leigh]

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

Re: Fwd: Support for Roland VG-99 (working code, but could use help)

[Clemens Ladisch]

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