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)
Wow, nice detective work! :)
No wonder the Zoom gets confused when it gets sent ordinary sample data, and tries to interpret the first sample value as a length.
Heh, indeed.
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.
Sounds like a plan to me, but keep in mind I'm just another newbie in all this. Anyway, I wouldn't worry about cleanest possible way at this point, just do a quick-n-dirty hack to see if adding the length is enough to get it working and worry about the rest later. I'll try to have a look at it too as soon as time permits, but meanwhile if more experienced people have better suggestions...
- Panu -