Re: [LAU] re Zoom R16

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.