Re: [Line6linux-devel] POD HD500x working

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi Hans Peter,

On Sat, Jun 10, 2017 at 5:05 AM, Hans Peter Möller <hm...@gm...> wrote:

>    I made the tests,
> - Removing LINE6_CAP_CONTROL disable playback in the unit, I can still
> capture but no sound come out of the unit. The "receive length failed (error
> -11)" disappear. Since Initialization is required for playback, the .ctrl_if
> is needed and thus the simple patch will only work in Kernel 4.9 and above.

I'm not sure it would be accepted into the maintenance branches
(<4.13) anyway, so that shouldn't matter. In the end .ctrl_if is not
needed for the <4.12 kernels anyhow (it's basically there just to lock
the USB device access for the kernel).

> -Removing LINE6_CAP_IN_NEEDS_OUT has no effect, so it's not needed.
>
> We still have the "receive length failed (error -11)" error, any other ideas
> of how to solve it? Or is not necessary?
>

Probably the init protocol is different then (no way to tell unless
you sniff some stuff from windows). You can check one last thing -
whether line6_read_serial_number() returns a reasonable value. Most
likely not, but...

I would say the best solution will be to add another flag, something
like LINE6_CAP_CONTROL_INIT - and adjust podhd_init() like:

-    if (!(pod->line6.properties->capabilities & LINE6_CAP_CONTROL)) {
+    if (!(pod->line6.properties->capabilities & LINE6_CAP_CONTROL_INIT)) {
        /* register USB audio system directly */
        return podhd_startup_finalize(pod);
    }

The flag would be only set for POD X3 for now...

> Just of curiosity, is there any difference in the usb_device_id
> podhd_id_table[] if I use
> { LINE6_DEVICE(0x4159), .driver_info = LINE6_PODHD500X },
> instead of:
> { LINE6_IF_NUM(0x4159, 0), .driver_info = LINE6_PODHD500X },
>
> The current table is:
> /* table of devices that work with this driver */
> static const struct usb_device_id podhd_id_table[] = {
>     /* TODO: no need to alloc data interfaces when only audio is used */
>     { LINE6_DEVICE(0x5057),    .driver_info = LINE6_PODHD300 },
>     { LINE6_DEVICE(0x5058),    .driver_info = LINE6_PODHD400 },
>     { LINE6_IF_NUM(0x414D, 0), .driver_info = LINE6_PODHD500_0 },
>     { LINE6_IF_NUM(0x414D, 1), .driver_info = LINE6_PODHD500_1 },
>     { LINE6_IF_NUM(0x414A, 0), .driver_info = LINE6_PODX3 },
>     { LINE6_IF_NUM(0x414B, 0), .driver_info = LINE6_PODX3LIVE },
>     { LINE6_IF_NUM(0x4159, 0), .driver_info = LINE6_PODHD500X },
>     {}
> };
>

This depends on how the device looks like. If there is only one USB
interface, LINE6_DEVICE should be sufficient. However, POD X3 has one
interface for audio (isochronous endpoints) and one for bulk
transfers, so it needs LINE6_IF_NUM() to match the right
device=interface (plus .ctrl_if for locking of the other one...).

-- 
Best regards,

Andrej

> On Fri, Jun 9, 2017 at 11:50 AM, Andrej Kruták <de...@an...> wrote:
>>
>> Ah yes, that one patch... I already forgot about it (and of course
>> didn't check the sources at the time of merge in 4.12 :)) Ok, but you
>> shouldn't need the ctrl_if thing if you only use the audio stuff.
>>
>> Regarding the maxpacket error, my prints the same - Line6 apparently
>> violates the USB specification (AFAIR bulk endpoints on HS USB 64 is
>> invalid maxsize (aka only valid for FullSpeed USB)...). In any case,
>> nothing to worry about...
>>
>>
>> --
>> Greetings,
>>
>> Andrej
>>
>>
>> On Fri, Jun 9, 2017 at 4:42 PM, Hans Peter Möller <hm...@gm...>
>> wrote:
>> > Hi,
>> >    I will thest droping those things and see what happened.
>> > What about the " config 1 interface 1 altsetting 0 bulk endpoint 0x1 has
>> > invalid maxpacket 64" ??? It has appear since the first time I plug my
>> > pod
>> > with the stock kernel 4.4.
>> >
>> > in your kernel 4.12 the if_ctrl doesn't appear? How did they implemented
>> > the
>> > x3 then?
>> >
>> > here is the podhd.c that come in my kernel
>> >
>> > https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/tree/sound/usb/line6/podhd.c?h=hwe-edge
>> > and this is the one from torvalds
>> > https://github.com/torvalds/linux/blob/master/sound/usb/line6/podhd.c
>> >
>> > both have the x3 implementation with the ctr_if (and mention you).
>> >
>> >
>> >
>> > On Fri, Jun 9, 2017 at 1:51 AM, Andrej Kruták <de...@an...> wrote:
>> >>
>> >> Hey,
>> >>
>> >> On Fri, Jun 9, 2017 at 5:35 AM, Hans Peter Möller <hm...@gm...>
>> >> wrote:
>> >> > Hi Andrej,
>> >> >    good news!!
>> >> > I can capture and listen from my pod.
>> >> >
>> >>
>> >> Perfect!
>> >>
>> >>
>> >> > I compare the lsusb from de x3 and I found that it has the same
>> >> > alternative
>> >> > setting issue than the hd500x, which is different from hd300 (I
>> >> > couldn't
>> >> > get
>> >> > one from h400 nor from h500). In x3 and 500x the altsetting is
>> >> > different
>> >> > for
>> >> > audio than for data.
>> >> > Since X3 is included in kernel 4.9, I decided to go over kernel 4.9
>> >> > and
>> >> > use
>> >> > that code which also appear to be more updated than the one here.
>> >> >
>> >> > In podhd.c I copy the same configuration used for X3. The .ctr_if=1
>> >> > is
>> >> > the
>> >> > difference from the others and it make the difference. This are the
>> >> > modifications I made:
>> >> >
>> >> > enum {
>> >> >     LINE6_PODHD300,
>> >> >     LINE6_PODHD400,
>> >> >     LINE6_PODHD500_0,
>> >> >     LINE6_PODHD500_1,
>> >> >     LINE6_PODX3,
>> >> >     LINE6_PODX3LIVE,
>> >> >     LINE6_PODHD500X
>> >> > };
>> >> >
>> >> > /* table of devices that work with this driver */
>> >> > static const struct usb_device_id podhd_id_table[] = {
>> >> >     /* TODO: no need to alloc data interfaces when only audio is used
>> >> > */
>> >> >     { LINE6_DEVICE(0x5057),    .driver_info = LINE6_PODHD300 },
>> >> >     { LINE6_DEVICE(0x5058),    .driver_info = LINE6_PODHD400 },
>> >> >     { LINE6_IF_NUM(0x414D, 0), .driver_info = LINE6_PODHD500_0 },
>> >> >     { LINE6_IF_NUM(0x414D, 1), .driver_info = LINE6_PODHD500_1 },
>> >> >     { LINE6_IF_NUM(0x414A, 0), .driver_info = LINE6_PODX3 },
>> >> >     { LINE6_IF_NUM(0x414B, 0), .driver_info = LINE6_PODX3LIVE },
>> >> >     { LINE6_IF_NUM(0x4159, 0), .driver_info = LINE6_PODHD500X },
>> >> >     {}
>> >> > };
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >     [LINE6_PODHD500X] = {
>> >> >         .id = "PODHD500X",
>> >> >         .name = "POD HD500x",
>> >> >         .capabilities    = LINE6_CAP_CONTROL
>> >> >                 | LINE6_CAP_PCM | LINE6_CAP_HWMON |
>> >> > LINE6_CAP_IN_NEEDS_OUT,
>> >> >         .altsetting = 1,
>> >> >         .ep_ctrl_r = 0x81,
>> >> >         .ep_ctrl_w = 0x01,
>> >> >         .ctrl_if = 1,
>> >> >         .ep_audio_r = 0x86,
>> >> >         .ep_audio_w = 0x02,
>> >> >     },
>> >> >
>> >> >
>> >> > I still get some errors/warning in dmesg, the maxpacket are the data
>> >> > ep
>> >> > so
>> >> > that is data. The "receive length failed (error -11)" don't know what
>> >> > it
>> >> > is,
>> >> > maybe initialization? Because it only appear this two times.
>> >> >
>> >> >  Here is dmesg output:
>> >> >
>> >> > [ 4001.944114] usb 1-3: new high-speed USB device number 11 using
>> >> > ehci-pci
>> >> > [ 4002.063668] usb 1-3: config 1 interface 1 altsetting 0 bulk
>> >> > endpoint
>> >> > 0x1
>> >> > has invalid maxpacket 64
>> >> > [ 4002.063677] usb 1-3: config 1 interface 1 altsetting 0 bulk
>> >> > endpoint
>> >> > 0x81
>> >> > has invalid maxpacket 64
>> >> > [ 4002.064779] usb 1-3: New USB device found, idVendor=0e41,
>> >> > idProduct=4159
>> >> > [ 4002.064785] usb 1-3: New USB device strings: Mfr=1, Product=2,
>> >> > SerialNumber=0
>> >> > [ 4002.064790] usb 1-3: Product: POD HD500X
>> >> > [ 4002.064794] usb 1-3: Manufacturer: Line 6
>> >> > [ 4002.067896] snd_usb_podhd 1-3:1.0: Line 6 POD HD500x found
>> >> > [ 4002.069846] snd_usb_podhd 1-3:1.0: Line 6 POD HD500x now attached
>> >> > [ 4002.577334] snd_usb_podhd 1-3:1.0: receive length failed (error
>> >> > -11)
>> >> > [ 4002.579660] snd_usb_podhd 1-3:1.0: receive length failed (error
>> >> > -11)
>> >> >
>> >>
>> >> I think this is caused by the device having different initial setup
>> >> requirements. But it also (most likely) means that it doesn't need any
>> >> setup. Thus drop the LIBE6_CAP_CONTROL thing, see if it still works.
>> >>
>> >> In addition, can you try also dropping LINE6_CAP_IN_NEEDS_OUT - and
>> >> check whether the stand-alone recording works?
>> >>
>> >> Lastly, I don't see any ctrl_if in the structure? Not in 4.0 ...
>> >> 4.12-rc kernels at least...
>> >>
>> >>
>> >> > I believe this should be added to the podhd.c delivered in the kernel
>> >> > but I
>> >> > dont know how to do that.
>> >> >
>> >>
>> >> Check linux/Documentation/process/submitting-patches.rst. In short -
>> >> just get inspired in the commit history of sound/usb/line6, create a
>> >> similar patch (git format-patch) and send it to alsa-devel
>> >> mailinglist.
>> >>
>> >> Alternatively, once you test the above, I can submit the patch on your
>> >> behalf too.
>> >>
>> >>
>> >> --
>> >> Best regards,
>> >>
>> >> Andrej
>> >
>> >
>
>