[alsa-devel] Zoom R16/24 playback slient

[Ricard Wanderlof]

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
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30