[alsa-devel] TASCAM US-122mkII
Hi! The good news is that I have 122mkII to play with, the bad news is that it doesn't work with the snd_usb_122l driver.
The probe function fails most likely in usb_stream_start(&us122l->sk),
The dmesg output:
... status=-2 status=-2 us122l_start error -14 snd-usb-us122l: probe of 1-2:1.1 failed with error -22 usbcore: registered new interface driver snd-usb-us122l ...
I've set up a windows machine with usbsnoop and captured the init log (I could upload it somewhere if anybody is interested). I would probably be able to help fix/write the driver with some guidance. Just now I'm trying to understand the log...
PS: I've send this mail to alsa-devel a couple of days ago, but without being subscribed, does anybody do the screening on incomming mails?
On Fri, Aug 19, 2011 at 12:01 PM, Cyril Hrubis metan.lists@gmail.com wrote:
Hi! The good news is that I have 122mkII to play with, the bad news is that it doesn't work with the snd_usb_122l driver.
IIRC, the 122mkII implements an entirely different USB protocol compared to its former version. Can you send your "lsusb -v" output?
Daniel
Hi!
The good news is that I have 122mkII to play with, the bad news is that it doesn't work with the snd_usb_122l driver.
IIRC, the 122mkII implements an entirely different USB protocol compared to its former version. Can you send your "lsusb -v" output?
Attached.
As far as I understand it, there are two endpoints for audio and two for MIDI. The MIDI part seems to be initalized fine although I don't have any MIDI device to test it.
And in the log from windows machine the audio part does some intialization and then only buch of isochronous transfers.
On Fri, Aug 19, 2011 at 1:37 PM, Cyril Hrubis metan.lists@gmail.com wrote:
Hi!
The good news is that I have 122mkII to play with, the bad news is that it doesn't work with the snd_usb_122l driver.
IIRC, the 122mkII implements an entirely different USB protocol compared to its former version. Can you send your "lsusb -v" output?
Attached.
Ok, nothing that even remotely looks like class compliant descriptors.
As far as I understand it, there are two endpoints for audio and two for MIDI. The MIDI part seems to be initalized fine although I don't have any MIDI device to test it.
And in the log from windows machine the audio part does some intialization and then only buch of isochronous transfers.
Hmm, so it seems that our only option is really to look at these Windows dumps and reverse-engineer the protocol.
Daniel
Hi!
As far as I understand it, there are two endpoints for audio and two for MIDI. The MIDI part seems to be initalized fine although I don't have any MIDI device to test it.
And in the log from windows machine the audio part does some intialization and then only buch of isochronous transfers.
Hmm, so it seems that our only option is really to look at these Windows dumps and reverse-engineer the protocol.
Looks so, anybody could lend a helping hand (or a good HOWTO), I'm still new to USB, kernel USB subsystem and alsa.
Hi!
And in the log from windows machine the audio part does some intialization and then only buch of isochronous transfers.
Hmm, so it seems that our only option is really to look at these Windows dumps and reverse-engineer the protocol.
Looks so, anybody could lend a helping hand (or a good HOWTO), I'm still new to USB, kernel USB subsystem and alsa.
Should be: "could anybody ... ?"
Am Freitag, den 19.08.2011, 13:46 +0200 schrieb Daniel Mack:
On Fri, Aug 19, 2011 at 1:37 PM, Cyril Hrubis metan.lists@gmail.com wrote:
[…]
As far as I understand it, there are two endpoints for audio and two for MIDI. The MIDI part seems to be initalized fine although I don't have any MIDI device to test it.
And in the log from windows machine the audio part does some intialization and then only buch of isochronous transfers.
Hmm, so it seems that our only option is really to look at these Windows dumps and reverse-engineer the protocol.
Is there a chance to talk to the manufacturer or are they known to not cooperate? Cyril, did you contact their support?
Thanks,
Paul
Hi!
As far as I understand it, there are two endpoints for audio and two for MIDI. The MIDI part seems to be initalized fine although I don't have any MIDI device to test it.
And in the log from windows machine the audio part does some intialization and then only buch of isochronous transfers.
Hmm, so it seems that our only option is really to look at these Windows dumps and reverse-engineer the protocol.
Is there a chance to talk to the manufacturer or are they known to not cooperate? Cyril, did you contact their support?
Hmm, haven't though of this, but that may be worth of try.
Hi!
As far as I understand it, there are two endpoints for audio and two for MIDI. The MIDI part seems to be initalized fine although I don't have any MIDI device to test it.
And in the log from windows machine the audio part does some intialization and then only buch of isochronous transfers.
Hmm, so it seems that our only option is really to look at these Windows dumps and reverse-engineer the protocol.
Is there a chance to talk to the manufacturer or are they known to not cooperate? Cyril, did you contact their support?
FYI: Wrote to their support more than a week ago and got no response so far.
Hi! But still there are some good news. I've examined the pcb a bit and the USB interface is ISP1583 connected to the ATmega162 which is driving DA converters. So at least there is a documentation for the USB chip. And there seems to be ISP header for ATmega programming. And the ATmega code may be ripped of their firmware update binaries. Looks like I'll have some fun.
participants (3)
-
Cyril Hrubis -
Daniel Mack -
Paul Menzel