[alsa-devel] Zoom R16/24 playback slient

[Ricard Wanderlof]

On Wed, 30 Sep 2015, Panu Matilainen wrote:

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

Ah, I should have guessed as much... (I was looking in the kernel for some 
USB debug thing via /sys or similar).

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

I wonder if any information could be gleaned from running the Windows 
driver and somehow snooping the USB bus.

There must be some way of enabling the playback stream.

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

I think that many devices put 24 bits in the most significant bits of a 32 
bit word, hence SNDRV_PCM_FMTBIT_S32 works fine, and the device simply 
disregards the lowest 8 bits. I don't know about USB, but I've come across 
SoC devices where it is the lower 24 bits that carry the data, in which 
case SNDRV_PCM_FMTBIT_S24LE is needed, and then there are devices which 
really handle the data in 24 bit chunks, using SNDRV_PCM_FMTBIT_S24_3LE.

At any rate this issue seems to be cleared up.

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

Ok, thanks for that tidbit, I'd read about problems with simulatenous 
capture and playback in previous threads; I thought perhaps (hopefully...) 
the only remaining issue was the silent playback.

> 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;

So your theory is that reconfiguring the device once opened for one 
direction is what causes it to hang?

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

I understand. Since I have a setup at home that works now I thought I'd 
take a look at it and see how far I get.

/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