Am Sonntag, 6. Januar 2013, 14:01:02 schrieben Sie: > I tested your changes with 1000ms delay (default), 2000ms and 3000ms. It > doesn't work but the log says first thing that is sent is version > request (twice) and in following packets it is sent three times in a > row. I think this is not correct (?). Let me answer your last question first: "line6usb 3-1:1.0" refers to the POD interface, "line6usb 3-1:1.1" refers to the Variax interface
The Variax interface doesn't respond unless a Variax guitar is connected via the digital cable. I didn't find out how to get notified when a digital connection is established, therefore the interface is "polled" by repeatedly sending these requests. All messages sent to "line6usb 3-1:1.1" can be ignored (at least I assume the Line6 engineers were smart enough to clearly separate these two). > Looking at the dump from working > version the first thing requested is channel dump. Then firmware version > is requested (only once). I think it might be a good idea to try to > follow that pattern. Also these repeated requests - is it a bug of some > sort or was that your intention? Let's say it's a simplification :-) The startup procedure is repeatedly started every second until it is completely finished. I observed that sometimes the response to the first channel dump request is incomplete, so it has to be done again. However, if the firmware version request doesn't succeed, the whole procedure is started over again. It's maybe not a bug, but a mess, and I just created a branch where this is fixed: https://line6linux.svn.sourceforge.net/svnroot/line6linux/driver/branches/init This will probably not solve the problem, but make it easier to debug. The head revision also contains some more debugging stuff (including the "Variax disable" patch, so let's continue debugging in this branch to avoid messing up the trunk). I don't expect much news from this, but could you please create another log just to verify that the new startup procedure works at least until the version request? Some more ideas: *) There is an alternative way to send data to the device, which is disabled by default. It can be enabled in the driver options dialog (where you also enabled the message debugging feature) by checking "raw data communication". The driver then creates a special file "raw", and any byte sequence copied to this file is immediately sent to the device. You can use the script "create_links.pl" to create symlinks to the sysfs directories containing the special files ("PODxtLive:0" is for the POD interface). Create a file containing the version request byte sequence (F0 7E 7F 06 01 F7) with a hex editor or similar tool, double-check its content, and copy it to "raw" (as root). With message debugging enabled, you can see the message travelling to the device, and the response travelling back (if any). The message takes a slightly different code path inside the driver, which may or may not make a difference. *) It would be helpful to know the exact revision number up to which the driver works for you. r611 is particularly interesting since work on the startup procedure was finished there. If you do a binary search (similar to git's bisect feature), you should prefer version numbers after which the driver remained unchanged for some time since these are likely the most stable ones. Kind regards, Markus ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 _______________________________________________ Line6linux-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/line6linux-user
