line6linux-devel — mailing list for developers of Line6 Linux software

[Line6linux-devel] Deprecated setup_timer on function line6_start_timer

[Olivier F. <oli...@gm...>]

Hi,
I am trying to compile the line6 driver onDebian 11 with Linux
5.10.0-18-amd64

>From linux 5.3 the setup_timer function is deprecated, i tried to replace
it with timer_setup without success.

Anybody have solved it ?

Olivier Fontes

Re: [Line6linux-devel] POD HD500x working

[Andrej K. <de...@an...>]

On Mon, Jun 12, 2017 at 4:33 PM, Hans Peter Möller <hm...@gm...> wrote:
> What do you mean with "release of workqueue" ?? The podhd_disconnect
> function?
>
> The other two (claim interface in and sysfs out) I think it might by solved
> with creating a new if in podhd_init funtion:
>
>
> static int podhd_init(struct usb_line6 *line6,
>               const struct usb_device_id *id)
> {
>     int err;
>     struct usb_line6_podhd *pod = (struct usb_line6_podhd *) line6;
>     struct usb_interface *intf;
>
>     line6->disconnect = podhd_disconnect;
>
>     if (pod->line6.properties->capabilities & LINE6_CAP_CONTROL) {
>         /* claim the data interface */
>         intf = usb_ifnum_to_if(line6->usbdev,
>                     pod->line6.properties->ctrl_if);
>         if (!intf) {
>             dev_err(pod->line6.ifcdev, "interface %d not found\n",
>                 pod->line6.properties->ctrl_if);
>             return -ENODEV;
>         }
>
>         err = usb_driver_claim_interface(&podhd_driver, intf, NULL);
>         if (err != 0) {
>             dev_err(pod->line6.ifcdev, "can't claim interface %d, error
> %d\n",
>                 pod->line6.properties->ctrl_if, err);
>             return err;
>         }
> +    }
>
> +    if (pod->line6.properties->capabilities & LINE6_CAP_CONTROL_INIT) {
>         /* create sysfs entries: */
>         err = snd_card_add_dev_attr(line6->card, &podhd_dev_attr_group);
>         if (err < 0)
>             return err;
>     }
>
>     if (pod->line6.properties->capabilities & LINE6_CAP_PCM) {
>         /* initialize PCM subsystem: */
>         err = line6_init_pcm(line6,
>             (id->driver_info == LINE6_PODX3 ||
>             id->driver_info == LINE6_PODX3LIVE) ? &podx3_pcm_properties :
>             &podhd_pcm_properties);
>         if (err < 0)
>             return err;
>     }
>
> -    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);
>     }
>
>     /* init device and delay registering */
>     init_timer(&pod->startup_timer);
>     INIT_WORK(&pod->startup_work, podhd_startup_workqueue);
>     podhd_startup(pod);
>     return 0;
> }
>
>
> That's what you where thinking? I haven't tested it, I will do as soon as I
> can.
>

Yup, exactly this (including the disconnect function). :-)


A.

> On Mon, Jun 12, 2017 at 1:46 AM, Andrej Kruták <de...@an...> wrote:
>>
>> Hi there,
>>
>> On Jun 12, 2017 12:30 AM, "Hans Peter Möller" <hm...@gm...> wrote:
>>
>> You were right, I forgot to test if disabling the initialization
>> worked. I tested and it worked, the "receive length failed (error
>> -11)" error disapear.
>> I actually change all of the LINE6_CAP_CONTROL to
>> LINE6_CAP_CONTROL_INIT and it worked. I don't know in 4.12 but in 4.10
>> there is used in
>>
>> static void podhd_disconnect(struct usb_line6 *line6)
>> {
>>     struct usb_line6_podhd *pod = (struct usb_line6_podhd *)line6;
>>
>> /*    if (pod->line6.properties->capabilities & LINE6_CAP_CONTROL) {*/
>>     if (pod->line6.properties->capabilities & LINE6_CAP_CONTROL_INIT) {
>>         struct usb_interface *intf;
>>
>>         del_timer_sync(&pod->startup_timer);
>>         cancel_work_sync(&pod->startup_work);
>>
>>         intf = usb_ifnum_to_if(line6->usbdev,
>>                     pod->line6.properties->ctrl_if);
>>         usb_driver_release_interface(&podhd_driver, intf);
>>     }
>> }
>>
>> and in podhd_init is also this:
>>
>> if (pod->line6.properties->capabilities & LINE6_CAP_CONTROL_INIT) {
>>         /* claim the data interface */
>>         intf = usb_ifnum_to_if(line6->usbdev,
>>                     pod->line6.properties->ctrl_if);
>>         if (!intf) {
>>             dev_err(pod->line6.ifcdev, "interface %d not found\n",
>>                 pod->line6.properties->ctrl_if);
>>             return -ENODEV;
>>         }
>>
>>         err = usb_driver_claim_interface(&podhd_driver, intf, NULL);
>>         if (err != 0) {
>>             dev_err(pod->line6.ifcdev, "can't claim interface %d, error
>> %d\n",
>>                 pod->line6.properties->ctrl_if, err);
>>             return err;
>>         }
>>
>>         /* create sysfs entries: */
>>         err = snd_card_add_dev_attr(line6->card, &podhd_dev_attr_group);
>>         if (err < 0)
>>             return err;
>>     }
>>
>> It's better to change both of the to LINE6_CAP_CONTROL_INIT?
>>
>> I found out that the 500x need the LINE6_CAP_CONTROL in driver.c, in
>> the probe (maybe also in suspend and resume).
>>
>>
>>
>> Hmm, looking at the code, I think we'll have to refactor it a bit
>> more. If you want to do it - the usb_claim/release needs to be done
>> always for CAP_CONTROL. For !CONTROL_INIT, we should skip the init and
>> release of workqueue and sysfs stuff. I can create the patch too and
>> send it to you for testing, if you want. Don't worry, you won't lose
>> credits :-)
>>
>>
>>
>> MIDI:
>> I added the LINE6_CAP_CONTROL_MIDI to my pod and also added the
>> midi_init procedure in podhd.c, aplaymidi -l sees the midi ports of my
>> pod, but my system freezes (apparenly when my pod sends data), so
>> there's more to do here.
>>
>> Could I do midi via the quirck? Or one device should only has one driver?
>>
>>
>> As I wrote, the hw interface likely doesn't send midi since +/- pod
>> x3. It's some proprietary binary protocol instead, so getting it to
>> work is not trivial. At very least, you'd have to write a translation
>> layer, but I reckon such task would be better suited for a userspace
>> app.
>>
>>
>>
>> Anyway, I will wrap-up to submit the patch with audio only. I will
>> read teh link you send me on how to do it.
>>
>> When you send me the info of how to do it, you meant this?
>> https://www.kernel.org/doc/html/v4.11/process/submitting-patches.html
>> because I search there for line6 and didn't found anything.
>>
>>
>> Yup..
>>
>> The generic alsa-devel mailing list is ok (see MAINTAINERS file, SOUND
>> section), just check the recent commit log of the driver and put a few
>> relevant people on cc. You can send me the patch first if you want,
>> for a quick pre-review (I'd just check that we understood each other
>> and you didn't break POD X3 :) ).
>>
>> Regarding POD HD X, it probably depends on how sure you are that it'll
>> work. If lsusb is the same, it's probably safe to assume it and add.
>> If you don't have even lsusb, I'd go the safe way for now.
>>
>> In any case, split the patch into at least two (add CONTROL_INIT &
>> pod500x(+hdx) support).
>>
>>
>> --
>> Greetings,
>>
>> Andrej
>>
>>
>> On Sun, Jun 11, 2017 at 2:42 AM, Andrej Kruták <de...@an...> wrote:
>> >
>> > Hey there,
>> >
>> > On Sun, Jun 11, 2017 at 4:07 AM, Hans Peter Möller <hm...@gm...>
>> > wrote:
>> > > Hi Andrej,
>> > >    I believe I will have to sniff to get rid of that error.
>> > >
>> >
>> > Well, if you insist... :-) I guess since it works without the
>> > initialization, and noone really needs the device serial number, you
>> > could for now just disable the code. But of course sniffing is more
>> > educational and systematic...
>> >
>> >
>> > > Is there a reason why in kernel 4.10 the podhd.c has no midi init? Now
>> > > I
>> > > don't see the pod midi ports, I remember that in some of my other
>> > > tries
>> > > (kernel 4.4 or 4.8 or quirck) I could see the midi ports of my pod in
>> > > qjacktl connections (but I never test them).
>> > > How is it in Kernel 4.12? How they init midi? (I tried to find the
>> > > tree in
>> > > inet but I couldn't get it). Maybe they drop midi at all.
>> > >
>> >
>> > Perhaps you did it with the quirk thing. But the podhd driver, AFAIK,
>> > never supported MIDI. Maybe pod hdNNN devices support it, but t least
>> > POD X3 doesn't have a native midi interface (compared to previous
>> > models) --> you would have to emulate it via the bulk binary protocol
>> > somehow. Check LINE6_CAP_CONTROL_MIDI in driver.c
>> >
>> >
>> > > In dmesg I see this warning after connecting, could this mean
>> > > something?
>> > >
>> > > [  530.888811] WARNING: CPU: 1 PID: 2889 at
>> > >
>> > > /build/linux-hwe-edge-vebCva/linux-hwe-edge-4.10.0/drivers/usb/core/hcd.c:1587
>> > > usb_hcd_map_urb_for_dma+0x382/0x560
>> > > [  530.888813] transfer buffer not dma capable
>> > >
>> >
>> > This sounds like host USB controller issue, nothing directly related
>> > to the podhd driver probably.
>> >
>> >
>> > --
>> > Greetings,
>> >
>> > Andrej
>> >
>> >
>> > >
>> > > On Sat, Jun 10, 2017 at 4:48 AM, Andrej Kruták <de...@an...> wrote:
>> > >>
>> > >> 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
>> > >> >> >
>> > >> >> >
>> > >> >
>> > >> >
>> > >
>> > >
>
>

Re: [Line6linux-devel] POD HD500x working

[Hans P. M. <hm...@gm...>]

What do you mean with "release of workqueue" ?? The podhd_disconnect
function?

The other two (claim interface in and sysfs out) I think it might by solved
with creating a new if in podhd_init funtion:


static int podhd_init(struct usb_line6 *line6,
              const struct usb_device_id *id)
{
    int err;
    struct usb_line6_podhd *pod = (struct usb_line6_podhd *) line6;
    struct usb_interface *intf;

    line6->disconnect = podhd_disconnect;

    if (pod->line6.properties->capabilities & LINE6_CAP_CONTROL) {
        /* claim the data interface */
        intf = usb_ifnum_to_if(line6->usbdev,
                    pod->line6.properties->ctrl_if);
        if (!intf) {
            dev_err(pod->line6.ifcdev, "interface %d not found\n",
                pod->line6.properties->ctrl_if);
            return -ENODEV;
        }

        err = usb_driver_claim_interface(&podhd_driver, intf, NULL);
        if (err != 0) {
            dev_err(pod->line6.ifcdev, "can't claim interface %d, error
%d\n",
                pod->line6.properties->ctrl_if, err);
            return err;
        }
+    }

+    if (pod->line6.properties->capabilities & LINE6_CAP_CONTROL_INIT) {
        /* create sysfs entries: */
        err = snd_card_add_dev_attr(line6->card, &podhd_dev_attr_group);
        if (err < 0)
            return err;
    }

    if (pod->line6.properties->capabilities & LINE6_CAP_PCM) {
        /* initialize PCM subsystem: */
        err = line6_init_pcm(line6,
            (id->driver_info == LINE6_PODX3 ||
            id->driver_info == LINE6_PODX3LIVE) ? &podx3_pcm_properties :
            &podhd_pcm_properties);
        if (err < 0)
            return err;
    }

-    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);
    }

    /* init device and delay registering */
    init_timer(&pod->startup_timer);
    INIT_WORK(&pod->startup_work, podhd_startup_workqueue);
    podhd_startup(pod);
    return 0;
}


That's what you where thinking? I haven't tested it, I will do as soon as I
can.

On Mon, Jun 12, 2017 at 1:46 AM, Andrej Kruták <de...@an...> wrote:

> Hi there,
>
> On Jun 12, 2017 12:30 AM, "Hans Peter Möller" <hm...@gm...> wrote:
>
> You were right, I forgot to test if disabling the initialization
> worked. I tested and it worked, the "receive length failed (error
> -11)" error disapear.
> I actually change all of the LINE6_CAP_CONTROL to
> LINE6_CAP_CONTROL_INIT and it worked. I don't know in 4.12 but in 4.10
> there is used in
>
> static void podhd_disconnect(struct usb_line6 *line6)
> {
>     struct usb_line6_podhd *pod = (struct usb_line6_podhd *)line6;
>
> /*    if (pod->line6.properties->capabilities & LINE6_CAP_CONTROL) {*/
>     if (pod->line6.properties->capabilities & LINE6_CAP_CONTROL_INIT) {
>         struct usb_interface *intf;
>
>         del_timer_sync(&pod->startup_timer);
>         cancel_work_sync(&pod->startup_work);
>
>         intf = usb_ifnum_to_if(line6->usbdev,
>                     pod->line6.properties->ctrl_if);
>         usb_driver_release_interface(&podhd_driver, intf);
>     }
> }
>
> and in podhd_init is also this:
>
> if (pod->line6.properties->capabilities & LINE6_CAP_CONTROL_INIT) {
>         /* claim the data interface */
>         intf = usb_ifnum_to_if(line6->usbdev,
>                     pod->line6.properties->ctrl_if);
>         if (!intf) {
>             dev_err(pod->line6.ifcdev, "interface %d not found\n",
>                 pod->line6.properties->ctrl_if);
>             return -ENODEV;
>         }
>
>         err = usb_driver_claim_interface(&podhd_driver, intf, NULL);
>         if (err != 0) {
>             dev_err(pod->line6.ifcdev, "can't claim interface %d, error
> %d\n",
>                 pod->line6.properties->ctrl_if, err);
>             return err;
>         }
>
>         /* create sysfs entries: */
>         err = snd_card_add_dev_attr(line6->card, &podhd_dev_attr_group);
>         if (err < 0)
>             return err;
>     }
>
> It's better to change both of the to LINE6_CAP_CONTROL_INIT?
>
> I found out that the 500x need the LINE6_CAP_CONTROL in driver.c, in
> the probe (maybe also in suspend and resume).
>
>
>
> Hmm, looking at the code, I think we'll have to refactor it a bit
> more. If you want to do it - the usb_claim/release needs to be done
> always for CAP_CONTROL. For !CONTROL_INIT, we should skip the init and
> release of workqueue and sysfs stuff. I can create the patch too and
> send it to you for testing, if you want. Don't worry, you won't lose
> credits :-)
>
>
>
> MIDI:
> I added the LINE6_CAP_CONTROL_MIDI to my pod and also added the
> midi_init procedure in podhd.c, aplaymidi -l sees the midi ports of my
> pod, but my system freezes (apparenly when my pod sends data), so
> there's more to do here.
>
> Could I do midi via the quirck? Or one device should only has one driver?
>
>
> As I wrote, the hw interface likely doesn't send midi since +/- pod
> x3. It's some proprietary binary protocol instead, so getting it to
> work is not trivial. At very least, you'd have to write a translation
> layer, but I reckon such task would be better suited for a userspace
> app.
>
>
>
> Anyway, I will wrap-up to submit the patch with audio only. I will
> read teh link you send me on how to do it.
>
> When you send me the info of how to do it, you meant this?
> https://www.kernel.org/doc/html/v4.11/process/submitting-patches.html
> because I search there for line6 and didn't found anything.
>
>
> Yup..
>
> The generic alsa-devel mailing list is ok (see MAINTAINERS file, SOUND
> section), just check the recent commit log of the driver and put a few
> relevant people on cc. You can send me the patch first if you want,
> for a quick pre-review (I'd just check that we understood each other
> and you didn't break POD X3 :) ).
>
> Regarding POD HD X, it probably depends on how sure you are that it'll
> work. If lsusb is the same, it's probably safe to assume it and add.
> If you don't have even lsusb, I'd go the safe way for now.
>
> In any case, split the patch into at least two (add CONTROL_INIT &
> pod500x(+hdx) support).
>
>
> --
> Greetings,
>
> Andrej
>
>
> On Sun, Jun 11, 2017 at 2:42 AM, Andrej Kruták <de...@an...> wrote:
> >
> > Hey there,
> >
> > On Sun, Jun 11, 2017 at 4:07 AM, Hans Peter Möller <hm...@gm...>
> wrote:
> > > Hi Andrej,
> > >    I believe I will have to sniff to get rid of that error.
> > >
> >
> > Well, if you insist... :-) I guess since it works without the
> > initialization, and noone really needs the device serial number, you
> > could for now just disable the code. But of course sniffing is more
> > educational and systematic...
> >
> >
> > > Is there a reason why in kernel 4.10 the podhd.c has no midi init? Now
> I
> > > don't see the pod midi ports, I remember that in some of my other tries
> > > (kernel 4.4 or 4.8 or quirck) I could see the midi ports of my pod in
> > > qjacktl connections (but I never test them).
> > > How is it in Kernel 4.12? How they init midi? (I tried to find the
> tree in
> > > inet but I couldn't get it). Maybe they drop midi at all.
> > >
> >
> > Perhaps you did it with the quirk thing. But the podhd driver, AFAIK,
> > never supported MIDI. Maybe pod hdNNN devices support it, but t least
> > POD X3 doesn't have a native midi interface (compared to previous
> > models) --> you would have to emulate it via the bulk binary protocol
> > somehow. Check LINE6_CAP_CONTROL_MIDI in driver.c
> >
> >
> > > In dmesg I see this warning after connecting, could this mean
> something?
> > >
> > > [  530.888811] WARNING: CPU: 1 PID: 2889 at
> > > /build/linux-hwe-edge-vebCva/linux-hwe-edge-4.10.0/drivers/
> usb/core/hcd.c:1587
> > > usb_hcd_map_urb_for_dma+0x382/0x560
> > > [  530.888813] transfer buffer not dma capable
> > >
> >
> > This sounds like host USB controller issue, nothing directly related
> > to the podhd driver probably.
> >
> >
> > --
> > Greetings,
> >
> > Andrej
> >
> >
> > >
> > > On Sat, Jun 10, 2017 at 4:48 AM, Andrej Kruták <de...@an...> wrote:
> > >>
> > >> 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
> > >> >> >
> > >> >> >
> > >> >
> > >> >
> > >
> > >
>

Re: [Line6linux-devel] POD HD500x working

[Andrej K. <de...@an...>]

Hi there,

On Jun 12, 2017 12:30 AM, "Hans Peter Möller" <hm...@gm...> wrote:

You were right, I forgot to test if disabling the initialization
worked. I tested and it worked, the "receive length failed (error
-11)" error disapear.
I actually change all of the LINE6_CAP_CONTROL to
LINE6_CAP_CONTROL_INIT and it worked. I don't know in 4.12 but in 4.10
there is used in

static void podhd_disconnect(struct usb_line6 *line6)
{
    struct usb_line6_podhd *pod = (struct usb_line6_podhd *)line6;

/*    if (pod->line6.properties->capabilities & LINE6_CAP_CONTROL) {*/
    if (pod->line6.properties->capabilities & LINE6_CAP_CONTROL_INIT) {
        struct usb_interface *intf;

        del_timer_sync(&pod->startup_timer);
        cancel_work_sync(&pod->startup_work);

        intf = usb_ifnum_to_if(line6->usbdev,
                    pod->line6.properties->ctrl_if);
        usb_driver_release_interface(&podhd_driver, intf);
    }
}

and in podhd_init is also this:

if (pod->line6.properties->capabilities & LINE6_CAP_CONTROL_INIT) {
        /* claim the data interface */
        intf = usb_ifnum_to_if(line6->usbdev,
                    pod->line6.properties->ctrl_if);
        if (!intf) {
            dev_err(pod->line6.ifcdev, "interface %d not found\n",
                pod->line6.properties->ctrl_if);
            return -ENODEV;
        }

        err = usb_driver_claim_interface(&podhd_driver, intf, NULL);
        if (err != 0) {
            dev_err(pod->line6.ifcdev, "can't claim interface %d, error %d\n",
                pod->line6.properties->ctrl_if, err);
            return err;
        }

        /* create sysfs entries: */
        err = snd_card_add_dev_attr(line6->card, &podhd_dev_attr_group);
        if (err < 0)
            return err;
    }

It's better to change both of the to LINE6_CAP_CONTROL_INIT?

I found out that the 500x need the LINE6_CAP_CONTROL in driver.c, in
the probe (maybe also in suspend and resume).



Hmm, looking at the code, I think we'll have to refactor it a bit
more. If you want to do it - the usb_claim/release needs to be done
always for CAP_CONTROL. For !CONTROL_INIT, we should skip the init and
release of workqueue and sysfs stuff. I can create the patch too and
send it to you for testing, if you want. Don't worry, you won't lose
credits :-)



MIDI:
I added the LINE6_CAP_CONTROL_MIDI to my pod and also added the
midi_init procedure in podhd.c, aplaymidi -l sees the midi ports of my
pod, but my system freezes (apparenly when my pod sends data), so
there's more to do here.

Could I do midi via the quirck? Or one device should only has one driver?


As I wrote, the hw interface likely doesn't send midi since +/- pod
x3. It's some proprietary binary protocol instead, so getting it to
work is not trivial. At very least, you'd have to write a translation
layer, but I reckon such task would be better suited for a userspace
app.



Anyway, I will wrap-up to submit the patch with audio only. I will
read teh link you send me on how to do it.

When you send me the info of how to do it, you meant this?
https://www.kernel.org/doc/html/v4.11/process/submitting-patches.html
because I search there for line6 and didn't found anything.


Yup..

The generic alsa-devel mailing list is ok (see MAINTAINERS file, SOUND
section), just check the recent commit log of the driver and put a few
relevant people on cc. You can send me the patch first if you want,
for a quick pre-review (I'd just check that we understood each other
and you didn't break POD X3 :) ).

Regarding POD HD X, it probably depends on how sure you are that it'll
work. If lsusb is the same, it's probably safe to assume it and add.
If you don't have even lsusb, I'd go the safe way for now.

In any case, split the patch into at least two (add CONTROL_INIT &
pod500x(+hdx) support).


-- 
Greetings,

Andrej


On Sun, Jun 11, 2017 at 2:42 AM, Andrej Kruták <de...@an...> wrote:
>
> Hey there,
>
> On Sun, Jun 11, 2017 at 4:07 AM, Hans Peter Möller <hm...@gm...> wrote:
> > Hi Andrej,
> >    I believe I will have to sniff to get rid of that error.
> >
>
> Well, if you insist... :-) I guess since it works without the
> initialization, and noone really needs the device serial number, you
> could for now just disable the code. But of course sniffing is more
> educational and systematic...
>
>
> > Is there a reason why in kernel 4.10 the podhd.c has no midi init? Now I
> > don't see the pod midi ports, I remember that in some of my other tries
> > (kernel 4.4 or 4.8 or quirck) I could see the midi ports of my pod in
> > qjacktl connections (but I never test them).
> > How is it in Kernel 4.12? How they init midi? (I tried to find the tree in
> > inet but I couldn't get it). Maybe they drop midi at all.
> >
>
> Perhaps you did it with the quirk thing. But the podhd driver, AFAIK,
> never supported MIDI. Maybe pod hdNNN devices support it, but t least
> POD X3 doesn't have a native midi interface (compared to previous
> models) --> you would have to emulate it via the bulk binary protocol
> somehow. Check LINE6_CAP_CONTROL_MIDI in driver.c
>
>
> > In dmesg I see this warning after connecting, could this mean something?
> >
> > [  530.888811] WARNING: CPU: 1 PID: 2889 at
> > /build/linux-hwe-edge-vebCva/linux-hwe-edge-4.10.0/drivers/usb/core/hcd.c:1587
> > usb_hcd_map_urb_for_dma+0x382/0x560
> > [  530.888813] transfer buffer not dma capable
> >
>
> This sounds like host USB controller issue, nothing directly related
> to the podhd driver probably.
>
>
> --
> Greetings,
>
> Andrej
>
>
> >
> > On Sat, Jun 10, 2017 at 4:48 AM, Andrej Kruták <de...@an...> wrote:
> >>
> >> 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
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >

Re: [Line6linux-devel] POD HD500x working

[Hans P. M. <hm...@gm...>]

Sorry to bother you again Andrej,

I will have to learn a bit of git to make the patch.

I believe that pod hd pro x works the same way as  podhd500x, so it should
be copying the same parameters, but I cannot test it because I don't have a
pod hd pro x. Sould I include the parameters in the git or I cannot because
it's not tested?



On Sun, Jun 11, 2017 at 6:30 PM, Hans Peter Möller <hm...@gm...>
wrote:

> You were right, I forgot to test if disabling the initialization worked. I
> tested and it worked, the "receive length failed (error -11)" error
> disapear.
> I actually change all of the LINE6_CAP_CONTROL to LINE6_CAP_CONTROL_INIT
> and it worked. I don't know in 4.12 but in 4.10 there is used in
>
> static void podhd_disconnect(struct usb_line6 *line6)
> {
>     struct usb_line6_podhd *pod = (struct usb_line6_podhd *)line6;
>
> /*    if (pod->line6.properties->capabilities & LINE6_CAP_CONTROL) {*/
>     if (pod->line6.properties->capabilities & LINE6_CAP_CONTROL_INIT) {
>         struct usb_interface *intf;
>
>         del_timer_sync(&pod->startup_timer);
>         cancel_work_sync(&pod->startup_work);
>
>         intf = usb_ifnum_to_if(line6->usbdev,
>                     pod->line6.properties->ctrl_if);
>         usb_driver_release_interface(&podhd_driver, intf);
>     }
> }
>
> and in podhd_init is also this:
>
> if (pod->line6.properties->capabilities & LINE6_CAP_CONTROL_INIT) {
>         /* claim the data interface */
>         intf = usb_ifnum_to_if(line6->usbdev,
>                     pod->line6.properties->ctrl_if);
>         if (!intf) {
>             dev_err(pod->line6.ifcdev, "interface %d not found\n",
>                 pod->line6.properties->ctrl_if);
>             return -ENODEV;
>         }
>
>         err = usb_driver_claim_interface(&podhd_driver, intf, NULL);
>         if (err != 0) {
>             dev_err(pod->line6.ifcdev, "can't claim interface %d, error
> %d\n",
>                 pod->line6.properties->ctrl_if, err);
>             return err;
>         }
>
>         /* create sysfs entries: */
>         err = snd_card_add_dev_attr(line6->card, &podhd_dev_attr_group);
>         if (err < 0)
>             return err;
>     }
>
> It's better to change both of the to LINE6_CAP_CONTROL_INIT?
>
> I found out that the 500x need the LINE6_CAP_CONTROL in driver.c, in the
> probe (maybe also in suspend and resume).
>
> MIDI:
> I added the LINE6_CAP_CONTROL_MIDI to my pod and also added the midi_init
> procedure in podhd.c, aplaymidi -l sees the midi ports of my pod, but my
> system freezes (apparenly when my pod sends data), so there's more to do
> here.
>
> Could I do midi via the quirck? Or one device should only has one driver?
>
> Anyway, I will wrap-up to submit the patch with audio only. I will read
> teh link you send me on how to do it.
>
> When you send me the info of how to do it, you meant this?
> https://www.kernel.org/doc/html/v4.11/process/submitting-patches.html
> because I search there for line6 and didn't found anything.
>
> brgds
> HPM
>
> On Sun, Jun 11, 2017 at 2:42 AM, Andrej Kruták <de...@an...> wrote:
>
>> Hey there,
>>
>> On Sun, Jun 11, 2017 at 4:07 AM, Hans Peter Möller <hm...@gm...>
>> wrote:
>> > Hi Andrej,
>> >    I believe I will have to sniff to get rid of that error.
>> >
>>
>> Well, if you insist... :-) I guess since it works without the
>> initialization, and noone really needs the device serial number, you
>> could for now just disable the code. But of course sniffing is more
>> educational and systematic...
>>
>>
>> > Is there a reason why in kernel 4.10 the podhd.c has no midi init? Now I
>> > don't see the pod midi ports, I remember that in some of my other tries
>> > (kernel 4.4 or 4.8 or quirck) I could see the midi ports of my pod in
>> > qjacktl connections (but I never test them).
>> > How is it in Kernel 4.12? How they init midi? (I tried to find the tree
>> in
>> > inet but I couldn't get it). Maybe they drop midi at all.
>> >
>>
>> Perhaps you did it with the quirk thing. But the podhd driver, AFAIK,
>> never supported MIDI. Maybe pod hdNNN devices support it, but t least
>> POD X3 doesn't have a native midi interface (compared to previous
>> models) --> you would have to emulate it via the bulk binary protocol
>> somehow. Check LINE6_CAP_CONTROL_MIDI in driver.c
>>
>>
>> > In dmesg I see this warning after connecting, could this mean something?
>> >
>> > [  530.888811] WARNING: CPU: 1 PID: 2889 at
>> > /build/linux-hwe-edge-vebCva/linux-hwe-edge-4.10.0/drivers/u
>> sb/core/hcd.c:1587
>> > usb_hcd_map_urb_for_dma+0x382/0x560
>> > [  530.888813] transfer buffer not dma capable
>> >
>>
>> This sounds like host USB controller issue, nothing directly related
>> to the podhd driver probably.
>>
>>
>> --
>> Greetings,
>>
>> Andrej
>>
>>
>> >
>> > On Sat, Jun 10, 2017 at 4:48 AM, Andrej Kruták <de...@an...> wrote:
>> >>
>> >> 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/linu
>> x/+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/line
>> 6/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
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>>
>
>

Re: [Line6linux-devel] POD HD500x working

[Hans P. M. <hm...@gm...>]

You were right, I forgot to test if disabling the initialization worked. I
tested and it worked, the "receive length failed (error -11)" error
disapear.
I actually change all of the LINE6_CAP_CONTROL to LINE6_CAP_CONTROL_INIT
and it worked. I don't know in 4.12 but in 4.10 there is used in

static void podhd_disconnect(struct usb_line6 *line6)
{
    struct usb_line6_podhd *pod = (struct usb_line6_podhd *)line6;

/*    if (pod->line6.properties->capabilities & LINE6_CAP_CONTROL) {*/
    if (pod->line6.properties->capabilities & LINE6_CAP_CONTROL_INIT) {
        struct usb_interface *intf;

        del_timer_sync(&pod->startup_timer);
        cancel_work_sync(&pod->startup_work);

        intf = usb_ifnum_to_if(line6->usbdev,
                    pod->line6.properties->ctrl_if);
        usb_driver_release_interface(&podhd_driver, intf);
    }
}

and in podhd_init is also this:

if (pod->line6.properties->capabilities & LINE6_CAP_CONTROL_INIT) {
        /* claim the data interface */
        intf = usb_ifnum_to_if(line6->usbdev,
                    pod->line6.properties->ctrl_if);
        if (!intf) {
            dev_err(pod->line6.ifcdev, "interface %d not found\n",
                pod->line6.properties->ctrl_if);
            return -ENODEV;
        }

        err = usb_driver_claim_interface(&podhd_driver, intf, NULL);
        if (err != 0) {
            dev_err(pod->line6.ifcdev, "can't claim interface %d, error
%d\n",
                pod->line6.properties->ctrl_if, err);
            return err;
        }

        /* create sysfs entries: */
        err = snd_card_add_dev_attr(line6->card, &podhd_dev_attr_group);
        if (err < 0)
            return err;
    }

It's better to change both of the to LINE6_CAP_CONTROL_INIT?

I found out that the 500x need the LINE6_CAP_CONTROL in driver.c, in the
probe (maybe also in suspend and resume).

MIDI:
I added the LINE6_CAP_CONTROL_MIDI to my pod and also added the midi_init
procedure in podhd.c, aplaymidi -l sees the midi ports of my pod, but my
system freezes (apparenly when my pod sends data), so there's more to do
here.

Could I do midi via the quirck? Or one device should only has one driver?

Anyway, I will wrap-up to submit the patch with audio only. I will read teh
link you send me on how to do it.

When you send me the info of how to do it, you meant this?
https://www.kernel.org/doc/html/v4.11/process/submitting-patches.html
because I search there for line6 and didn't found anything.

brgds
HPM

On Sun, Jun 11, 2017 at 2:42 AM, Andrej Kruták <de...@an...> wrote:

> Hey there,
>
> On Sun, Jun 11, 2017 at 4:07 AM, Hans Peter Möller <hm...@gm...>
> wrote:
> > Hi Andrej,
> >    I believe I will have to sniff to get rid of that error.
> >
>
> Well, if you insist... :-) I guess since it works without the
> initialization, and noone really needs the device serial number, you
> could for now just disable the code. But of course sniffing is more
> educational and systematic...
>
>
> > Is there a reason why in kernel 4.10 the podhd.c has no midi init? Now I
> > don't see the pod midi ports, I remember that in some of my other tries
> > (kernel 4.4 or 4.8 or quirck) I could see the midi ports of my pod in
> > qjacktl connections (but I never test them).
> > How is it in Kernel 4.12? How they init midi? (I tried to find the tree
> in
> > inet but I couldn't get it). Maybe they drop midi at all.
> >
>
> Perhaps you did it with the quirk thing. But the podhd driver, AFAIK,
> never supported MIDI. Maybe pod hdNNN devices support it, but t least
> POD X3 doesn't have a native midi interface (compared to previous
> models) --> you would have to emulate it via the bulk binary protocol
> somehow. Check LINE6_CAP_CONTROL_MIDI in driver.c
>
>
> > In dmesg I see this warning after connecting, could this mean something?
> >
> > [  530.888811] WARNING: CPU: 1 PID: 2889 at
> > /build/linux-hwe-edge-vebCva/linux-hwe-edge-4.10.0/drivers/
> usb/core/hcd.c:1587
> > usb_hcd_map_urb_for_dma+0x382/0x560
> > [  530.888813] transfer buffer not dma capable
> >
>
> This sounds like host USB controller issue, nothing directly related
> to the podhd driver probably.
>
>
> --
> Greetings,
>
> Andrej
>
>
> >
> > On Sat, Jun 10, 2017 at 4:48 AM, Andrej Kruták <de...@an...> wrote:
> >>
> >> 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
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>

Re: [Line6linux-devel] POD HD500x working

[Andrej K. <de...@an...>]

Hey there,

On Sun, Jun 11, 2017 at 4:07 AM, Hans Peter Möller <hm...@gm...> wrote:
> Hi Andrej,
>    I believe I will have to sniff to get rid of that error.
>

Well, if you insist... :-) I guess since it works without the
initialization, and noone really needs the device serial number, you
could for now just disable the code. But of course sniffing is more
educational and systematic...


> Is there a reason why in kernel 4.10 the podhd.c has no midi init? Now I
> don't see the pod midi ports, I remember that in some of my other tries
> (kernel 4.4 or 4.8 or quirck) I could see the midi ports of my pod in
> qjacktl connections (but I never test them).
> How is it in Kernel 4.12? How they init midi? (I tried to find the tree in
> inet but I couldn't get it). Maybe they drop midi at all.
>

Perhaps you did it with the quirk thing. But the podhd driver, AFAIK,
never supported MIDI. Maybe pod hdNNN devices support it, but t least
POD X3 doesn't have a native midi interface (compared to previous
models) --> you would have to emulate it via the bulk binary protocol
somehow. Check LINE6_CAP_CONTROL_MIDI in driver.c


> In dmesg I see this warning after connecting, could this mean something?
>
> [  530.888811] WARNING: CPU: 1 PID: 2889 at
> /build/linux-hwe-edge-vebCva/linux-hwe-edge-4.10.0/drivers/usb/core/hcd.c:1587
> usb_hcd_map_urb_for_dma+0x382/0x560
> [  530.888813] transfer buffer not dma capable
>

This sounds like host USB controller issue, nothing directly related
to the podhd driver probably.


-- 
Greetings,

Andrej


>
> On Sat, Jun 10, 2017 at 4:48 AM, Andrej Kruták <de...@an...> wrote:
>>
>> 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
>> >> >
>> >> >
>> >
>> >
>
>

Re: [Line6linux-devel] POD HD500x working

[Hans P. M. <hm...@gm...>]

Hi Andrej,
   I believe I will have to sniff to get rid of that error.

Is there a reason why in kernel 4.10 the podhd.c has no midi init? Now I
don't see the pod midi ports, I remember that in some of my other tries
(kernel 4.4 or 4.8 or quirck) I could see the midi ports of my pod in
qjacktl connections (but I never test them).
How is it in Kernel 4.12? How they init midi? (I tried to find the tree in
inet but I couldn't get it). Maybe they drop midi at all.

In dmesg I see this warning after connecting, could this mean something?

[  530.888811] WARNING: CPU: 1 PID: 2889 at
/build/linux-hwe-edge-vebCva/linux-hwe-edge-4.10.0/drivers/usb/core/hcd.c:1587
usb_hcd_map_urb_for_dma+0x382/0x560
[  530.888813] transfer buffer not dma capable

thanks again.
brgds
HPM

On Sat, Jun 10, 2017 at 4:48 AM, Andrej Kruták <de...@an...> wrote:

> 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
> <https://git.launchpad.net/%7Eubuntu-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
> >> >
> >> >
> >
> >
>

Re: [Line6linux-devel] POD HD500x working

[Andrej K. <de...@an...>]

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

Re: [Line6linux-devel] POD HD500x working

[Hans P. M. <hm...@gm...>]

Hi Andrej,
   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.
-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?

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

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

Re: [Line6linux-devel] POD HD500x working

[Andrej K. <de...@an...>]

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

Re: [Line6linux-devel] POD HD500x working

[Hans P. M. <hm...@gm...>]

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
>

Re: [Line6linux-devel] POD HD500x working

[Andrej K. <de...@an...>]

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

[Line6linux-devel] POD HD500x working

[Hans P. M. <hm...@gm...>]

Hi Andrej,
   good news!!
I can capture and listen from my pod.

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 believe this should be added to the podhd.c delivered in the kernel but I
dont know how to do that.

Thanks a lot for you help.

Re: [Line6linux-devel] pod hd500x

[Andrej K. <de...@an...>]

On Jun 7, 2017 1:23 AM, "Hans Peter Möller" <hm...@gm...> wrote:

Thanks Andrej,
I will do that.

I also found in the ardour blog some quirk on snd-usb-audio for pod hd pro
in https://community.ardour.org/node/13646. The lsusb of the pod hd pro is
almost identical (except for the product id) from the one of the pod
hd500x.


that could work too, yes. For x3 there was a problem though, that some
binary initial setup was needed - but more importantly, for audio recording
to work, the device required an ongoing playback to. So because of this, I
had to use/extend podhd driver. But probably hd500x is more similar to
hd500, where it (at least according to sources) isn't needed. Just keep it
in mind if the device misbehaves... :)


I would try that path to, I still don't know how to apply the quirk,
apparently adding it to quirks-table.h and compiling the kernel.
I'm not sure why the whole kernel need to be compiled if only the
snd-usb-audio is the affected.
have you tried something like this?

afaik, you really only need to rebuild the one module. You can just insmod
that, and in worst case it will segfault :) Perhaps there are dependencies
causing while kernel rebuild, but I reckon if you add the new card at the
end of the quirks array, it should be binary compatible.

If it works, be sure to post the patch to kernel ! :)




On Tue, Jun 6, 2017 at 1:42 PM, Andrej Kruták <de...@an...> wrote:

> On Mon, Jun 5, 2017 at 7:16 PM, Hans Peter Möller <hm...@gm...>
> wrote:
> > The 4 EP (2 audio and 2 ctrl) match the ones from PODHD500_0 and
> PODHD500_1
> > (do you know what are the ctrl or User for??) so it appears to be simple.
>
> Not sure what you mean by "User", but the ctrl are used (well, can be
> used) to transfer stuff like effects configuration.
>
>
> >
> > Now to test if this simple edit would be enough, I assume I have to
> > uninstall the module from the kernel (line6usb comes with the kernel) and
> > then compile and follow the instructions prior it was included in the
> > kernel. Is that correct? If that's the case, what would be the best way
> to
> > uninstall the module from teh kernel?
>
> TBH, you should rather read some tutorial regarding this. This depends
> on your distribution, google for "linux module rebuild" etc.
>
>
> > I would also need to pin the kernel,
> > so no kernel update with line6usb module mess with this right?
> > thansk a lot.
> >
>
> That is the optimal solution. You can do such thing via dkms, for example.
>
> Myself, I only use the driver occasionally, so everytime I need it,
> I'll just basically do:
>
> rmmod snd_usb_podhd
> rmmod snd_usb_line6
> cd $LINUX_SRC/sound/usb/line6/ # basically you only need the one
> directory, not whole tree
> make -C /lib/modules/`uname -r`/build M=$PWD
> insmod snd-usb-line6.ko
> insmod snd-usb-podhd.ko
>
> (Of course, rmmod/insmod need to be executed as root).
>
>
> --
> Good luck,
>
> A.
>
> >
> >
> > On Sun, Jun 4, 2017 at 4:01 PM, Andrej Kruták <de...@an...> wrote:
> >>
> >> Hi there,
> >>
> >> On Thu, Jun 1, 2017 at 1:19 AM, Hans Peter Möller <hm...@gm...>
> >> wrote:
> >> >    I want to help to inlude the pod hd500x in the driver. I've never
> >> > done
> >> > some driver programming but I have done a lot of coding myself, from
> ASM
> >> > in
> >> > a PIC to php, java, javascript, vb, c, c#, etc... If you can give me
> >> > some
> >> > info to read and study it would be great to start.
> >> >
> >> > Do you use wireshark to do the reverse ingeneering stuff? I'f done
> some
> >> > basic stuff with it.
> >> >
> >> > Hope to hear from you soon.
> >> >
> >>
> >> There's not a lot of traffic here anymore, sadly - so you are veru
> >> much on your own.
> >>
> >>
> >> Anyhow, depends on what you want to do. If it's only the audio
> >> support, with a bit of luck it will be as simple as editing
> >> sound/usb/line6/podhd.c. Add LINE6_PODHD500X similarly like
> >> PODHD500_0. Check the endpoints (esp. the audio ones) match what you
> >> see in lsusb. If POD HD500X has more than 2+2 audio channels, get
> >> inspired at POD X3.
> >>
> >> If you would like to edit the presets etc., you'd have to reverse
> >> engineer the binary protocol. Basically install some USB sniffer (for
> >> me http://www.usblyzer.com/ worked fine), dump the binary stuff (from
> >> bulk endpoints) and have fun. If you cannot get any audio, you may
> >> need some control interface initialization - again check POD X3 or
> >> pod.c.
> >>
> >> I have written down steps I had to do to get POD X3 working - maybe
> >> you'll find them useful. http://andree.sk/2016/11/podx3 (there's also
> >> link to some WIP python binary protocol decoder) ... Perhaps the
> >> binary protocol is similar, in such case we could share some efforts.
> >> POD X3's is actually quite simple - but I never got the time to
> >> implement a GUI for it. Maybe if it turned out it'd be useful also for
> >> other PODs, it would be more temptin ;-)
> >>
> >> --
> >> Greetings & good luck,
> >>
> >> Andrej
> >
> >
>

Re: [Line6linux-devel] pod hd500x

[Hans P. M. <hm...@gm...>]

Thanks Andrej,
I will do that.

I also found in the ardour blog some quirk on snd-usb-audio for pod hd pro
in https://community.ardour.org/node/13646. The lsusb of the pod hd pro is
almost identical (except for the product id) from the one of the pod
hd500x.

I would try that path to, I still don't know how to apply the quirk,
apparently adding it to quirks-table.h and compiling the kernel.
I'm not sure why the whole kernel need to be compiled if only the
snd-usb-audio is the affected.
have you tried something like this?

thanks again.


On Tue, Jun 6, 2017 at 1:42 PM, Andrej Kruták <de...@an...> wrote:

> On Mon, Jun 5, 2017 at 7:16 PM, Hans Peter Möller <hm...@gm...>
> wrote:
> > The 4 EP (2 audio and 2 ctrl) match the ones from PODHD500_0 and
> PODHD500_1
> > (do you know what are the ctrl or User for??) so it appears to be simple.
>
> Not sure what you mean by "User", but the ctrl are used (well, can be
> used) to transfer stuff like effects configuration.
>
>
> >
> > Now to test if this simple edit would be enough, I assume I have to
> > uninstall the module from the kernel (line6usb comes with the kernel) and
> > then compile and follow the instructions prior it was included in the
> > kernel. Is that correct? If that's the case, what would be the best way
> to
> > uninstall the module from teh kernel?
>
> TBH, you should rather read some tutorial regarding this. This depends
> on your distribution, google for "linux module rebuild" etc.
>
>
> > I would also need to pin the kernel,
> > so no kernel update with line6usb module mess with this right?
> > thansk a lot.
> >
>
> That is the optimal solution. You can do such thing via dkms, for example.
>
> Myself, I only use the driver occasionally, so everytime I need it,
> I'll just basically do:
>
> rmmod snd_usb_podhd
> rmmod snd_usb_line6
> cd $LINUX_SRC/sound/usb/line6/ # basically you only need the one
> directory, not whole tree
> make -C /lib/modules/`uname -r`/build M=$PWD
> insmod snd-usb-line6.ko
> insmod snd-usb-podhd.ko
>
> (Of course, rmmod/insmod need to be executed as root).
>
>
> --
> Good luck,
>
> A.
>
> >
> >
> > On Sun, Jun 4, 2017 at 4:01 PM, Andrej Kruták <de...@an...> wrote:
> >>
> >> Hi there,
> >>
> >> On Thu, Jun 1, 2017 at 1:19 AM, Hans Peter Möller <hm...@gm...>
> >> wrote:
> >> >    I want to help to inlude the pod hd500x in the driver. I've never
> >> > done
> >> > some driver programming but I have done a lot of coding myself, from
> ASM
> >> > in
> >> > a PIC to php, java, javascript, vb, c, c#, etc... If you can give me
> >> > some
> >> > info to read and study it would be great to start.
> >> >
> >> > Do you use wireshark to do the reverse ingeneering stuff? I'f done
> some
> >> > basic stuff with it.
> >> >
> >> > Hope to hear from you soon.
> >> >
> >>
> >> There's not a lot of traffic here anymore, sadly - so you are veru
> >> much on your own.
> >>
> >>
> >> Anyhow, depends on what you want to do. If it's only the audio
> >> support, with a bit of luck it will be as simple as editing
> >> sound/usb/line6/podhd.c. Add LINE6_PODHD500X similarly like
> >> PODHD500_0. Check the endpoints (esp. the audio ones) match what you
> >> see in lsusb. If POD HD500X has more than 2+2 audio channels, get
> >> inspired at POD X3.
> >>
> >> If you would like to edit the presets etc., you'd have to reverse
> >> engineer the binary protocol. Basically install some USB sniffer (for
> >> me http://www.usblyzer.com/ worked fine), dump the binary stuff (from
> >> bulk endpoints) and have fun. If you cannot get any audio, you may
> >> need some control interface initialization - again check POD X3 or
> >> pod.c.
> >>
> >> I have written down steps I had to do to get POD X3 working - maybe
> >> you'll find them useful. http://andree.sk/2016/11/podx3 (there's also
> >> link to some WIP python binary protocol decoder) ... Perhaps the
> >> binary protocol is similar, in such case we could share some efforts.
> >> POD X3's is actually quite simple - but I never got the time to
> >> implement a GUI for it. Maybe if it turned out it'd be useful also for
> >> other PODs, it would be more temptin ;-)
> >>
> >> --
> >> Greetings & good luck,
> >>
> >> Andrej
> >
> >
>

Re: [Line6linux-devel] pod hd500x

[Andrej K. <de...@an...>]

On Mon, Jun 5, 2017 at 7:16 PM, Hans Peter Möller <hm...@gm...> wrote:
> The 4 EP (2 audio and 2 ctrl) match the ones from PODHD500_0 and PODHD500_1
> (do you know what are the ctrl or User for??) so it appears to be simple.

Not sure what you mean by "User", but the ctrl are used (well, can be
used) to transfer stuff like effects configuration.


>
> Now to test if this simple edit would be enough, I assume I have to
> uninstall the module from the kernel (line6usb comes with the kernel) and
> then compile and follow the instructions prior it was included in the
> kernel. Is that correct? If that's the case, what would be the best way to
> uninstall the module from teh kernel?

TBH, you should rather read some tutorial regarding this. This depends
on your distribution, google for "linux module rebuild" etc.


> I would also need to pin the kernel,
> so no kernel update with line6usb module mess with this right?
> thansk a lot.
>

That is the optimal solution. You can do such thing via dkms, for example.

Myself, I only use the driver occasionally, so everytime I need it,
I'll just basically do:

rmmod snd_usb_podhd
rmmod snd_usb_line6
cd $LINUX_SRC/sound/usb/line6/ # basically you only need the one
directory, not whole tree
make -C /lib/modules/`uname -r`/build M=$PWD
insmod snd-usb-line6.ko
insmod snd-usb-podhd.ko

(Of course, rmmod/insmod need to be executed as root).


-- 
Good luck,

A.

>
>
> On Sun, Jun 4, 2017 at 4:01 PM, Andrej Kruták <de...@an...> wrote:
>>
>> Hi there,
>>
>> On Thu, Jun 1, 2017 at 1:19 AM, Hans Peter Möller <hm...@gm...>
>> wrote:
>> >    I want to help to inlude the pod hd500x in the driver. I've never
>> > done
>> > some driver programming but I have done a lot of coding myself, from ASM
>> > in
>> > a PIC to php, java, javascript, vb, c, c#, etc... If you can give me
>> > some
>> > info to read and study it would be great to start.
>> >
>> > Do you use wireshark to do the reverse ingeneering stuff? I'f done some
>> > basic stuff with it.
>> >
>> > Hope to hear from you soon.
>> >
>>
>> There's not a lot of traffic here anymore, sadly - so you are veru
>> much on your own.
>>
>>
>> Anyhow, depends on what you want to do. If it's only the audio
>> support, with a bit of luck it will be as simple as editing
>> sound/usb/line6/podhd.c. Add LINE6_PODHD500X similarly like
>> PODHD500_0. Check the endpoints (esp. the audio ones) match what you
>> see in lsusb. If POD HD500X has more than 2+2 audio channels, get
>> inspired at POD X3.
>>
>> If you would like to edit the presets etc., you'd have to reverse
>> engineer the binary protocol. Basically install some USB sniffer (for
>> me http://www.usblyzer.com/ worked fine), dump the binary stuff (from
>> bulk endpoints) and have fun. If you cannot get any audio, you may
>> need some control interface initialization - again check POD X3 or
>> pod.c.
>>
>> I have written down steps I had to do to get POD X3 working - maybe
>> you'll find them useful. http://andree.sk/2016/11/podx3 (there's also
>> link to some WIP python binary protocol decoder) ... Perhaps the
>> binary protocol is similar, in such case we could share some efforts.
>> POD X3's is actually quite simple - but I never got the time to
>> implement a GUI for it. Maybe if it turned out it'd be useful also for
>> other PODs, it would be more temptin ;-)
>>
>> --
>> Greetings & good luck,
>>
>> Andrej
>
>

Re: [Line6linux-devel] pod hd500x

[Hans P. M. <hm...@gm...>]

Thanks Andrej!
     with audio working I will be more than happy.

The 4 EP (2 audio and 2 ctrl) match the ones from PODHD500_0 and PODHD500_1
(do you know what are the ctrl or User for??) so it appears to be simple.

Now to test if this simple edit would be enough, I assume I have to
uninstall the module from the kernel (line6usb comes with the kernel) and
then compile and follow the instructions prior it was included in the
kernel. Is that correct? If that's the case, what would be the best way to
uninstall the module from teh kernel? I would also need to pin the kernel,
so no kernel update with line6usb module mess with this right?
thansk a lot.

brgds
HPM


On Sun, Jun 4, 2017 at 4:01 PM, Andrej Kruták <de...@an...> wrote:

> Hi there,
>
> On Thu, Jun 1, 2017 at 1:19 AM, Hans Peter Möller <hm...@gm...>
> wrote:
> >    I want to help to inlude the pod hd500x in the driver. I've never done
> > some driver programming but I have done a lot of coding myself, from ASM
> in
> > a PIC to php, java, javascript, vb, c, c#, etc... If you can give me some
> > info to read and study it would be great to start.
> >
> > Do you use wireshark to do the reverse ingeneering stuff? I'f done some
> > basic stuff with it.
> >
> > Hope to hear from you soon.
> >
>
> There's not a lot of traffic here anymore, sadly - so you are veru
> much on your own.
>
>
> Anyhow, depends on what you want to do. If it's only the audio
> support, with a bit of luck it will be as simple as editing
> sound/usb/line6/podhd.c. Add LINE6_PODHD500X similarly like
> PODHD500_0. Check the endpoints (esp. the audio ones) match what you
> see in lsusb. If POD HD500X has more than 2+2 audio channels, get
> inspired at POD X3.
>
> If you would like to edit the presets etc., you'd have to reverse
> engineer the binary protocol. Basically install some USB sniffer (for
> me http://www.usblyzer.com/ worked fine), dump the binary stuff (from
> bulk endpoints) and have fun. If you cannot get any audio, you may
> need some control interface initialization - again check POD X3 or
> pod.c.
>
> I have written down steps I had to do to get POD X3 working - maybe
> you'll find them useful. http://andree.sk/2016/11/podx3 (there's also
> link to some WIP python binary protocol decoder) ... Perhaps the
> binary protocol is similar, in such case we could share some efforts.
> POD X3's is actually quite simple - but I never got the time to
> implement a GUI for it. Maybe if it turned out it'd be useful also for
> other PODs, it would be more temptin ;-)
>
> --
> Greetings & good luck,
>
> Andrej
>

Re: [Line6linux-devel] pod hd500x

[Andrej K. <de...@an...>]

Hi there,

On Thu, Jun 1, 2017 at 1:19 AM, Hans Peter Möller <hm...@gm...> wrote:
>    I want to help to inlude the pod hd500x in the driver. I've never done
> some driver programming but I have done a lot of coding myself, from ASM in
> a PIC to php, java, javascript, vb, c, c#, etc... If you can give me some
> info to read and study it would be great to start.
>
> Do you use wireshark to do the reverse ingeneering stuff? I'f done some
> basic stuff with it.
>
> Hope to hear from you soon.
>

There's not a lot of traffic here anymore, sadly - so you are veru
much on your own.


Anyhow, depends on what you want to do. If it's only the audio
support, with a bit of luck it will be as simple as editing
sound/usb/line6/podhd.c. Add LINE6_PODHD500X similarly like
PODHD500_0. Check the endpoints (esp. the audio ones) match what you
see in lsusb. If POD HD500X has more than 2+2 audio channels, get
inspired at POD X3.

If you would like to edit the presets etc., you'd have to reverse
engineer the binary protocol. Basically install some USB sniffer (for
me http://www.usblyzer.com/ worked fine), dump the binary stuff (from
bulk endpoints) and have fun. If you cannot get any audio, you may
need some control interface initialization - again check POD X3 or
pod.c.

I have written down steps I had to do to get POD X3 working - maybe
you'll find them useful. http://andree.sk/2016/11/podx3 (there's also
link to some WIP python binary protocol decoder) ... Perhaps the
binary protocol is similar, in such case we could share some efforts.
POD X3's is actually quite simple - but I never got the time to
implement a GUI for it. Maybe if it turned out it'd be useful also for
other PODs, it would be more temptin ;-)

-- 
Greetings & good luck,

Andrej

[Line6linux-devel] pod hd500x

[Hans P. M. <hm...@gm...>]

Hi,
   I want to help to inlude the pod hd500x in the driver. I've never done
some driver programming but I have done a lot of coding myself, from ASM in
a PIC to php, java, javascript, vb, c, c#, etc... If you can give me some
info to read and study it would be great to start.

Do you use wireshark to do the reverse ingeneering stuff? I'f done some
basic stuff with it.

Hope to hear from you soon.

brgds
HPM

Re: [Line6linux-devel] Where is the line6usb driver located in menuconfig nowadays?

[Laurent N. <lau...@ya...>]

Hi,While in menuconfig, you can type '/ ' and search for LINE6.
Hope it helps,
Laurent, 


     Le Samedi 17 octobre 2015 20h10, eliteos_webmaster <el...@gm...> a écrit :
   
 

 I can't seem to find it since it was moved out of staging. :(

Cheers

Tom

------------------------------------------------------------------------------
_______________________________________________
Line6linux-devel mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/line6linux-devel


 
  

[Line6linux-devel] Where is the line6usb driver located in menuconfig nowadays?

[eliteos_webmaster <el...@gm...>]

I can't seem to find it since it was moved out of staging. :(

Cheers

Tom

[Line6linux-devel] line6 pod(hd)/x3 support

[Andrej K. <de...@an...>]

Hi Stefan,


In short - I am (yet again) trying to figure out Pod X3 and add it to the
driver. I found that in the last year you guys made it from staging to main
- congrats!

Anywho, I did some research (and reused pypodx3.py tool in svn). Seems like
the control/init communication w/ X3 is similar to podxt - yet the samples
format should be (acc. to specs) 48kHz (+it has two inputs). Also, it seems
that the parameter settings differs to the older pods.

I saw that you guys completely avoided the init stuff for HD and just get
on to the audio endpoint usage. Seems this doesn't work for X3. After
hacking around, it seems that also the data endpoints changed from
interrupt to bulk - but even after fixing it, the init differs in some
points. I am confident I should be able to make it work eventually.

Could you please provide lsusb's (-v) of PODxt and some POD HDnnn? Would be
interesting to compare... Also some USB logs from windows would be
interesting - to see, whether the parameter settings is still done the same
way on HD.

I think, in the end we'll have to merge pod.c+podhd.c to support x3 and not
duplicate too much of code. The nice side effect could be also potential
support for other pod features, if X3 will be similar enough to HD :)

--
Thanks for your time and answer,

Andrej

Re: [Line6linux-devel] Anyone interested in getting line6usb out of staging?

[L. A. G. <agi...@sy...>]

On Fri, Jun 27, 2014 at 07:15:54AM +0200, Stefan Hajnoczi wrote:
> Any developers who want to help get line6usb out of staging?
> 
> http://www.spinics.net/lists/linux-driver-devel/msg49189.html
> 
> Stefan

Hi Stefan,

I would like to, but I'm quite limited on time and knowledge right now. I have an
HD500 (last time I plugged it in, it crashed my system...) and it's a shame that I'm
forced to use Windows :(

I could try in my spare time, but I would need a lot of help and guidance, even on
just where to begin.


-- 
L. Alberto Giménez
GnuPG key ID 0xDD4E27AB

[Line6linux-devel] Anyone interested in getting line6usb out of staging?

[Stefan H. <ste...@gm...>]

Any developers who want to help get line6usb out of staging?

http://www.spinics.net/lists/linux-driver-devel/msg49189.html

Stefan