On Wed, 30 Sep 2015, Ricard Wanderlof wrote:
I did a small bit of experimenting, and as far as I can tell, playback seems to hang the device so it becomes completely unresponsive and needs to be restarted.
Actually, after a bit more experimenting, the R16 actually wakes up from its unresponsive state after a couple of minutes, at least when playing a small file. After that it seems to behave as before.
I'm learning USB and USB-audio at the same time so progress is slow.
Installed the Zoom Windows driver on a Win7 box, followed by the bundled DAW software (Cubase 6 LE), in order to dump the USB data to see what was going on, using USBPcap.
Captured the corresponding traffic in Linux using usbmon and Wireshark.
I transferred the Windows pcap dumps to Linux for subsequent analysis in Wireshark.
It was getting late so I didn't do more than a cursory look. I noted that the packet format is very different between Windows and Linux, but if that's due to the different capture methods I don't know. For the USBPcap dump each Isochronous frame contains a number of isochronous packets, whereas the dump I do on Linux just lists the payload as 'captured isochronous data' or somesuch. Even basic things such as the packet lengths don't match, but I also noted that USBPcap seems to insert metadata into the frames (to ease decoding?) Got to research that more.
I did conclude however that when playing back to the R16 there seems to be an isochronous packet flow going on with data from both ends of the link (again, I need to read up what really to expect). What is odd is that in Linux, the final packet from the host is a SET CONFIGURATION, and the R16 seems to take about 5 seconds to respond to it. I thought 5 seconds was supposed to be a general timeout when waiting for responses in USB, not the maximum time before a device can respond. But perhaps the R16 thinks it's in a mode where it's expecting more data from the host and thus times out when receiving a request its not expecting and actually goes ahead and processes the same request.
My next step may be to use USBPcap to capture the data in Linux too so I get comparable dumps. And do read up on USB audio documentation...
/RIcard