On 10/06/2015 10:02 AM, Ricard Wanderlof wrote:
On Wed, 30 Sep 2015, Panu Matilainen wrote:
My memory is a bit hazy on the details, but the automatically detected SNDRV_PCM_FMTBIT_S32 (which iirc means the actual 24bit values are carried in 32bit chunks) seems to be the right thing for the device, forcing it to something else just makes things worse. IIRC. The delay was a key part, but not enough.
Another finding from my last round in the spring I do remember clearly, is that enabling both the input and output interfaces makes things hang up (timeouts and nothing really works). But if you disable the input interface and enable the output interface, you get an apparently working playback stream. Only no sound comes out. If you disable the output and enable input, capture itself works fine.
Having dived into this, and looking carefully at the data produced by the Windows driver, it appears that what's happening is that the driver stuffs a 32-bit length specifier at the start of each isochronous data packet.
So, for instance, instead of transferring the sample data
00 12 bf 34 00 98 87 76 00 3c 24 35 00 86 75 64 .. .. (40 bytes)
the Zoom driver would send:
28 00 00 00 00 12 bf 34 00 98 87 76 00 3c 24 35 00 86 75 64 ... (44 bytes)
No wonder the Zoom gets confused when it gets sent ordinary sample data, and tries to interpret the first sample value as a length.
There doesn't seem to be anything in the ALSA USB driver to do this, and I'm thinking it's Zoom specific (perhaps to overcome some deficiency in the hardware (or USB firmware) in the R16?).
FWIW, while poking around the source I spotted this in sound/usb/midi.c:
/* * Novation USB MIDI protocol: number of data bytes is in the first byte * (when receiving) (+1!) or in the second byte (when sending); data begins * at the third byte. */
Just goes to show such quirks are not previously unheard-of. It's MIDI so the details differ, but perhaps a similar approach could be used for PCM too.
- Panu -