Nice work, ricardwolf! 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 :)
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:
bInterfaceClass 255 Vendor Specific Class
** 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
bEndpointAddress 0x03 EP 3 OUT
Transfer Type Isochronous
Synch Type Adaptive
Usage Type Data
wMaxPacketSize 0x006c 1x 108 bytes
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:
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?
[quote] By the way which Linux kernel (or distribution for that matter) are you using? [/quote]
I have several distros I use... UbuntuStudio, AVLinux. I did see your post on the AVLInux forum about the R16. The focus there has been on stability rather than on broad compatibility...and it is indeed the most stable of all distros I have used. But the older Squeeze base and now ancient 3.6 kernel have made it hard to stay current with effects and apps that require newer libs. The dev (GMaq) has been working on a totally new version that will be released both 32 and 64 bit, and hopefully be based on a current kernel.
UbuntuStudio is pretty solid, but it is SO bloated. I can not seem to make anything work without occassional xruns (whereas I have never had an xrun in AVLInux)
I will also voice my support for R16 support in the next version of AVLinux, as well as for a patch for the current version. Thanks again!
On 10/24/2015 02:10 PM, jmancine wrote:
> Also, if you are interested in the subject of audio-centric distros... keep
> an eye on one called "IO". The current version uses a 4.0.4 rt kernel and
> it is VERY smooth on newer hardware.
> http://sourceforge.net/projects/io-gnu-linux/files/ >
> I read on a forum that the next release will be based on 4.4, so it should
> include full R16 support
I think I tried IO Gnu Linux, for some reason it didn't work. But that
might have been awhile ago.
Thanks jmancine, IO looks good and the fix for the R16 is fantastic, what a great bit of news! I don't have an R16 currently although having fixed the io I shall look into purchasing one. I use UbuntuStudio with the kxstudio repositories added and with pulseaudio stripped out. (just 'apt-get purge pulseaudio' is sufficient. It may very well be pulseaudio that is giving you the xruns. Also, a realtime kernel will diminish the chance of xruns as well. I usually use this article to remind myself how to do this: http://askubuntu.com/questions/72964/how-can-i-install-a-realtime-kernel making sure I update to the latest kernel that has a realtime patch available, and using the lowlatency kernel config from ubuntu studio to initialise the kernel config. it compiles to a deb file which is portable and can be reinstalled easily and if you really want to minimise jitter etc, then you can customise the kernel config by running 'make localmodconfig' instead of copying over the kernel config. It doesn't take much editing to the config after that, just remember to add sd card readers and broadband dongles etc that you might use.
Ubuntu studio uses xfce4.12 so add the xfce4-whiskermenu-plugin to the menu instead of the standard launcher and along with kxstudio programs like cadence and carla (really good btw) you have a really good audio etc distro that has the functionality of the kxstudio distro without the bloat of kde.
On Sun, Oct 25, 2015 at 1:10 AM, jmancine [via Linux Audio] <[hidden email]> wrote:
Also, if you are interested in the subject of audio-centric distros... keep an eye on one called "IO". The current version uses a 4.0.4 rt kernel and it is VERY smooth on newer hardware.