On Mon, Oct 14, 2013 at 9:10 AM, Paul Davis <paul(a)linuxaudiosystems.com> wrote: None at all, beyond making sure you configure it correctly for the device (Mackie). Otherwise, it's all done through ALSA. I don't remember to what extent it might have worked in A2 as a surface controller, I didn't test it much, it definitely worked in A3 as a surface controller. -- Brett W. McCoy -- http://www.brettwmccoy.com ------------------------------------------------------------------------ "In the rhythm of music a secret is hidden; If I were to divulge it, it would overturn the world." -- Jelaleddin Rumi

On Mon, Oct 14, 2013 at 9:24 AM, Paul Davis <paul(a)linuxaudiosystems.com> wrote: Yeah, as an audio controller, if I recall, it worked out of the box as a USB device. I haven't played with it in a while and only used the surface controller stuff. -- Brett W. McCoy -- http://www.brettwmccoy.com ------------------------------------------------------------------------ "In the rhythm of music a secret is hidden; If I were to divulge it, it would overturn the world." -- Jelaleddin Rumi

On Mon, Oct 14, 2013 at 9:39 AM, reSet Sakrecoer <sakrecoer(a)gmail.com> wrote: I'll take a look at it when I back in the studio tonight. I didn't do much with the audio interface, but it was working for me with ALSA & Pulseaudio (didn't try it with Jack, at least not for audio). -- Brett W. McCoy -- http://www.brettwmccoy.com ------------------------------------------------------------------------ "In the rhythm of music a secret is hidden; If I were to divulge it, it would overturn the world." -- Jelaleddin Rumi

Hey man, I am in my studio now, here's what I am doing under Ubuntu Studio 13.04 1. Plugin USB cable to unit, turn it on 2. Press USB button on unit and activate USB functionality 3. lsub shows me this: $ lsusb Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 007: ID 1686:014f ZOOM Corporation Bus 001 Device 004: ID 05e3:0719 Genesys Logic, Inc. SATA adapter Bus 002 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 002 Device 004: ID 18e3:9106 Fitipower Integrated Technology Inc 4. aplay shows me this: $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Generic [HD-Audio Generic], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: DSP [Hammerfall DSP], device 0: RME Hammerfall DSP + Multiface [RME Hammerfall DSP + Multiface] Subdevices: 0/1 Subdevice #0: subdevice #0 card 2: R8 [ZOOM R8], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 Turnong on jack, I get an ALSA MIDI device and Jack in/out ports. Running a2j -e (export hardware ports), ZOOM R8 is listed under Jack MIDI. This is working out of the box for me, I didn't need to install and/or configure anything. Pulseaudio seems to work better with jack out of the box on Ubuntu Studio 13.04 On Mon, Oct 14, 2013 at 9:44 AM, reSet Sakrecoer <sakrecoer(a)gmail.com> wrote: -- Brett W. McCoy -- http://www.brettwmccoy.com ------------------------------------------------------------------------ "In the rhythm of music a secret is hidden; If I were to divulge it, it would overturn the world." -- Jelaleddin Rumi

Set Hallstrom wrote: Try recompiling the kernel with the following entry in sound/usb/quirks-table.h: { /* ZOOM R16 in USB 2.0 mode */ USB_DEVICE(0x1686, 0x00dd), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { .ifnum = QUIRK_ANY_INTERFACE, .type = QUIRK_COMPOSITE, .data = (const struct snd_usb_audio_quirk[]) { { .ifnum = 0, .type = QUIRK_IGNORE_INTERFACE }, { .ifnum = 1, .type = QUIRK_AUDIO_STANDARD_INTERFACE }, { .ifnum = 2, .type = QUIRK_AUDIO_STANDARD_INTERFACE }, { .ifnum = 3, .type = QUIRK_MIDI_STANDARD_INTERFACE }, { .ifnum = .1 }, } } }, Regards, Clemens

Hi Clemens, El 10/15/2013 01:15 PM, Clemens Ladisch escribió: I confirm that the patch works for MIDI on a kernel 3.10.7 (gentoo)!! Thanks a lot!! On the other hand, audio doesn't seem to works straightforward. The device is seen, but I was not able to make it work with jack nor aplay. I'll do more tests... Thanks again!, Natanael.

El 10/18/2013 08:27 AM, Clemens Ladisch escribió: I think it had some trouble with the sample rate or some of the other defined arguments, but I still didn't had many time to try different combinations... Plus, I don't know how to change the sample rate on the device. There is no control exposed for alsamixer, and I cannot change it from the device itself. When I tested it, as soon I started jackd the device changed the sample rate to 96kHz (when I was trying 48kHz from the jackd command, and the device was at 44.1kHz before), and (q)jack(ctl)d stopped like waiting for the device. ... But after my previous mail I tried again with alsa_in on a running 48kHz jackd server (Focusrite Saffire), and it worked!!!! I was able to use all the 8 input channels!!! (my impression was an incredibly -for the price...- clean sound!) I tried then adding an alsa_out (at the same time than alsa_in), but it said the device was already in use (I have a H2n and as far I can remember I can execute both together...) Soon I'll do more controlled tests and I'll update you. But it look so good!! :-) Thanks a lot!!! Natanael.

WOW!!!!!!!!!!!!!!! Thank you!!!! This is GREAT NEWS!!!!!!! <3 <3 <3 Thank you Clement and Natanael!!! I haven't had time to fiddle with kernel recompiling yet, but as soon as i get my hands arround the process, i will try to compile all the information you gather to make some nice how-to for future users. *Set On 2013-10-18 22:04, Natanael Olaiz wrote: -- Set Hallstrom AKA Sakrecoer http://sakrecoer.com WARNING: Remember clear-text email is subject to mass surveillance systems. Alone this information is useless. Our summed communications are worth humanity. Please keep in mind Internet is a boulevard in a crowded virtual city. Privacy is found under the cloaks.

Hi! I'm 99% sure you can only switch the bitrate on the r16 from 16-bits to 24-bits. The samplerate is always set to 44.1kHz. Perhaps configuring jack to use 44.1 will solve the problem? Just a thaught, i still havn't got my thumb out to try Clemens Patch :/ Have a good awoken time y'all! *set On 2013-10-21 22:57, Natanael Olaiz wrote: -- Set Hallstrom AKA Sakrecoer http://sakrecoer.com WARNING: Remember clear-text email is subject to mass surveillance systems. Alone this information is useless. Our summed communications are worth humanity. Please keep in mind Internet is a boulevard in a crowded virtual city. Privacy is found under the cloaks.

On 10/23/2013 02:18 PM, Jan Depner wrote: I might be interested in getting one or two of these, but from reading this thread, it's not clear to me exactly what works and how robust it is under linux. Could someone please fill me in ? -- Atte http://atte.dk http://modlys.dk

Control surface is working in Ardour 3 using A2JMIDID to connect the ports. For Ardour 2, you also need to connect the MCU and SEQ ports to the R16 MIDI out. R16 is now fully functional in linux as a control surface and recording interface! -- View this message in context: http://linux-audio.4202.n7.nabble.com/re-Zoom-R16-tp87487p87917.html Sent from the linux-audio-user mailing list archive at Nabble.com.

On 11/15/2013 08:25 PM, jmancine wrote: Could you list what you had to do? Patching which kernel, etc... -- Atte http://atte.dk http://modlys.dk

On 11/16/2013 01:35 PM, jmancine wrote: Hmmm, is that a result of the new "not more than X posts a day" policy? If so, bad idea... Anyways back on topic. So basically it works with the editing of quirks-table.h in kernel 3.6.11, right? But not in duplex mode? Doesn't that mean that you can't record and playback (like recording vocals over existing tracks) at the same time. If so I wouldn't call the r16 "working"... -- Atte http://atte.dk http://modlys.dk

On 11/17/2013 04:19 PM, jmancine wrote: Well for overdubbing, which in some projects are the way all tracks would be recorded (the first ones would be sequenced), non-duplex is a deal-breaker. So yeah, if you could confirm it works in duplex, that would be great! That said, my main interest in the r16/r24 is as standalone recorder... -- Atte http://atte.dk http://modlys.dk

On Mon, Nov 18, 2013 at 12:58 AM, jmancine &lt;jason(a)mancine.net&gt; wrote: That seems to contradict even my admittedly basic understanding of how digital audio devices work. Mixing unsynced devices for simultaneous I/O is asking for trouble. JACK has no inbuilt capacity for synchronizing devices, so you will get clock drift and as far as I know potential sample misalignment between what you are listening to and what you are recording. Using a single device with the same clock for both input and output is always preferable, followed by two devices with some kind of hard sync if possible, followed by an aggregate driver level (ALSA in Linux) device only if the other options are unavailable. I've probably made a mess of explaining this, but there are multiple articles on the web about the importance of clock sync if you want to read up on it.

Dont want to stray too far off here, but if that were "asking for trouble" I'd have been out of business many years ago. The sync is fine, one clock becomes master. I have been recording and playing back on separate devices for a long time... As long as various softwares/platforms have supported it, but I am talking back in the days of cramming 3 or 4 soundblasters into PCI slots. I record generally 16 to 32 tracks, mostly overdubs. This year I did a 90 minute film score in two single Ardour sessions with literally thousands of takes and +/- 1 frame accuracy In other words, it is a non-issue. On Nov 18, 2013 7:13 AM, "Ralf Mardorf [via Linux Audio]" < ml-node+s4202n87947h4(a)n7.nabble.com&gt; wrote: -- View this message in context: http://linux-audio.4202.n7.nabble.com/re-Zoom-R16-tp87487p87948.html Sent from the linux-audio-user mailing list archive at Nabble.com.

On Mon, Nov 18, 2013 at 9:42 PM, jmancine &lt;jason(a)mancine.net&gt; wrote: I should clarify. You didn't specify any kind of sync solution, and not only recommended using two devices, but stated that it is the normal way of doing things. Doing so without a sync solution will result in unsynchronized clocks, which as far as I know, is very much not the normal way of doing things.

On Mon, Nov 18, 2013 at 02:53:09PM +0800, michael noble wrote: It's perfectly possible, and without any signficant loss of quality. Jack is configured to use one of the cards. The others become clients, and their signals are resampled to match the rate of the 'master' card. Zita-ajbridge will do this with a constant and repeatable latency. This is also reported to Jack, so smart applications can compensate for it. Remaining delay variations will be around a microsecond (with decent HW) and be very slow. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

FWIW, just finished a little test... I recorded a 3 minute "click track" of a metronome using the two built in mics on the R16. I then plugged my playback device into two tracks on the R16 and overdubbed those two tracks...and repeated the process 4 more times, each time playing back the previously recorded tracks while re-recording them onto two more tracks. Theoretically, this should bring out any sync problems, but there is no discernible difference in the beats when playing back all 32 tracks. Would I trust this setup for sample-sensitive work like film scoring? Probably not... but I really don't think it would be an issue for producing traditional music tracks. I am sure the mileage varies with different equipment, but after a couple weeks of tinkering, I haven't experienced any audible issues with drift...nor have I had a single xrun in JACK. Anyhow, back to the original topic. As it stands, JACK starts with the R16 in "playback only" but tries to set it at 32 bits -- just as it did with the recording before the quirk. If I start it in full duplex, JACK starts fine but then dumps a bunch of xruns and crashes when I start to record. So I think another entry in the quirk that explicitly sets playback at 24 bits should do the trick. -- View this message in context: http://linux-audio.4202.n7.nabble.com/re-Zoom-R16-tp87487p87956.html Sent from the linux-audio-user mailing list archive at Nabble.com.

Man, I wish recompiling didn't take so darn long! Maybe someone can save me some time... I am trying to figure out the correct parameters to update the quirks-table.h file. I believe that the endpoint we are after for playback is EP 3 OUT, and this is the output of lsusb-v for that section: 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 endpoint address is obviously 0x03, and I have transfered that to the table. My problem seems to be with entering the bmAttributes value into the .ep_attr section for the quirks-table.h file. Is ALSA expecting a hex type value for ep_attr? The R16 seems to have an integer (9) whereas every other device I have plugged in as a hex value for bmAttributes. First attempt failed, I compiled with the integer "9" in ep_attr. Any insight would be appreciated since it takes many hours just to test out a single change. One thought I had was to just use 0x09 even though that is not the actual hex value of bmAttributes... but that's a pure guess. -- View this message in context: http://linux-audio.4202.n7.nabble.com/re-Zoom-R16-tp87487p87971.html Sent from the linux-audio-user mailing list archive at Nabble.com.

Not sure how to do that... am I wrong in assuming that the endpoint values I need are in the output of lsusb -v? This is where it stands right now... the capture part is working fine with the addition of the specific endpoint address, playback either crashes JACK or hard freezes the R16. { .ifnum = 4, .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = & (const struct audioformat) { .formats = SNDRV_PCM_FMTBIT_S24_LE, .channels = 8, .iface = 1, .altsetting = 1, .altset_idx = 1, .attributes = UAC_EP_CS_ATTR_SAMPLE_RATE, .endpoint = 0x84, /*CAPTURE*/ .ep_attr = 13, .rates = SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_88200 | SNDRV_PCM_RATE_96000, .rate_min = 44100, .rate_max = 96000, .nr_rates = 4, .rate_table = (unsigned int[]) { 44100, 48000, 88200, 96000 } } }, { .ifnum = 5, .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = & (const struct audioformat) { .formats = SNDRV_PCM_FMTBIT_S24_LE, .channels = 2, .iface = 1, .altsetting = 1, .altset_idx = 1, .attributes = UAC_EP_CS_ATTR_SAMPLE_RATE, .endpoint = 0x03, /*PLAYBACK*/ .ep_attr = 9, .rates = SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_88200 | SNDRV_PCM_RATE_96000, .rate_min = 44100, .rate_max = 96000, .nr_rates = 4, .rate_table = (unsigned int[]) { 44100, 48000, 88200, 96000 } } }, -- View this message in context: http://linux-audio.4202.n7.nabble.com/re-Zoom-R16-tp87487p87973.html Sent from the linux-audio-user mailing list archive at Nabble.com.

On 12/02/2013 09:13 PM, jmancine wrote: Just wanted to say that I just bought an R24, so I'll join in the research as soon as time permits. Unfortunately (or fortunately) I'm quite busy with music right now, but maybe after christmas... For starters, it seems to share the USB ID with R16... -- Atte http://atte.dk http://modlys.dk

Hi, Excuse my ignorance, but how to I recompile a kernel with the quirk? Or if you could direct me to the information I can't find any straightforward instructions anywhere... Just bought an R16, using Ubuntu Studio 64-bit - 12.04 but will upgrade shortly (and hopefully have this quirk in the kernel... cheers -- View this message in context: http://linux-audio.4202.n7.nabble.com/re-Zoom-R16-tp87487p89557.html Sent from the linux-audio-user mailing list archive at Nabble.com.

Thanks Atte, That's useful, but I don't actually know how to recompile the kernel...does this mean that the quirk will be picked up when I start up the computer, or will I need to remake the kernel in order to add it... https://help.ubuntu.com/community/Kernel/Compile <https://help.ubuntu.com/community/Kernel/Compile> tells me that if I don't know what I'm doing I might wreck my computer... */Reasons for NOT compiling a custom kernel Also another quick question...I understand that once I can capture via the R16, I'll need another device for playback from the laptop/ardour/jack etc. Would the laptop soundcard be sufficient for monitoring?, or should I get another device...? Would this do...http://www.behringer.com/EN/Products/UCA202.aspx I've been using/trying to use a Presonus Firebox for a couple of years, intermittently it worked well, but overall Firewire and FFADO and xruns have been a major major major headache and waste of time so I've given it away...this is also the reason while I'll do the bulk of my recording directly in the Zoom R16 and then use my laptop primarily for mixing and mastering... ...I've learnt to be wary of an enthusiastic developers who know way more than I do, and so I can never hope to emulate the performance they claim they have...with the R16 I can't go wrong as I'll have recorded something regardless... Cheers Hamish -- View this message in context: http://linux-audio.4202.n7.nabble.com/re-Zoom-R16-tp87487p89561.html Sent from the linux-audio-user mailing list archive at Nabble.com.

On 02/23/2014 08:48 PM, sub_acoustic wrote: What I do is: download a kernel from kernel.org, apply realtime patch, apply the zoom_quirks.txt, compile the kernel, install it and reboot into it... It's not that easy, although there are lots of good info outthere... -- Atte http://atte.dk http://modlys.dk

On 02/24/2014 10:50 PM, sub_acoustic wrote: Yeah, just make sure you have the kernel source, not sure if this is provided with unbuntustudio. I think it should be included in the main linux kernel. Did anyone contact clemens(a)ladisch.de to ask for zoom r16/r24 to be added to quirks-table.h (just downloaded kernel 3.13.5 and AFAICT the zoom quirks are not in there)? It's annoying, but I think it all boils down to the relatively small number of linux users... -- Atte http://atte.dk http://modlys.dk

On 02/24/2014 10:50 PM, sub_acoustic wrote: Here's the script I use for building kernels, save this into a text file in ~/bin/kompile, make it executable with "chmod +x ~/bin/kompile", cd to /usr/src/ where you have your kernel source (make sure you have a symlink called "linux" to the kernel source "ln -s /usr/src/linux-3.13.5 /usr/src/linux") and that you have write permission to /usr/src (on debian add yourself to the src group), and run "kompile". Then you should get a .deb in /usr/src you can install with "sudo dpkg -i". Hope it helps... ---------------------------------------------------------------- #!/bin/bash cores=$(getconf _NPROCESSORS_ONLN) if [ `pwd` != '/usr/src' ]; then echo This script must be run from /usr/src exit fi if [ ! -d linux ]; then echo No symlink or directory '"linux"' found exit fi revision=0 cd linux pushd . V=`grep -e ^VERSION Makefile | sed -e 's/.*=//g'` P=`grep -e ^PATCHLEVEL Makefile | sed -e 's/.*=//g'` S=`grep -e ^SUBLEVEL Makefile | sed -e 's/.*=//g'` E=`grep -e ^EXTRAVERSION Makefile | sed -e 's/.*=//g'` version=`echo $V.$P.$S$E | sed 's/ //g'` branch=`echo $V.$P | sed 's/ //g'` running=`uname -r` echo version: $version echo branch: $branch echo running: $running sed -rie 's/echo "\+"/#echo "\+"/' scripts/setlocalversion make-kpkg clean fakeroot make-kpkg -j$cores --initrd --revision=$revision kernel_image --------------------------------------------------------------------- -- Atte http://atte.dk http://modlys.dk

Not there yet unfortunately, I decided to shift to Debian with KXStudio...and one of the first things I did was to try to compile the kernel with the quirk. hopefully it's not a hardware fault, but twice (and about halfway through the kernel rebuild) I lose power to my laptop, despite have a charged battery etc... I've emailed clemens, so hopefully the quirk is added to the kernel to make this easier in future..... I wish I could help to make the R16 quirk duplex, but that kind of thing is still beyond me at this stage cheers -- View this message in context: http://linux-audio.4202.n7.nabble.com/re-Zoom-R16-tp87487p89728.html Sent from the linux-audio-user mailing list archive at Nabble.com.

Still no duplex. In fact, no playback. I have narrowed the issue down to a problem with the nitrate being set to 32 instead of 24. This happens despite specifically setting 24 in the .formats section of the quirk. On the recording side it doesn't seem to matter because the device is doing the encoding at 24 and the PC is receiving at 32...not ideal, but it functions because 24 bits fit into 32. But for playback, the PC is sending a 32 bit stream to a device that can only decode 24...and it crashes. If you go back through this thread, I posted the various settings I tried for .formats -- there are likely many that I have not tested. Perhaps there is another way to force 24 bits -- View this message in context: http://linux-audio.4202.n7.nabble.com/re-Zoom-R16-tp87487p89731.html Sent from the linux-audio-user mailing list archive at Nabble.com.

A few things: First, many of my original posts to the mailing list did not actually end up on the mailing list! You can go back through here to see the full history of how we got to where we are: http://linux-audio.4202.n7.nabble.com/re-Zoom-R16-td87487.html Second, we should all be aware that kernels 3.11 and greater have support for the "ANY INTERFACE" and "AUTODETECT" tags. For the R16, this means that this quirk (yes that is the whole thing!) will work for capture only. /* ZOOM R16 in USB 2.0 mode */ { .match_flags = USB_DEVICE_ID_MATCH_VENDOR | USB_DEVICE_ID_MATCH_INT_CLASS, .idVendor = 0x1686, .bInterfaceClass = USB_CLASS_VENDOR_SPEC, .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { .ifnum = QUIRK_ANY_INTERFACE, .type = QUIRK_AUTODETECT } }, If you are after capture only, and are on a kernel >3.11, this is your quirk. Third, the problem with playback is (I believe) narrowed down to ALSA not being able to set set the bit rate. Until we are able to figure out how to make ALSA see the R16 as 24-bit integer, everything else is irrelevant. millerthegorilla wrote The R16 does not support 8, 16 or 32... it is only 24 (in interface mode). The problem is that none of the 24 bit formats I am aware of WORK. ALSA has some kind of problem with the R16 when it comes to initializig it, and always sets it to 32 bit (or technically 24 in 32) which it does not support. It is 24 bit INTEGER meaning exactly 24 bits. Again, until we can find a .format that will set the R16 to 24 bits, it will not support playback. Fourth, on the subject of ifnums and ifaces: millerthegorilla wrote .ifnum is the hardware interface number, it can be derived from the variable "bInterfaceNumber" in the output of lsusb -v Here is the problem.... there is NO interface #4 despite the quirk working as such. When I initially was testing quirks for the R16, I just added that (and #5) as a placeholders on top of the standard audio quirk! I was as surprised as everyone when #4 enabled capture. It is a working hack, but it is accidental. To my knowledge, these are the correct interface numbers and functions: The correct interfaces are: 0 - device (hardware comm) 1 - PLAYBACK 2 - CAPTURE 3 - MIDI If you move your .ifnum=4 section into the .ifnum=2 section (and delete #4) it will work, and will be in the right place for further testing. Similarly, .iface correlates with the iInterface variable that you can also view in the output of lsusb. The correct setting is zero, like this: .iface = 0,' I noticed you also changed .attributes to USB_ENDPOINT_XFER_ISOC... any reason for that? And finally, here is the THEORETICAL quirk that *should* work for playback, capture and MIDI. By all accounts, this *should* work... BUT IT DOES NOT. My best guess is that this is indeed the right quirk, but that the .formats setting of 24 bits is not accepted and ALSA defaults to 32 (or 24 packed in 32). { /* ZOOM R16 in USB 2.0 mode */ USB_DEVICE(0x1686, 0x00dd), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { .ifnum = QUIRK_ANY_INTERFACE, .type = QUIRK_COMPOSITE, .data = (const struct snd_usb_audio_quirk[]) { { .ifnum = 0, .type = QUIRK_IGNORE_INTERFACE }, { .ifnum = 1, /*PLAYBACK*/ .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = & (const struct audioformat) { .formats = SNDRV_PCM_FMTBIT_S24_LE, .channels = 2, .iface = 0, .altsetting = 1, altset_idx = 1, .attributes = UAC_EP_CS_ATTR_SAMPLE_RATE, .endpoint = 0x03, .ep_attr = 9, .rates = SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_88200 | SNDRV_PCM_RATE_96000, .rate_min = 44100, .rate_max = 96000, .nr_rates = 4, .rate_table = (unsigned int[]) { 44100, 48000, 88200, 96000 } } }, { .ifnum = 2, /*CAPTURE*/ .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = & (const struct audioformat) { .formats = SNDRV_PCM_FMTBIT_S24_LE, .channels = 8, .iface = 0, .altsetting = 1, .altset_idx = 1, .attributes = UAC_EP_CS_ATTR_SAMPLE_RATE, .endpoint = 0x84, .ep_attr = 13, .rates = SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 | SNDRV_PCM_RATE_88200 | SNDRV_PCM_RATE_96000, .rate_min = 44100, .rate_max = 96000, .nr_rates = 4, .rate_table = (unsigned int[]) { 44100, 48000, 88200, 96000 } } }, { .ifnum = 3, .type = QUIRK_MIDI_STANDARD_INTERFACE }, { .ifnum = .1 }, } } }, -- View this message in context: http://linux-audio.4202.n7.nabble.com/re-Zoom-R16-tp87487p89773.html Sent from the linux-audio-user mailing list archive at Nabble.com.

I searched LAU for an appropriate thread for an ongoing R16 discussion, and this seemed to be it... I finally got my hands on an R16 about a month ago after a long period of indecision. Mostly because I was originally looking for a standalone multitrack recorder, having had a Korg D8 since it was almost new, and liking that format, but wanting to be able to record more than two channels at once. The R16 has very limited editing facilities so it was far down on my list. However, after visiting an acquaintance during the summer who was using Logic or some similar DAW software on his Mac, I decided to try out first Audacity with simultaneous playback/record on my Edirol UA-5, and then Ardour. I really took a liking to Ardour, and started looking for a multi channel interface. So, it was back to the R16, decided that I'd take the chance and try to get it going under Linux. After looking around a bit I swapped my almost unused Yamaha AW1600 (bought earlier this year to replace the D8, but never really took to it) for an R16. So after reading up on various forum posts, and dumping the USB traffic in both Linux and using the Windows driver, I managed to figure out what the problem is. For some reason, when sending data to the R16, rather than just transmitting the audio data in so-called USB isochronous packets (a type of high rate data packet type used for USB audio transmission - 125 µs interval for USB 2) as a standard audio device, the Windows driver stuffs a length descriptor at the start of each packet. (The packet size is in the range of around 100 bytes, depending on the sample rate). No wonder the R16 gets confused when it receives ordinary audio data; every first sample in an isochronous packet would be interpreted as a packet length! There was no quirk already in the Linux ALSA USB driver which would add this. This means that no fiddling about in the quirk table could ever make the R16 work; some code changes are required as well. (Incidentally, I found out that while researching this that the audio format expected by the R16 is 32 bits, of which only 24 are used, i.e. S32_LE in ALSA parlance.) So I devised a suitable patch which just adds the required descriptor in the playback data and lo and behold - the R16 started playing back without hangs or other hickups. Joy indeed! A nice guy called Panu, who's already added capture support to the Linux ALSA USB driver, in Linux 3.19, helped me test it out. The R16 playback patch has been submitted to Linux mainline and will probably appear in Linux 4.4 . For those that can't wait, there's a patch set available here: http://butoba.net/downloads/R16-3.16.7-final.tgz . It is intended for Linux 3.16.7 which what is used in Debian Jessie. The first patch in the series is just a backport of Panu's R16 capture support from Linux 3.19, so it can be skipped if you're already running Linux 3.19 or later. The patch set might not apply cleanly to all later versions, but the differences should be small enough to be worked out manually. If there's enough interest in a specific kernel version which doesn't seem to work, send me a download or git link (and sha1 or tag) and I can try and rework the patch set for that particular version. -- View this message in context: http://linux-audio.4202.n7.nabble.com/re-Zoom-R16-tp87487p97591.html Sent from the linux-audio-user mailing list archive at Nabble.com.

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

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 -- View this message in context: http://linux-audio.4202.n7.nabble.com/re-Zoom-R16-tp87487p97684.html Sent from the linux-audio-user mailing list archive at Nabble.com.

On 2015-10-19 23:10, ricardwolf wrote: GENIUS!!! You rock! The aw1600 agrees with me and sends you kind regards! -- Set

Atte André Jensen wrote Yes, or more accurately this: https://github.com/0day-ci/linux/commits/Ricard-Wanderlof/ALSA-USB-audio-Su… which is the second version of the same patch set. If you want to apply this patchset, you also need this commit: https://github.com/0day-ci/linux/commit/ab30965d9bfcd04931f9b70d00faa2ea614… which fixes a (small) bug in the max packet size calculation. -- View this message in context: http://linux-audio.4202.n7.nabble.com/re-Zoom-R16-tp87487p97601.html Sent from the linux-audio-user mailing list archive at Nabble.com.

On Mon, 24 Feb 2014 09:29:44 -0800 (PST), jmancine wrote Not being Atte, but I think I can answer this. No way. The .h files are read by the C compiler (actually, the C preprocessor). Changes are only picked up during a recomile. HTH Ralf Mattes

On Mon, Feb 24, 2014 at 09:41:51AM -0800, jmancine wrote: Compile as a module, unload, compile, reload. -- Gordonjcp MM0YEQ