Re: Zoom R16/24 playback slient

[Panu Matilainen <pmatilai@laiskiainen.org>]

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 -