[alsa-devel] Zoom R16/24 playback slient

[Panu Matilainen]

On 09/29/2015 11:19 PM, Ricard Wanderlof wrote:
>
> Bringing up an old thread from 2014 since I've gotten access to a Zoom R16
> and am keen on getting it to work in full duplex under Linux. Apparently
> (not yet verified here yet, rebuilding a kernel with the patch applied at
> the moment), 8 channel capture works with the quirk, but playback doesn't
> (well, it appears to work, but no sound comes out) and neither does the
> mixer.
>
>> At Sun, 30 Nov 2014 12:08:38 +0200,
>> Panu Matilainen wrote:
>>>
>>> On 11/29/2014 09:39 PM, Takashi Iwai wrote:
>>>> At Sat, 29 Nov 2014 21:35:04 +0200,
>>>> Panu Matilainen wrote:
>>>>>
>>>>> This makes the midi interface and capture work out of the box with
>>>>> R16 (and presumably R24 too but untested). Playback stream would also
>>>>> seem to function fine except for one caveat: no sound is produced,
>>>>> so it is disabled for now.
>>>
>>> [ ... ]
>>>
>>> In the meanwhile I started looking at the mixer - this is just guessing
>>> but maybe its starting with outputs muted which could explain the
>>> playback stream running but without sound.
>>>
>>> The descriptors for interface 0 are garbage but what is there would seem
>>> to map to logical elements by subtype and terminaltype, after those the> > data doesn't seem to add up (eg number of input/output channels
>>> missing/wrongly placed etc):
>>>
>>> ** UNRECOGNIZED:  0b 24 01 00 01 35 00 03 01 02 03
>>>      -> Header?
>>> ** UNRECOGNIZED:  0c 24 02 05 01 01 00 02 03 00 00 00
>>>      -> USB streaming input terminal?
>>> ** UNRECOGNIZED:  09 24 03 08 01 03 00 05 00
>>>      -> Speaker output terminal?
>>> ** UNRECOGNIZED:  0c 24 02 09 01 02 00 08 00 00 00 00
>>>      -> Microphone input terminal?
>>> ** UNRECOGNIZED:  09 24 03 0c 01 01 00 09 00
>>>      -> USB streaming output terminal?
>>>
>>> Anything there that might ring a bell, or other ideas where to start
>>> poking at this thing?
>>
>> Yeah, most of these look almost sane, so any off-by-one firmware
>> issue?
>
> Searching the archives, I could find no further posts on the subject of
> the R16. Panu, did you do any more work on this?

I did, but haven't gotten the playback to work (otherwise I would've 
sent a patch, obviously). Last five months have been a series of health 
issues for me so haven't had any energy left for poking at a stubbornly 
silent white box :)

> Where does the above output come from, and where could I find information
> on what type of data is expected? I assume what's expected is something
> one would get from an USB mixer device?

The output is simply 'lsusb -v' plus manually added guesses as to what 
these unrecognized bits are. The information is "out there", official 
USB documentation is valuable 
(http://www.usb.org/developers/docs/devclass_docs/) and looking at lsusb 
output of other similar products helps figure what might be there.

As for the mixer, I concluded the Zoom does not really have one. The 
interface 0 is a control interface where a mixer would reside, but 
there's no actual mixer unit in there.

> In an earlier incarnation of a patch for the R16 (on the 10th of March
> 2014), there's a discussion between Jason Mancine and Takashi regarding
> the .format field in the quirks table
> (http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/074117.html)
> which didn't seem to reach a conclusion; the problem then seemed to be
> that even when setting the .format to SNDRV_PCM_FMTBIT_S24_3LE, ALSA still
> setup up a 32 bit transfer. However, Panu's patch also added a small delay
> in snd_usb_ctl_msg_quirk(), so that perhaps was the real solution to the
> alleged format problem? (The final patch is much smaller than in this
> particular thread, possibly due to the use of QUIRK_ANY_INTERFACE since
> kernel version >3.11 ?)

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.

So perhaps it needs another quirk similar in spirit to the E-Mu:

         /* When capture is active
          * sample rate shouldn't be changed
          * by playback substream
          */
         if (subs->direction == SNDRV_PCM_STREAM_PLAYBACK) {
                 if 
(subs->stream->substream[SNDRV_PCM_STREAM_CAPTURE].interface != -1)
                         return;

Or something. I do intend to continue poking at it sooner or later but 
can't make any promises.


	- Panu -

>
> /Ricard
>