Re: re Zoom R16

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user




[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux