jmancine wrote
> I had made it as far as recognizing that the audio format was the culprit,
> but not specifically why. Strangely, I was told directly by Zoom that the
> playback for the device was fixed 24 bit integer. I suppose this is true
> from a certain perspective if it is 24-packed-in-32, but they didn't
> mention that :)
Thanks by the way for your research, it really did get me going on this, and
it (together with the rest of the posts in this thread) was a good starting
point for getting this to work.
Interesting though that you actually did get a reply from Zoom at all, I was
figuring they simply would not answer any questions at all on that level.
It could also be that they don't really know ... like the audio interface
part of the Zoom had been outsourced to someone (who also implemented the
weird length descriptor quirk), but that at least on the level that handles
support within Zoom they're not aware of it. My guess is that the playback
quirk was implemented to get around some deficiency in the USB hard- or
firmware that they use in the R16, e.g. that on some level, the hardware
doesn't present the packet lengths properly to the software, so they added
the quirk in order to work around that. But of course I don't know for sure.
I don't pretend to know exactly how it all fits together, but when doing an
'lsusb -v' with the Zoom connected in audio interface mode, one of the
things that gets presented is the following:
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 2
bInterfaceProtocol 0
iInterface 0
** UNRECOGNIZED: 07 24 01 05 01 01 00
** UNRECOGNIZED: 14 24 02 01 02 04 18 04 44 ac 00 80 bb 00 88 58 01
00 77 01
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 9
Transfer Type Isochronous
Synch Type Adaptive
Usage Type Data
wMaxPacketSize 0x006c 1x 108 bytes
bInterval 1
The second UNRECOGNIZED string actually specifies the audio format: the '02
04 18' means
'2 channels, 4 bytes per sample, 0x18 (=24) significant bits per sample'.
The corresponding string for the capture direction is:
** UNRECOGNIZED: 14 24 02 01 08 04 18 04 44 ac 00 80 bb 00 88 58 01 00 77
01
where the '08 04 18' means '8 channels, 4 bytes per sample, 24 bits per
sample'
The '04 44 ac 00 ...' that follows indicates '4 sample rates: 44.1 kHz, 48
kHz, 88.2 kHz, 96 kHz'
(44 ac 00 is 44100 in 3 byte little endian format).
I think the reason that lsusb doesn't interpret this is because the Zoom
presents itself as a 'Vendor Specific' device; some of the the descriptors
are dependent on each other, so unless the device says it's a class
compliant audio device lsusb can't decipher it properly.
I ran some tests with an Edirol UA-5, for reference. In it's 'advanced' mode
it is not class compliant, and it presents itself as a '2 channel, 3 bytes
per sample, 24 bits' device, with a single sample rate (44.1 kHz as set by
the front panel), as follows:
** UNRECOGNIZED: 0b 24 02 01 02 03 18 01 44 ac 00
However, when switching the UA-5 to class compliant mode, lsusb still
doesn't decipher the descriptor properly, it still comes out as UNRECOGNIZED
(albeit with '02 02 10' in the middle, i.e. '2 channels, 2 bytes per
channel, 16 bits'). I haven't bothered to dive into lsusb to figure out why
it works this way. I can conclude however that ALSA seems to decipher the
descriptor fine, which is why the endpoints don't need to be specifically
specified in the quirk.
> I look forward to using the R16 for playback!
By the way which Linux kernel (or distribution for that matter) are you
using?
/Ricard
--
View this message in context: http://linux-audio.4202.n7.nabble.com/re-Zoom-R16-tp87487p97598.html
Sent from the linux-audio-user mailing list archive at Nabble.com.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
