[alsa-devel] snd-usb-audio for Radikal Technologies SAC-2K
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I'm working on getting the usb part of this very nice control surface to work with alsa. I sniffed the usb traffic of the windows driver then browsed the snd-usb-audio source code for clues.
I managed to get it partially working using a modified QUIRK_MIDI_EMAGIC since the protocols are fairly similar (at least the 0xF5 port switching part).
Please find attached the patch I came up to.
I have a few problems and dark areas I hope you'll be able to light up a little :
First, I more or less get the picture of what the code is doing but there's one part I fiddled with that I don't understand fully. What are the .out_cables and .in_cables bitmasks doing besides defining the number of ports ?
Next, the input part seem to work flawlessly on all ports, but I have what seems to be a buffer overflow on the device when outputting midi data. Comparing the windows and linux usb traffic, something obvious shows up : the windows driver seem to be waiting for the device's acknowledgment after each sent byte before sending the next one while the snd-usb-audio module sends a bunch of bytes at once that ends up confusing the device _and_ module. How can I make it behave like the windows driver ?
I have traffic and error logs available if needed.
Thanks. - -- Raphaël Doursenaud http://raphael.doursenaud.fr
Raphaël Doursenaud wrote:
First, I more or less get the picture of what the code is doing but there's one part I fiddled with that I don't understand fully. What are the .out_cables and .in_cables bitmasks doing besides defining the number of ports ?
The also define the port numbers.
Next, the input part seem to work flawlessly on all ports, but I have what seems to be a buffer overflow on the device when outputting midi data. Comparing the windows and linux usb traffic, something obvious shows up : the windows driver seem to be waiting for the device's acknowledgment after each sent byte before sending the next one while the snd-usb-audio module sends a bunch of bytes at once that ends up confusing the device _and_ module.
Do you mean that the Windows driver does not submit more than one URB at once? And that it never puts more than one byte for a port into one packet? Is it possible that the device want a F5 port number at the beginning of every packet?
Anyway, all bulk packets must be explicitly accepted by a device, so if the SAC-2K accepts a packet and then does something wrong, it's the device's fault.
To force the driver to submit no more than one packet at once, replace OUTPUT_URBS with a variable and set it to 1 for this device.
Regards, Clemens
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le 20/10/2010 11:29, Clemens Ladisch a écrit :
Raphaël Doursenaud wrote:
First, I more or less get the picture of what the code is doing but there's one part I fiddled with that I don't understand fully. What are the .out_cables and .in_cables bitmasks doing besides defining the number of ports ?
The also define the port numbers.
Could you be more explicit ? What's the format ? How is it interpreted ? I just don't have a clue of how it works, I just set it by trial and errors… Not really good.
Next, the input part seem to work flawlessly on all ports, but I have what seems to be a buffer overflow on the device when outputting midi data. Comparing the windows and linux usb traffic, something obvious shows up : the windows driver seem to be waiting for the device's acknowledgment after each sent byte before sending the next one while the snd-usb-audio module sends a bunch of bytes at once that ends up confusing the device _and_ module.
Do you mean that the Windows driver does not submit more than one URB at once? And that it never puts more than one byte for a port into one packet? Is it possible that the device want a F5 port number at the beginning of every packet?
AFAIK the F5 pn is only sent once. Everything seems good to that respect.
Anyway, all bulk packets must be explicitly accepted by a device, so if the SAC-2K accepts a packet and then does something wrong, it's the device's fault.
To force the driver to submit no more than one packet at once, replace OUTPUT_URBS with a variable and set it to 1 for this device.
I've investigated with OUTPUT_URBS set to "1" and while the transfer pattern now looks like the windows one, the device still reacts the same.
Please find the wireshark sniffed USB transfers playing the same MIDI file from both midi-ox on windows under QEMU and aplaymidi on linux at : http://raphael.doursenaud.fr/wp-content/uploads/Midi-file-playing-windows.tx... http://raphael.doursenaud.fr/wp-content/uploads/Midi-file-playing-linux.txt
See how the transfers look the same until the device throws a "FE0100" message at frame 88. From there the device goes wild blinking and displaying a cryptic error message on its numerical display and stops outputting midi signal. If playing long enough, the module throws "MIDI output buffer overrun" messages before the device disconnects to finally error and lock with that :
seq_lock: timeout [1 left] in sound/core/seq/seq_ports.c:263 rawmidi drain error (avail = 28, buffer_size = 4096) general protection fault: 0000 [#5] PREEMPT SMP last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host3/target3:0:0/3:0:0:0/block/sdf/sdf1/stat CPU 2 Modules linked in: snd_usb_audio snd_usbmidi_lib blackmagic(P) [last unloaded: snd_usbmidi_lib]
Pid: 27, comm: khubd Tainted: P D 2.6.36-rc8 #1 EP35C-DS3R/EP35C-DS3R RIP: 0010:[<ffffffff8162d35f>] [<ffffffff8162d35f>] clear_subscriber_list+0x19f/0x200 RSP: 0018:ffff88011fe3d890 EFLAGS: 00010246 RAX: ffff8800c0910a80 RBX: ffff8800c68afb40 RCX: dead000000100100 RDX: dead000000200200 RSI: 0000000000000282 RDI: ffff8800c0910a80 RBP: ffff8800c0910a00 R08: 0000000000000000 R09: dead000000100100 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800c0aa62b8 R13: 0000000000000001 R14: ffff8800c0aa62b8 R15: ffff8800c0aa6200 FS: 0000000000000000(0000) GS:ffff880001f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007fb37da18000 CR3: 000000011ddc9000 CR4: 00000000000006f0 DR0: 0000000000000003 DR1: 00000000000000b0 DR2: 0000000000000001 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process khubd (pid: 27, threadinfo ffff88011fe3c000, task ffff88011fe3b8d0) Stack: ffff88011fe3d8f0 ffff8800c0910a80 ffff8800c0910a68 ffff88011bbd1880 <0> ffff88011bab0c00 ffff88011b2a9cc0 ffffffff819a94c3 ffff8800c0aa6200 <0> ffff88011bbd1880 0000000000000002 ffff88011bab0c50 0000000000000006 Call Trace: [<ffffffff8162d410>] ? port_delete+0x50/0x80 [<ffffffff81628f1c>] ? snd_seq_ioctl_delete_port+0x4c/0x70 [<ffffffff81625e60>] ? snd_seq_kernel_client_ctl+0x60/0x70 [<ffffffff8162c940>] ? snd_seq_event_port_detach+0x30/0x40 [<ffffffff81633ae8>] ? snd_seq_midisynth_delete+0x18/0x40 [<ffffffff81633ba3>] ? snd_seq_midisynth_unregister_port+0x93/0x120 [<ffffffff8162dd64>] ? free_device+0x34/0xb0 [<ffffffff8162e3b5>] ? snd_seq_device_dev_disconnect+0x35/0x50 [<ffffffff816068e2>] ? snd_device_disconnect+0x42/0x80 [<ffffffff81606954>] ? snd_device_disconnect_all+0x34/0x60 [<ffffffff816019af>] ? snd_card_disconnect+0x19f/0x230 [<ffffffffa002117c>] ? usb_audio_disconnect+0xac/0x1c0 [snd_usb_audio] [<ffffffff8155bdb4>] ? usb_unbind_interface+0xc4/0x120 [<ffffffff814d0560>] ? __device_release_driver+0x60/0xd0 [<ffffffff814d06a5>] ? device_release_driver+0x25/0x40 [<ffffffff814cf7ad>] ? bus_remove_device+0x9d/0xe0 [<ffffffff814cd720>] ? device_del+0x120/0x1c0 [<ffffffff8155945a>] ? usb_disable_device+0x9a/0x120 [<ffffffff815530db>] ? usb_disconnect+0x8b/0x130 [<ffffffff815531d9>] ? hub_quiesce+0x59/0xc0 [<ffffffff8155325a>] ? hub_pre_reset+0x1a/0x30 [<ffffffff81554135>] ? usb_reset_device+0x45/0x160 [<ffffffff81555072>] ? hub_thread+0xcd2/0x10e0 [<ffffffff810618af>] ? dequeue_task_fair+0x4f/0x190 [<ffffffff81082ac0>] ? autoremove_wake_function+0x0/0x30 [<ffffffff815543a0>] ? hub_thread+0x0/0x10e0 [<ffffffff815543a0>] ? hub_thread+0x0/0x10e0 [<ffffffff81082646>] ? kthread+0x96/0xa0 [<ffffffff8102ad94>] ? kernel_thread_helper+0x4/0x10 [<ffffffff810825b0>] ? kthread+0x0/0xa0 [<ffffffff8102ad90>] ? kernel_thread_helper+0x0/0x10 Code: 48 89 44 24 10 48 8d 85 80 00 00 00 48 89 c7 48 89 44 24 08 e8 23 d3 15 00 48 8b 4b 50 48 8b 53 58 49 b9 00 01 10 00 00 00 ad de <48> 89 51 08 49 b8 00 02 20 00 00 00 ad de 48 89 0a 4c 89 4b 50 RIP [<ffffffff8162d35f>] clear_subscriber_list+0x19f/0x200 RSP <ffff88011fe3d890> - ---[ end trace 4d12c4e83f4f7bf8 ]--- seq_lock: timeout [1 left] in sound/core/seq/seq_clientmgr.c:277
I'm scratching my head now… Any clues on what might be going on ?
Thanks !
- -- Raphaël Doursenaud http://raphael.doursenaud.fr
participants (2)
-
Clemens Ladisch -
Raphaël Doursenaud