[alsa-devel] Zoom R16/24 playback slient

[Ricard Wanderlof]

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?).

I'm trying to figure out where would be the best place to add a quirk for 
this. Input from anyone knowledgeable about the ALSA USB system would be 
very helpful.

At the moment I'm considering adding some additional code to 
sound/usb/pcm.c: prepare_playback_urb(), governed by a new boolean in 
struct snd_usb_substream in a similar vain as txfr_quirk in that structure 
(which in turn is set in some quirk function detecting the R16).

What needs to be done is to add 4 bytes to the length, and adjust the 
offset accordingly, in urb->iso_frame_desc[i], and then add the additional 
length descriptor for each packet when copying out the data further down 
in the same function.

It would be nice to add a foo_quirk() function but since the actual 
copying of the data needs to be changed, it's not really possible to do 
efficiently with a separate routine.

/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