Zoom R16/24 playback slient

Zoom R16/24 playback slient

[Ricard Wanderlof]

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?

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?

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

/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

Re: 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
>

Re: 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Zoom R16/24 playback slient

[Panu Matilainen]

On 09/30/2015 11:05 AM, Ricard Wanderlof wrote:
>
> 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.

I do have an usb dump of Windows initializing the thing and can/will 
share and/or generate new ones if you/others want to have a look. It 
hasn't helped me so far, problem being I dont really know what to look 
for in the first place.

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

IIRC you start getting hangs accompanied with "cannot get/set freq XXX 
to ep Y" (or similar) messages when you try to open both. For a single 
interface at a time, those messages went away by adding the small delay, 
but adding more delay doesn't help with the case where both are active.

So to me the evidence seems to suggest it only supports a global 
frequency for the device, instead of per interface. Which, considering 
what the device is, seems quite reasonable.

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

Cool.

	- Panu -

>
> /Ricard
>

Re: Zoom R16/24 playback slient

[Panu Matilainen]

On 09/30/2015 11:05 AM, Ricard Wanderlof wrote:
>
> On Wed, 30 Sep 2015, Panu Matilainen wrote:
[...]
>> 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.

Forgot to clarify this: I actually thought the silent playback was the 
only remaining issue when submitting the patch, but later realized I 
only ever had one of the interfaces enabled at a time to avoid any 
side-effects, and apparently never bothered to check with both since the 
playback was not really working anyway.

	- Panu -

Re: Zoom R16/24 playback slient

[Ricard Wanderlof]

On Wed, 30 Sep 2015, Panu Matilainen wrote:

> I do have an usb dump of Windows initializing the thing and can/will 
> share and/or generate new ones if you/others want to have a look. It 
> hasn't helped me so far, problem being I dont really know what to look 
> for in the first place.

Although I doubt I'll be able to make more sense of it than you, it would 
be interesting to have a look at, perhaps it can be useful.

What might also be interesting if you don't already have a dump of it is 
Windows actually starting a playback stream.

> IIRC you start getting hangs accompanied with "cannot get/set freq XXX 
> to ep Y" (or similar) messages when you try to open both. For a single 
> interface at a time, those messages went away by adding the small delay, 
> but adding more delay doesn't help with the case where both are active.
> 
> So to me the evidence seems to suggest it only supports a global 
> frequency for the device, instead of per interface. Which, considering 
> what the device is, seems quite reasonable.

Yes, I agree.

/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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Zoom R16/24 playback slient

[Ricard Wanderlof]

On Wed, 30 Sep 2015, Panu Matilainen wrote:

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

I did a small bit of experimenting, and as far as I can tell, playback 
seems to hang the device so it becomes completely unresponsive and needs 
to be restarted.

What I did was change QUICK_IGNORE_INTERFACE to 
QUIRK_AUDIO_STANDARD_INTERFACE for ifnum 1 (playback) in the quirks table.

What happens here is that if I attmempt to aplay a file that is 10.5 
seconds long, it actually plays for about 16 seconds, but no sound comes 
out. If I attempt it again, it takes about 5 seconds, after which I get 
aplay: set_params:1297: Unable to install hw params: <dump of attempted 
parameter settings>. There is no error message the first time.

The problem is the same no matter if I have IGNORE_INTERFACE set for ifnum 
2 (capture) or not. Setting both ifnum 1 and 2 to AUDIO_STANDARD_INTERFACE 
still results in capture to work as expected.

Interestingly enough, if I instrument the call to pcm:set_params(), it 
seems to get called as soon as the device is plugged in, with no ill 
effects. The sample rate display on the R16 also changes from 96.0 kHz to 
44.1 kHz. I don't seem to remember it doing this the first times I plugged 
it in, but the behavior remains after rebooting my computer, so it doesn't 
seem to be anything cached or something like that.

The problem doesn't seem to be in set_params(), as I can tell by adding 
delays that the unit freezes well after calling this function.

/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

Re: Zoom R16/24 playback slient

[Ricard Wanderlof]

On Wed, 30 Sep 2015, Ricard Wanderlof wrote:

> I did a small bit of experimenting, and as far as I can tell, playback 
> seems to hang the device so it becomes completely unresponsive and needs 
> to be restarted.

Actually, after a bit more experimenting, the R16 actually wakes up from 
its unresponsive state after a couple of minutes, at least when playing a 
small file. After that it seems to behave as before.

I'm learning USB and USB-audio at the same time so progress is slow.

Installed the Zoom Windows driver on a Win7 box, followed by the bundled 
DAW software (Cubase 6 LE), in order to dump the USB data to see what was 
going on, using USBPcap.

Captured the corresponding traffic in Linux using usbmon and Wireshark.

I transferred the Windows pcap dumps to Linux for subsequent analysis in 
Wireshark.

It was getting late so I didn't do more than a cursory look. I noted that 
the packet format is very different between Windows and Linux, but if 
that's due to the different capture methods I don't know. For the USBPcap 
dump each Isochronous frame contains a number of isochronous packets, 
whereas the dump I do on Linux just lists the payload as 'captured 
isochronous data' or somesuch. Even basic things such as the packet 
lengths don't match, but I also noted that USBPcap seems to insert 
metadata into the frames (to ease decoding?) Got to research that more.

I did conclude however that when playing back to the R16 there seems to be 
an isochronous packet flow going on with data from both ends of the 
link (again, I need to read up what really to expect). What is odd is that 
in Linux, the final packet from the host is a SET CONFIGURATION, and the 
R16 seems to take about 5 seconds to respond to it. I thought 5 seconds 
was supposed to be a general timeout when waiting for responses in USB, 
not the maximum time before a device can respond. But perhaps the R16 
thinks it's in a mode where it's expecting more data from the host and 
thus times out when receiving a request its not expecting and actually 
goes ahead and processes the same request.

My next step may be to use USBPcap to capture the data in Linux too so I 
get comparable dumps. And do read up on USB audio documentation...

/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

Re: Zoom R16/24 playback slient

[Ricard Wanderlof]

On Wed, 30 Sep 2015, Panu Matilainen wrote:

> >>>> At Sat, 29 Nov 2014 21:35:04 +0200,
> >>>> Panu Matilainen wrote:
> >>>>>
> >>> 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?

I was looking at this, and comparing it to the corresponding output from 
my Edirol UA-5, which is a class-complient (in its standard mode) 2 in / 2 
out device. The descriptors look suspiciously similar on both devices, 
especially considering that the R16 has 8 channels of input instead of 2 
and a MIDI interface which the UA-5 lacks.

I'm not sure exactly which version of the USB audio standard they 
correspond to, looking at the specifications for versions 1 and 2 it 
didn't seem to make sense, but they do happen to correspond very much to 
the descriptions in the following document:

https://www.silabs.com/Support%20Documents/TechnicalDocs/AN295.pdf

The fact that lsusb doesn't recognize them I would think boils down to the 
fact that it simply doesn't know about USB audio; it appears that the ALSA 
USB driver can make sense of the information, which is why the resulting 
entry in the quirks table doesn't need a FIXED_ENDPOINT quirk.

/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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Zoom R16/24 playback slient

[Panu Matilainen]

On 10/06/2015 09:47 AM, Ricard Wanderlof wrote:
>
> On Wed, 30 Sep 2015, Panu Matilainen wrote:
>
>>>>>> At Sat, 29 Nov 2014 21:35:04 +0200,
>>>>>> Panu Matilainen wrote:
>>>>>>>
>>>>> 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?
>
> I was looking at this, and comparing it to the corresponding output from
> my Edirol UA-5, which is a class-complient (in its standard mode) 2 in / 2
> out device. The descriptors look suspiciously similar on both devices,
> especially considering that the R16 has 8 channels of input instead of 2
> and a MIDI interface which the UA-5 lacks.
>
> I'm not sure exactly which version of the USB audio standard they
> correspond to, looking at the specifications for versions 1 and 2 it
> didn't seem to make sense, but they do happen to correspond very much to
> the descriptions in the following document:
>
> https://www.silabs.com/Support%20Documents/TechnicalDocs/AN295.pdf
>
> The fact that lsusb doesn't recognize them I would think boils down to the
> fact that it simply doesn't know about USB audio; it appears that the ALSA
> USB driver can make sense of the information, which is why the resulting
> entry in the quirks table doesn't need a FIXED_ENDPOINT quirk.

lsusb knows about USB audio alright, the problem is all these stupid 
vendors tagging their devices and their interfaces as vendor specific, 
even if when actually are class compliant. Which is why the quirks-table 
is needed: QUIRK_AUDIO_STANDARD_INTERFACE just tells the driver to parse 
the descriptor as a standard audio interface despite it claiming to be 
vendor specific. But lsusb doesn't have access to the quirks table.

	- Panu -

>
> /Ricard
>

Re: Zoom R16/24 playback slient

[Panu Matilainen]

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 -

Re: Zoom R16/24 playback slient

[Ricard Wanderlof]

On Tue, 6 Oct 2015, Panu Matilainen wrote:

> >>>>>> At Sat, 29 Nov 2014 21:35:04 +0200,
> >>>>>> Panu Matilainen wrote:
> >>>>>>>
> >>>>> ** 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?
> >>>>>
> 
> lsusb knows about USB audio alright, the problem is all these stupid 
> vendors tagging their devices and their interfaces as vendor specific, 
> even if when actually are class compliant. Which is why the quirks-table 
> is needed: QUIRK_AUDIO_STANDARD_INTERFACE just tells the driver to parse 
> the descriptor as a standard audio interface despite it claiming to be 
> vendor specific. But lsusb doesn't have access to the quirks table.

That makes sense, however, I seem to recall (will double check tonight) 
that lsusb still output UNRECOGNIZED for the corresponding descriptors 
even when the UA-5 was set to its class complient mode.

I'd have to do more research, but it would seem that the above decriptors 
match something other than the USB audio version 1 or 2 specs, whatever 
that might be.

Part of the decoding I found was:
(partly with reference to
https://www.silabs.com/Support%20Documents/TechnicalDocs/AN295.pdf)


** UNRECOGNIZED:  0b 24 01 00 01 35 00 03 01 02 03
                        -- ----  ----- -- --------
                        |  |       |    |     +---- device nos (cap,pb,midi)
                        |  |       |    +---------- no of devices
		        |  |       +--------------- total descriptors length
                        |  +----------------------- bcdADC (0x0001) ?
                        +-------------------------- subtype HEADER

** UNRECOGNIZED:  0c 24 02 05 01 01 00 02 03 00 00 00
                        -- -- -----    -- -----
                        |  |   |       |     +------ channel placement (L,R)
                        |  |   |       +------------ no of channels
                        |  |   +-------------------- terminal type? (output)
                        |  +------------------------ terminal ID (5)
                        +--------------------------- streaming terminal descr.
                                   
** UNRECOGNIZED:  09 24 03 08 01 03 00 05 00

** UNRECOGNIZED:  0c 24 02 09 01 02 00 08 00 00 00 00
                        -- -- -----    -- -----
                        |  |   |       |     +------ channel placement (none)
                        |  |   |       +------------ no of channels
                        |  |   +-------------------- terminal type? (input)
                        |  +------------------------ terminal ID (9)
                        +--------------------------- streaming terminal descr.

** UNRECOGNIZED:  09 24 03 0c 01 01 00 09 00

and further down in the dump (after the interface descriptor for the output
interface)

** UNRECOGNIZED:  07 24 01 05 01 01 00
                        -- -- -- -----
                        |  |  |    +-------- format tag (0x0100 = PCM)
                        |  |  +------------- bDelay
                        |  +---------------- terminal link?
                        +------------------- subtype AS_GENERAL
                           
** UNRECOGNIZED:  14 24 02 01 02 04 18 04 44 ac 00 80 bb 00 88 58 01 00 77 01
                           -- -- -- -- -- -------- -------- -------- --------
                           |  |  |  |  |  44.1 kHz  48 kHz  88.2 kHz  96 kHz
                           |  |  |  |  |
                           |  |  |  |  +--- no of sample rate specifications
                           |  |  |  +------ bit resolution (24 bits)
                           |  |  +--------- subframe size (4 bytes)
                           |  +------------ no of channels (2)
                           +--------------- format type (TYPE_I)

and for the input interface:

** UNRECOGNIZED:  07 24 01 0c 01 01 00
                        -- -- -- -----
                        |  |  |    +-------- format tag (0x0100 = PCM)
                        |  |  +------------- bDelay
                        |  +---------------- terminal link?
                        +------------------- subtype AS_GENERAL

** UNRECOGNIZED:  14 24 02 01 08 04 18 04 44 ac 00 80 bb 00 88 58 01 00 77 01
                           -- -- -- -- -- -------- -------- -------- --------
                           |  |  |  |  |  44.1 kHz  48 kHz  88.2 kHz  96 kHz
                           |  |  |  |  |
                           |  |  |  |  +--- no of sample rate specifications
                           |  |  |  +------ bit resolution (24 bits)
                           |  |  +--------- subframe size (4 bytes)
                           |  +------------ no of channels (8)
                           +--------------- format type (TYPE_I)

What doesn't make sense to me here is that certain subtypes seem to be 
reused for different purposes even with the same descriptor type, for 
instance descriptor type 24 has subtype 02 being used to specify terminal 
type and also the data format. Perhaps the length is also a part of the 
type specifier?

While this could all be vendor specific based on a standard but only 
loosely following it, when attempting the same interpretation on the 
corresponding lsusb -v output from the Edirol UA-5, they correspond 
perfectly, given the differences in the devices (for instance, the UA-5 
only runs at a single sample rate governed by a front panel switch, and in 
its class-complient mode uses 2 bytes per sample with 16 bit resolution, 
and in its advanced mode uses 3 bytes per sample with 24 bit resolution) 
so apparently they are based on the same standard, whatever that may be.

Perhaps someone can point in the right direction to some standards 
document, for now, my main interest is getting the playback streaming 
going, and since QUIRK_AUDIO_STANDARD_INTERFACE seems to suffice in order 
to grab the format information, it is apparent that the ALSA USB layer 
understands the information at least sufficiently for its purpose, so I 
don't really intend to dive deeper into the descriptor interpretation for 
now. Most importantly, it confirms that the correct audio format is 24 
bits in a 32 bit word.

/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

Re: Zoom R16/24 playback slient

[Ricard Wanderlof]

On Tue, 6 Oct 2015, Panu Matilainen wrote:

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

Yes, a proof-of-concept is needed, and there may be further issues, but 
I'm hoping for some input too from the 'more experienced people' if this 
is the right way to go about it before I go to far in the wrong direction.

/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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Zoom R16/24 playback slient

[Panu Matilainen]

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 -

Re: Zoom R16/24 playback slient

[Ricard Wanderlof]

On Tue, 6 Oct 2015, Panu Matilainen wrote:

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

I tried this out yesterday, with good results. I only had time for limited 
testing, but I managed to playback a couple of 44.1 kHz files (didn't test 
anything else) without any hitches. So this is definitely the right way to 
go. Actually it was a real joy after the R16 has been silent for a week. 
:-)

Apart from prepare_playback_urb(), I had to make a similar change to 
endpoint.c:prepare_outound_urb() which outputs silence before there is 
data to send.

Patch to follow, but there are a couple of things I need to straighten out 
first:

- Since we're stuffing more data in the outgoing packets, some allowance 
  must be made for this when allocating the urb->transfer_buffer. I've got 
  to review that code so that we don't spill over the end of the allocated 
  buffer in some case.
- The best way to trigger the quirk. I'm thinking something along the
  lines of introducing a QUIRK_AUDIO_ZOOM_INTERFACE which enables the
  aforementioned bit in order to enable the quirk in 
  prepare_playback_urb() and prepare_output_urb(), and then calls
  create_standard_audio_quirk() (just as QUIRK_AUDIO_STANDARD_INTERFACE
  would have resulted in). Then it's clear in quirks-table.h that 
  something special is going on. (Currently I've added the quirk 
  initialization directly in create_standard_audio_quirk(), but it seems 
  wrong to hide it away in there).

And I also need to test some more.

Also, in the dump from the Windows driver I saw some form of sample rate 
control message being sent that Linux doesn't send, on the other hand, 
that was sent as part of starting capture, which already has been proven 
to work, so it might simply not be needed.

/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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Zoom R16/24 playback slient

[Panu Matilainen]

On 10/07/2015 10:53 AM, Ricard Wanderlof wrote:
>
> On Tue, 6 Oct 2015, Panu Matilainen wrote:
>
>>> 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)
>>>
>>> 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...
>
> I tried this out yesterday, with good results. I only had time for limited
> testing, but I managed to playback a couple of 44.1 kHz files (didn't test
> anything else) without any hitches. So this is definitely the right way to
> go. Actually it was a real joy after the R16 has been silent for a week.
> :-)

Awesome! This will make you a hero for many :)

>
> Apart from prepare_playback_urb(), I had to make a similar change to
> endpoint.c:prepare_outound_urb() which outputs silence before there is
> data to send.
>
> Patch to follow, but there are a couple of things I need to straighten out
> first:
>
> - Since we're stuffing more data in the outgoing packets, some allowance
>    must be made for this when allocating the urb->transfer_buffer. I've got
>    to review that code so that we don't spill over the end of the allocated
>    buffer in some case.
> - The best way to trigger the quirk. I'm thinking something along the
>    lines of introducing a QUIRK_AUDIO_ZOOM_INTERFACE which enables the
>    aforementioned bit in order to enable the quirk in
>    prepare_playback_urb() and prepare_output_urb(), and then calls
>    create_standard_audio_quirk() (just as QUIRK_AUDIO_STANDARD_INTERFACE
>    would have resulted in). Then it's clear in quirks-table.h that
>    something special is going on. (Currently I've added the quirk
>    initialization directly in create_standard_audio_quirk(), but it seems
>    wrong to hide it away in there).

Clearly the device not following standard here, but then all sorts of 
other quirks get silently handled behind the scenes of 
QUIRK_AUDIO_STANDARD_INTERFACE too so... If handled in 
create_standard_audio_quirk() then the quirks-table entry for the thing 
could be reduced to just:

.driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) {
         .ifnum = QUIRK_ANY_INTERFACE,
         .type = QUIRK_AUTODETECT
}

Not that it matters a whole lot I guess.

>
> And I also need to test some more.

I'd be happy to help with testing + extra eyeballs for any 
work-in-progress patch you have. Feel free to send privately if you feel 
its not suitable for mass-consumption yet.

>
> Also, in the dump from the Windows driver I saw some form of sample rate
> control message being sent that Linux doesn't send, on the other hand,
> that was sent as part of starting capture, which already has been proven
> to work, so it might simply not be needed.

Right, good to know. While capture appears to work just fine, I wouldn't 
be surprised if there are glitches left, its probably not being used all 
that much because of the dead playback (until now of course).

	- Panu -

>
> /Ricard
>

Re: Zoom R16/24 playback slient

[Keith A. Milner]

On Tuesday 06 Oct 2015 10:16:05 Ricard Wanderlof wrote:

> What doesn't make sense to me here is that certain subtypes seem to be
> reused for different purposes even with the same descriptor type, for
> instance descriptor type 24 has subtype 02 being used to specify terminal
> type and also the data format. Perhaps the length is also a part of the
> type specifier?
> 

My reading of it is that the meaning of the CS_INTERFACE subtype is context 
specific, so it depends where in the descriptor it appears.

Cheers,

Keith