looking for help with X3 support
Status: Pre-Alpha
Brought to you by:
mgrabner
Menu
▾
▴
Hi
I decided to start looking into X3 svn branch trying to figure out something
and i'm looking for people interested in helping me.
I don't have any understanding of usb protocol or writing kernel drivers,
but why not to try. So far i managed to install usb monitor software,
dump few sessions, find and decode ESN number in the traffic,
add lots of printk to existing driver and crash linux after first
modification :-)
I am hoping to find other enthusiasts that are willing to help me.
Preferably someone who is familiar with usb, because reading dumps
is rather hard without it and it certainly would push me further.
I have X3 (bean) and i can give remote access to my computer.
you can find some spec here for x3 live (lsusb,proc usb devices and usbsnoop session):
http://msound.org/tmp/x3/
hope this helps
Thanks.
For anyone interested: how to start writing driver for usb devices:
A perfect short reference may found in the book "Linux Device Drivers".
Chapter 13 related to usb can be freely downloaded from
http://oreilly.com/catalog/linuxdrive3/chapter/index.html
This contains all information required to understand how usb works and
how to access usb devices from Linux driver.
More details are in usb specification: http://www.usb.org/developers.
After that reading you can start looking at the wires:
with any usb monitoring utilities: free usbsnoopy or commercial
utilities like usblyze (most of them pricy, but usually trial versions are available).
IMHO, X3 and all others line6 devices must be included in alsa kernel, maybe using usbquirks for audio and midi.
All others enhancements (like sysex/cc/patch,midi programming etc) must run in user space, and not in kernel space.
What you think about?
thanks all
> IMHO, X3 and all others line6 devices must be included in alsa kernel,
> maybe using usbquirks for audio and midi.
The MIDI/USB interface allows to use the same code to access devices which have both MIDI and USB on either of these interfaces, and this is a typical task for the kernel I would say.
> All others enhancements (like sysex/cc/patch,midi programming etc)
> must run in user space, and not in kernel space.
For development, it is very useful to query or modify device state by accessing files in the sysfs tree. I agree that it is not a good idea to implement applications based on this interface, so it could be made optional. Any volunteers :-?
Kind regards,
Markus
Hi all,
i'm on vacation, so i can't test x3 until 20/8.
i hope to send other suggestions and questions after this date.
but in my experience, iirc:
1) x3 don't works with current svn x3 branch. i can see the alsa audio devices, but i can hear anything
2) using patched usbquirks, i can see the device, but jackd crash after 20/30 seconds. (no sounds in the meantime)
thanks for you great works!
I agree, and this is how existing driver for older pods works.
First success
After a week of hacking, crashing kernel, starring at usb dumps and so on,
a just wrote code to read POD X3 serial number (using pyusb).
This is far away from being usable, but i am slowly starting to understand usb.
best regards
> After a week of hacking, crashing kernel, starring at usb dumps and so on,
> a just wrote code to read POD X3 serial number (using pyusb).
Great! I just gave you write permission to the repository, could you please share your development with us in the branch
https://line6linux.svn.sourceforge.net/svnroot/line6linux/driver/branches/x3
Note, however, that I'm currently working in the toneport branch, and if you make radical changes, they might be hard to merge later. Let's just keep in touch to coordinate this.
Thanks & kind regards,
Markus
Thanks. I hope to commit at least some information at the end of this week. For now i can only send control messages (that returns serial number and few other things, probably firmware version), now i am trying to figure out configuration and interface settings - this will let me set channel parameters(volume, treble, etc.).
Then work on recording will start. But there is a lot to learn.
I managed to set volume in X3. For now only once in a session (it doesn't work, then it does, then i can't do it until i restart pod),
but it's still a success. First information about x3 protocol are now in x3 svn branch. There is plenty of messages in communication with pod that i don't understand at all,
but it's late here and i am happy that i did it. I hope to make a progress with setting other params this week.
Goodnight.
Hi,
I started to look at the work that has been done so far with respect to X3 support and I am willing to contribute to its development.
I would like ask what is the status of it and who is actively working on it?
regard,
Maia
There are three things to do in order to fully support X3:
1) understading X3 protocol part related to device settings (reading/changing channels and parameters)
2) understand how sound is encoded
3) implement driver
I can understand large parts of protocol related to device settings. This is the easiest part and few missing elements can be easily obtained, there is no magic here. Analyzing usb is really simple, once you know were to look.
Second part is still mistery for me. I didn't spend much time analyzing it and i am not familiar with alsa and kernel to properly debug and implement it, so it will take some time. I do have few guesses, though.
The problem with last part is that:
- X3 doesn't look like other POD devices, so it doesn't really fit into existing code.
It is not midi based. It fully utilizes usb, so simple message passing is not enough to control it.
To bust development speed, i am seriously thinking about implement it fully in user space and then,
when everything will be clear, move eventually sound processing back to kernel.
The drawback would be, that there is no possibility to have user space alsa driver and libusb 1.0, which is required is not yet marked as stable by authors (yet works properly, i belive),
but speed of analyzing / debugging code in user space versus in kernel is very, very tempting.
Unfortunately, i am lately concerned with other thing (i moved to another job and town, so i have now only notebook with linux, and guitar maybe will arrive next week here), so i am not actually working on it. I hope though to go back to development and i certainly can find time to help anyone get started with it. If you are really interested and ready to devote lot of time, i can provide you all necessary information.
--
Best regards.
> - X3 doesn't look like other POD devices, so it doesn't really fit into existing code.
Ideally, the driver should hide hardware differences behind a common interface. This has been done so far with the different PODs and (to some extent) the TonePort devices. As far as audio is concerned, I think the ALSA concept is generic enough to cope with all different devices from Line6 (including the UX8 - any volunteers :-?
> It is not midi based. It fully utilizes usb, so simple message passing is not enough to control it.
What do you mean here? While some PODs have a MIDI interface, the driver just translates MIDI messages to USB (which is reasonable since Line6 choose to use the same byte-wise protocol for MIDI and USB). If the messages exchanged with the X3 don't follow the MIDI guidelines, a mapping to a MIDI device seems less natural (though still possible), but communication is still based on sending and receiving data over a bus system. A different question is whether this requires support by the driver, or if the user-space libusb is sufficient.
> To bust development speed, i am seriously thinking about implement it fully in user space and then,
> when everything will be clear, move eventually sound processing back to kernel.
Sounds like an efficient approach, but please take a look at the line6usb kernel code before to avoid duplicating features that already exist (e.g., handling of audio frames and USB packets).
The entire repository is a bit of a construction site at the moment, but unless a fully paid developer (or a very ambitious volunteer) takes the time to clean it up and complete the incomplete pieces, I propose to keep the different branches and eventually merge them when the work has been completed.
Kind regards,
Markus
>If the messages exchanged with the X3 don't follow the MIDI guidelines, a mapping
>to a MIDI device seems less natural (though still possible)
And that's how it is. As far as i understand, MIDI is limited to 7bits per byte and X3 fully utilizes 8bits.
Next thing is that single usb packet sets multiple parameters of channel at once, so it would translate into many MIDI messages. Overcoming this could be possible, but very inconvenient.
> but communication is still based on
> sending and receiving data over a bus system.
Yes, but thinking of writing application that controls sophisticated device that contains lots of states and logic to handle like X3 i can see following approaches to take:
1. All logic is in kernel and application only sends control messages telling the kernel what to do.
That would mean lot of code in kernel space and sophisticated protocol. Comparing to users space, kernel code is hard to write, hard to upgrade and hard to debug. I am thinking not only about developers, but also users.
2. All logic is in user space, kernel code only passes usb messages to device. Much easier to debug upgrade and modify. With libusb no kernel code is necessary at all. Incompatible with existing code.
3. Some combination of 1 and 2. Rather merge of cons then pros of both.
Now, because i am still learnig how X3 works, i prefer to start in userspace,
and when protocol will be mostly known and handled, decide what to do next.
If for any reasons (latency, ALSA support) userspace will be inconvenient, rewriting it as kernel driver still will be much faster then starting it there now.
Libusb 1.0 is ready (unfortunately work on python bindings will start in march, so i have to try c++).
I also learned, that userspace ALSA drivers are possible, so there is nothing to stop me from trying.
>The entire repository is a bit of a construction site at the moment, but unless a fully paid developer >(or a very ambitious volunteer) takes the time to clean it up and complete the incomplete pieces, I >propose to keep the different branches and eventually merge them when the work has been .>completed.
I agree.
Maciej,
So maybe we should for the time being concentrate on the first two issues:
1) understading X3 protocol part related to device settings (reading/changing channels and parameters)
2) understand how sound is encoded
and after that think on the best way to implement it.
With respect to 2) what is the current state?
In what way it differs from other Line6 devices?
regards,
Ricardo
>So maybe we should for the time being concentrate on the first two issues:
>1) understading X3 protocol part related to device settings (reading/changing channels and parameters)
Definitely. If you are interested in helping me, i can provide you all necessary information. Basically discovering work on that part will be based on sniffing usb protocol when working with Line6 software on windows. Solid documentation of that will be very important help and there is nothing complicated there,
that i could not easily explain.
>>2) understand how sound is encoded
>With respect to 2) what is the current state?
>In what way it differs from other Line6 devices?
I am just starting to work on it. Now i have a bit more time, i should start analyzing it right
after will understand new libusb.
Thanks for the update Maciej!
I started to work on this a few days ago. I am still in the state of getting the serial number from the X3L which I did with success. So now I am moving to the next step.
I will let you know the progess.
regards,
Maia
Thanks for helping! I added write permissions for the repository to your account, please use the following branch:
https://line6linux.svn.sourceforge.net/svnroot/line6linux/driver/branches/x3
Kind regards,
Markus
Just to let you know that i am working:
i have written simple debug console using libusb and readline,
and i hope to commit it within few days. It will allow to show
pod usb traffic and send some commands to it.
Hey I noticed that it's been a while since you updated this thread, what's the status on the project now?
I recently bought a POD X3, and I'm a programmer… so I think I could help
If you want just tell me the status and next steps.. thanks!
Though I don't have an X3, it seems to me that audio is the hardest part. Maybe the other developers could briefly summarize what they found out so far?
I've written some hints for analyzing the USB protocol of a Line6 device:
http://www.tanzband-scream.at/line6/usblog.html
However, sending the data to me will probably not be useful in this case since the X3 seems to be too much different from other Line6 devices to add support for it just by slightly modifying existing code.
Kind regards,
Markus
Hi…
I just stumbled on this recently… I'm a relative newbie to Linux but I do have some limited programing experience, and I have Pod X3 Live/Variax setup… I'm happy to offer whatever help I can to the project, even if it is only as a Guinea pig/test platform…
I have a great desire to see this thing working in Linux.
Cheers!
Dan
The two most useful things to proceed with X3 support would be the specifications and a device to experiment with. Due to increasing demand, I consider asking Line6 if they are willing to donate either (or both). A nice argument to support this request would be the dollar counter to increase above 1.000.000 on http://www.tanzband-scream.at/line6/poll.php5?results :-), which is well in reach now. So unless you already did so, please submit your vote on
http://www.tanzband-scream.at/line6/poll.php5
and inform other Line6/Linux users about this page!
Thanks & kind regards,
Markus
Hi.
What then, took a half years since the last message from maciejdz. Accordingly, no progress is not scheduled.
I would like to try to understand the function of recording the signal from the X3, but I need any help. Somebody spoke to Line6 for specifications?
--
Best regards, PSA.