re Zoom R16

classic Classic list List threaded Threaded
89 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

sub_acoustic
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 tells me that if I don't know what I'm doing I might wreck my computer...

Reasons for NOT compiling a custom kernel
> You merely need to compile a special driver. For this, you only need to install the linux-headers packages


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
Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

rob-107
On 23 February 2014 19:48:55 GMT+00:00, sub_acoustic <[hidden email]> wrote:

>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
>> You merely need to compile a special driver. For this, you only need
>to
>> install the linux-headers packages/*
>
>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.
>_______________________________________________
>Linux-audio-user mailing list
>[hidden email]
>http://lists.linuxaudio.org/listinfo/linux-audio-user

Check out:
http://wiki.linuxaudio.org/wiki/start
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

_______________________________________________
Linux-audio-user mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-user
Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

Atte-4
In reply to this post by sub_acoustic
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

jmancine
In reply to this post by Atte-4
Atte André Jensen wrote
On 02/23/2014 05:52 PM, sub_acoustic wrote:
> 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...

Here's what I did:

1) placed the quirks in a file (/usr/src/zoom_quirks.h)

2) included it in the build by adding a line to
/usr/src/linux/sound/usb/quirks_table.h:
#include "../../../zoom_quirks.h"

It might be more direct to add the the quirk intry directly in
/usr/src/linux/sound/usb/quirks_table.h, but this way it survives across
different kernel builds and is easier to fiddle with.
Hi Atte,

Am I right that you can make a change to your zoom_quirks.h file and it will be included when you reboot (without rebuilding the kernel)?   I was looking for a way to do this... so simple. :)


Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

Ralf Mattes
On Mon, 24 Feb 2014 09:29:44 -0800 (PST), jmancine wrote

> Hi Atte,

Not being Atte, but I think I can answer this.

> Am I right that you can make a change to your zoom_quirks.h file and
> it will be included when you reboot (without rebuilding the kernel)?

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

_______________________________________________
Linux-audio-user mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-user
Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

jmancine
R. Mattes wrote
No way. The .h files are read by the C compiler (actually, the C
preprocessor). Changes are only picked up during a recomile.
Makes sense...Thanks for the response.  The constant recompiling is what has kept me from testing more solutions to playback on the R16...wish there was a way to set a dynamic path to the R16 quirk that was picked up on reboot, but it sounds as if it needs to be compiled each time.  



Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

gordonjcp
On Mon, Feb 24, 2014 at 09:41:51AM -0800, jmancine wrote:
> R. Mattes wrote
> > No way. The .h files are read by the C compiler (actually, the C
> > preprocessor). Changes are only picked up during a recomile.
>
> Makes sense...Thanks for the response.  The constant recompiling is what has
> kept me from testing more solutions to playback on the R16...wish there was
> a way to set a dynamic path to the R16 quirk that was picked up on reboot,
> but it sounds as if it needs to be compiled each time.  

Compile as a module, unload, compile, reload.

--
Gordonjcp MM0YEQ

_______________________________________________
Linux-audio-user mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-user
Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

jmancine
gordonjcp wrote
Compile as a module, unload, compile, reload.
Not sure exactly what you mean...I would still have to recompile the whole kernel (in order to pass the changes to all the other modules like snd_usb_audio, soundcore, snd_usbmidi, etc, etc)  right???
Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

sub_acoustic
In reply to this post by Atte-4
Thanks Atte,

Does that mean that I could download the latest UbuntuStudio distro, including kernel then apply the zoom_quirks.txt, compile the kernel, install it and reboot
into it...?

sounds tricky...perhaps the Ubuntu Studio developers would be so kind as to add the quirk to the next distro...

why are manufacturers so hesitant to support linux?, or at least share information with Linux developers? they would sell so many more units...

Just got my Zoom R16...time to start making some sound!
Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

Atte-4
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

David W. Jones
On 02/26/2014 09:29 PM, Atte wrote:
> On 02/24/2014 10:50 PM, sub_acoustic wrote:

>> why are manufacturers so hesitant to support linux?, or at least share
>> information with Linux developers? they would sell so many more units...
>
> It's annoying, but I think it all boils down to the relatively small
> number of linux users...

And the even smaller number of pro-audio Linux users.

--
David W. Jones
[hidden email]
authenticity, honesty, community
http://dancingtreefrog.com
_______________________________________________
Linux-audio-user mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-user
Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

Atte-4
In reply to this post by sub_acoustic
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

sub_acoustic
Atte, you're a legend

Much appreciated!
Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

sub_acoustic
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

Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

millerthegorilla
Did anyone manage to advance the work on the zoom r16/24?  Is it possible yet to use it in full duplex mode?

Thanks

James
Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

jmancine
This post was updated on .
Still no duplex.  In fact, no playback.

I have narrowed the issue down to a problem with the bitrate 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
Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

millerthegorilla
Hmm, I have been compiling my kernel for a couple of days now and no joy.  I have the information from lsusb -vv, cat /proc/asound/R16/stream0 / 1, etc but I'm a little confused about the terminology of quirks-table.h.
What is the difference between .ifnum and .iface?    is the first (ifnum) a reference to the usb bus?
When I put the working zoom-quirks.h through, I get capture on interface 1 and playback on interface 2 listed under one stream in cat /proc/asound/R16/stream0 , when I try the zoom-quirks.h that I include below, I get two playback streams, one listed at /proc/asound/R16/stream0 and the other at /proc/asound/R16/stream1

Notice that I have put a bunch of sample formats so that the correct one can be selected.  I don't think that this covers the problem though if you read in my excerpt from kern.log, it complains that ep 3 can set freq.

here is the zoom-quirks.h quirks table.

{
/* 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_FIXED_ENDPOINT,
        .data = & (const struct audioformat) {
      .formats = (SNDRV_PCM_FMTBIT_U8 | SNDRV_PCM_FMTBIT_S8 |
               SNDRV_PCM_FMTBIT_U16_LE | SNDRV_PCM_FMTBIT_S16_LE |
               SNDRV_PCM_FMTBIT_U16_BE | SNDRV_PCM_FMTBIT_S16_BE |
               SNDRV_PCM_FMTBIT_U24_LE | SNDRV_PCM_FMTBIT_S24_LE |
               SNDRV_PCM_FMTBIT_U24_BE | SNDRV_PCM_FMTBIT_S24_BE |
               SNDRV_PCM_FMTBIT_U24_3LE | SNDRV_PCM_FMTBIT_S24_3LE |
               SNDRV_PCM_FMTBIT_U24_3BE | SNDRV_PCM_FMTBIT_S24_3BE |
               SNDRV_PCM_FMTBIT_U32_LE | SNDRV_PCM_FMTBIT_S32_LE |
               SNDRV_PCM_FMTBIT_U32_BE | SNDRV_PCM_FMTBIT_S32_BE),
      .channels = 2,
      .iface = 2,
      .altsetting = 1,
      .altset_idx = 1,
      .attributes = 0,
      .endpoint = 0x03, /*PLAYBACK*/
      .ep_attr = USB_ENDPOINT_XFER_ISOC,
      .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 = 4,
     .type = QUIRK_AUDIO_FIXED_ENDPOINT,
     .data = & (const struct audioformat) {
        .formats = (SNDRV_PCM_FMTBIT_U8 | SNDRV_PCM_FMTBIT_S8 |
               SNDRV_PCM_FMTBIT_U16_LE | SNDRV_PCM_FMTBIT_S16_LE |
               SNDRV_PCM_FMTBIT_U16_BE | SNDRV_PCM_FMTBIT_S16_BE |
               SNDRV_PCM_FMTBIT_U24_LE | SNDRV_PCM_FMTBIT_S24_LE |
               SNDRV_PCM_FMTBIT_U24_BE | SNDRV_PCM_FMTBIT_S24_BE |
               SNDRV_PCM_FMTBIT_U24_3LE | SNDRV_PCM_FMTBIT_S24_3LE |
               SNDRV_PCM_FMTBIT_U24_3BE | SNDRV_PCM_FMTBIT_S24_3BE |
               SNDRV_PCM_FMTBIT_U32_LE | SNDRV_PCM_FMTBIT_S32_LE |
               SNDRV_PCM_FMTBIT_U32_BE | SNDRV_PCM_FMTBIT_S32_BE),
        .channels = 8,
        .iface = 1,
        .altsetting = 1,
        .altset_idx = 1,
        .attributes = 0,
        .endpoint = 0x84, /*CAPTURE*/
        .ep_attr = USB_ENDPOINT_XFER_ISOC,
        .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 = .1
      },


    }

  }

},


here is  the excerpt from kern.log

Mar 10 09:35:17 super-R720 kernel: [   98.846039] usb 1-1: new high-speed USB device number 4 using ehci-pci
Mar 10 09:35:17 super-R720 kernel: [   98.974688] usb 1-1: config 1 interface 3 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
Mar 10 09:35:17 super-R720 kernel: [   98.974693] usb 1-1: config 1 interface 3 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
Mar 10 09:35:17 super-R720 kernel: [   98.975307] usb 1-1: New USB device found, idVendor=1686, idProduct=00dd
Mar 10 09:35:17 super-R720 kernel: [   98.975310] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar 10 09:35:17 super-R720 kernel: [   98.975312] usb 1-1: Product: R16
Mar 10 09:35:17 super-R720 kernel: [   98.975314] usb 1-1: Manufacturer: ZOOM Corporation
Mar 10 09:35:17 super-R720 kernel: [   98.975316] usb 1-1: SerialNumber: 0
Mar 10 09:35:22 super-R720 kernel: [  104.032341] 4:1:1: cannot get freq at ep 0x3
Mar 10 09:35:27 super-R720 kernel: [  109.033070] usbcore: registered new interface driver snd-usb-audio

I'm fairly certain that I've got the wrong interface number but I have found it virtually impossible to find any documentation on the nomenclature used in quirks-table.h.  For instance what is the difference between ifnum and iface?

Also, I notice that several source code files, like stream.c for instance, have quirks built in to them, so perhaps I could explicitly set the sample rate format for the playback stream when the stream is created in the source code.
Otherwise the bitrate descriptors are listed around about here:
www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/include/sound/asound.h#L203


I'm guessing that where a bit rate descriptor has the letter S it stands for signed and the one with U stands for unsigned, I don't know if that would make a difference.  My brief foray into the source code so far leaves me with the impression that I should be able to create both capture and playback on the same interface, using the alt setting, but how the format works for that is beyond me at the moment, although I plan to spend tomorrow morning reading through the source code!.


On Fri, Mar 7, 2014 at 2:04 PM, jmancine [via Linux Audio] <[hidden email]> wrote:
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


If you reply to this email, your message will be added to the discussion below:
http://linux-audio.4202.n7.nabble.com/re-Zoom-R16-tp87487p89731.html
To unsubscribe from re Zoom R16, click here.
NAML



--
James Stewart Miller Bsc(hons) Psych.
Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

jmancine
This post was updated on .
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
Notice that I have put a bunch of sample formats so that the correct one can be selected.
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
Hmm, I have been compiling my kernel for a couple of days now and no joy.
I have the information from lsusb -vv, cat /proc/asound/R16/stream0 / 1,
etc but I'm a little confused about the terminology of quirks-table.h.
What is the difference between .ifnum and .iface?    is the first (ifnum) a
reference to the usb bus?
.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
                        },
             

                        }

        }

},






Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

jmancine
Sorry, there was a typo in that last message...there is no apostrophe after the .iface setting

It should be just:

 .iface = 0,

Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

ricardwolf
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.
12345