[alsa-devel] Zoom R16/24 playback slient
Ricard Wanderlof
ricard.wanderlof at axis.com
Tue Oct 6 10:16:05 CEST 2015
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
More information about the Alsa-devel
mailing list