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

michael noble-2

On Mon, Nov 18, 2013 at 9:42 PM, jmancine <[hidden email]> wrote:
The sync is fine, one clock becomes master.

How?

_______________________________________________
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

michael noble-2
In reply to this post by jmancine

On Mon, Nov 18, 2013 at 9:42 PM, jmancine <[hidden email]> wrote:
The sync is fine, one clock becomes master.

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. 

_______________________________________________
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
Look, I am just trying to make this device work in Linux.  I apologize, but my "normal" setup has never included playback on the recording device -- so that was not a priority in testing the R16, or even on my radar.  Obviously, the R16 is low end device that has no clock sync ability whatsoever.  It is never going to be perfect, but I haven't noticed enough drift to be noticeable in a week or two of recording and overdubbing with it. Perhaps cheap crystals have gotten better and perform reasonably consistently... perhaps I am just a lucky guy.   Regardless, I hope to have it working in full duplex soon.  

That aside, the generalization that multiple devices can't work is incorrect.   There are many devices with hardware sync options... mine happen to use ADAT optical cables to do the job.   Even those old soundblasters (or whatever they were) had physical sync cables.  It remains a standard on higher end equipment.

Back to the topic at hand -- I will try to modify the quirk to support full duplex.   Stay tuned.






Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

Al Thompson-3
In reply to this post by Set Hallstrom
I can see this being a problem if the multiple devices were all input devices, such as the "multiple Soundblasters" mentioned in a previous post, but if there is a single device used for input, and another device that is used strictly for listening, what problems can be caused? I fail to see how it could cause a problem, even if the clock on the monitor audio chain drifts.



michael noble <[hidden email]> wrote:


On Mon, Nov 18, 2013 at 9:42 PM, jmancine <[hidden email]> wrote:
The sync is fine, one clock becomes master.

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. 

_______________________________________________
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

The idea is that you would be playing along with a track that wasnt "in time" with what you are recording.  In reality, minor drift is probably not audibly noticeable but it precludes work that needs to be sample-accurate.

On Nov 18, 2013 10:56 AM, "Al Thompson-3 [via Linux Audio]" <[hidden email]> wrote:
I can see this being a problem if the multiple devices were all input devices, such as the "multiple Soundblasters" mentioned in a previous post, but if there is a single device used for input, and another device that is used strictly for listening, what problems can be caused? I fail to see how it could cause a problem, even if the clock on the monitor audio chain drifts.



michael noble <[hidden email]> wrote:


On Mon, Nov 18, 2013 at 9:42 PM, jmancine <[hidden email]> wrote:
The sync is fine, one clock becomes master.

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. 

_______________________________________________
Linux-audio-user mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-user



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-tp87487p87952.html
To unsubscribe from re Zoom R16, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

Fons Adriaensen-3
In reply to this post by michael noble-2
On Mon, Nov 18, 2013 at 02:53:09PM +0800, michael noble 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.

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)

_______________________________________________
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

michael noble-2

On Tue, Nov 19, 2013 at 12:21 AM, Fons Adriaensen <[hidden email]> 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.

Right. I've used Zita-ajbridge, which I guess is what Ralf was thinking of, for this purpose. It works extremely well. I also use ADAT sync when needed to sync between two machines. I clarified with Jason off-list so as not to detract too much from the thread about getting the zoom to work, but it came across to me that he was saying there would be no problems at all to use multiple devices without *any* kind of sync solution. Which, as he himself clarified, is not true.


_______________________________________________
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
In reply to this post by Fons Adriaensen-3
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.



Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

Ralf Mardorf
On Mon, 2013-11-18 at 08:42 -0800, jmancine wrote:
> Theoretically, this should bring out any sync problems, but there is no
> discernible difference in the beats when playing back all 32 tracks.

If the difference is enough frames long, you'll get phasing issues that
are not noticeable as fluctuation for the musical timing, but it could
cause a muddy sound, make it harder or even impossible to do a good mix.

_______________________________________________
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
In reply to this post by jmancine
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.




Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

Ralf Mardorf
On Tue, 2013-11-19 at 09:46 -0800, jmancine wrote:
> Man, I wish recompiling didn't take so darn long!
> it takes many hours just to test out a single change.

Instead of programming the values you'll test and recompile everything,
why not reading values from a text file? This might not be possible for
every value, but in some cases this perhaps can be done.

_______________________________________________
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
This post was updated on .
Not sure how to do that...do you mean to replace the .ep_attr with a path to a txt file that just contains the string I want to test?  That makes sense.

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
               }
            }
         },


Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

Al Thompson-3
In reply to this post by jmancine
I understand sync issues, but I would think that the latency of the output device would have more influence than not having the playback device's clock synced to the input.  I've never heard of a clock drifting so badly that, for example, it took 3:05 to play back a 3:00 song.  I can't imagine anyone's playing to be of such exactness that the lack of sample-accurate playback sync would possibly be noticed???  If you are overdubbing over drum tracks, can you truthfully say that your note start times are within 1/48,000th of a second??


On 11/18/2013 11:06 AM, jmancine wrote:

The idea is that you would be playing along with a track that wasnt "in time" with what you are recording.  In reality, minor drift is probably not audibly noticeable but it precludes work that needs to be sample-accurate.

On Nov 18, 2013 10:56 AM, "Al Thompson-3 [via Linux Audio]" <[hidden email]> wrote:
I can see this being a problem if the multiple devices were all input devices, such as the "multiple Soundblasters" mentioned in a previous post, but if there is a single device used for input, and another device that is used strictly for listening, what problems can be caused? I fail to see how it could cause a problem, even if the clock on the monitor audio chain drifts.



michael noble <[hidden email]> wrote:


On Mon, Nov 18, 2013 at 9:42 PM, jmancine <[hidden email]> wrote:
The sync is fine, one clock becomes master.

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. 

-- 
---
My bands, CD projects, music, news, and pictures:

  http://www.lateralforce.com
 
 
 
Staat heißt das kälteste aller kalten Ungeheuer.  Kalt lügt es auch;
und diese Lüge kriecht aus seinem Munde: 'Ich, der Staat, bin das Volk.'
                                                - [Friedrich Nietzsche]

_______________________________________________
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

Fons Adriaensen-3
On Mon, Nov 25, 2013 at 07:26:11PM -0500, Al Thompson wrote:

> I understand sync issues, but I would think that the latency of the
> output device would have more influence than not having the playback
> device's clock synced to the input.  I've never heard of a clock
> drifting so badly that, for example, it took 3:05 to play back a 3:00
> song.  I can't imagine anyone's playing to be of such exactness that the
> lack of sample-accurate playback sync would possibly be noticed???  If
> you are overdubbing over drum tracks, can you truthfully say that your
> note start times are within 1/48,000th of a second??

Typical errors for cheap cards are less than 0.1%. But that still
means 0.18 seconds after 3 minutes.

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)

_______________________________________________
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
In reply to this post by Al Thompson-3

I think the point was more about phasing issues than timing.  That being said, phasing doesn't really present itself unless a track is playing back with a recording of itself...
Which doesn't generally happen when overdubbing

On Nov 25, 2013 7:26 PM, "Al Thompson-3 [via Linux Audio]" <[hidden email]> wrote:
I understand sync issues, but I would think that the latency of the output device would have more influence than not having the playback device's clock synced to the input.  I've never heard of a clock drifting so badly that, for example, it took 3:05 to play back a 3:00 song.  I can't imagine anyone's playing to be of such exactness that the lack of sample-accurate playback sync would possibly be noticed???  If you are overdubbing over drum tracks, can you truthfully say that your note start times are within 1/48,000th of a second??


On 11/18/2013 11:06 AM, jmancine wrote:

The idea is that you would be playing along with a track that wasnt "in time" with what you are recording.  In reality, minor drift is probably not audibly noticeable but it precludes work that needs to be sample-accurate.

On Nov 18, 2013 10:56 AM, "Al Thompson-3 [via Linux Audio]" <[hidden email]> wrote:
I can see this being a problem if the multiple devices were all input devices, such as the "multiple Soundblasters" mentioned in a previous post, but if there is a single device used for input, and another device that is used strictly for listening, what problems can be caused? I fail to see how it could cause a problem, even if the clock on the monitor audio chain drifts.



michael noble <[hidden email]> wrote:


On Mon, Nov 18, 2013 at 9:42 PM, jmancine <[hidden email]> wrote:
The sync is fine, one clock becomes master.

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. 

-- 
---
My bands, CD projects, music, news, and pictures:

  http://www.lateralforce.com
 
 
 
Staat heißt das kälteste aller kalten Ungeheuer.  Kalt lügt es auch;
und diese Lüge kriecht aus seinem Munde: 'Ich, der Staat, bin das Volk.'
                                                - [Friedrich Nietzsche]

_______________________________________________
Linux-audio-user mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-user



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-tp87487p88007.html
To unsubscribe from re Zoom R16, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

jmancine
In reply to this post by jmancine
Had a response over on alsa-devel mailing list, but the suggestion did not work.   Newer kernels support the QUIRK_AUTO_DETECT parameter which once again worked for 8 channels of capture,  but failed for playback.

I am pretty much out of ideas at this point.   Here is the output of an attempt to just use the R16 for stereo playback.  There are some maxpacket errors on the MIDI interface (though it works fine) and errors in getting the sample rate from the playback and capture addresses for the R16, as well as errors in setting the sample rate for the playback address (0x03).  If anyone has suggestions on what to do with this info (I also posted on alsa-devel), please let me know.

dmesg ouput:

[  319.651037] usb 2-8: new high-speed USB device number 10 using ehci-pci
[  319.959768] usb 2-8: config 1 interface 3 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
[  319.959773] usb 2-8: config 1 interface 3 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
[  319.960512] usb 2-8: New USB device found, idVendor=1686, idProduct=00dd
[  319.960516] usb 2-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  319.960519] usb 2-8: Product: R16
[  319.960522] usb 2-8: Manufacturer: ZOOM Corporation
[  319.960525] usb 2-8: SerialNumber: 0
[  319.961397] snd-usb-audio: probe of 2-8:1.0 failed with error -5
[  324.962217] 10:1:1: cannot get freq at ep 0x3
[  334.963237] 10:2:1: cannot get freq at ep 0x84
[  360.798326] 10:1:1: cannot get freq at ep 0x3
[  365.803274] 10:1:1: cannot set freq 96000 to ep 0x3
[  387.266266] 10:2:1: cannot get freq at ep 0x84
[  392.272214] 10:2:1: cannot get freq at ep 0x84
[  413.894325] 10:1:1: cannot get freq at ep 0x3
[  418.899271] 10:1:1: cannot set freq 96000 to ep 0x3



JACK LOG:

loading driver ..

apparent rate = 96000

creating alsa driver ... -|hw:R16|1024|2|96000|8|0|nomon|swmeter|-|32bit

configuring for 96000Hz, period = 1024 frames (10.7 ms), buffer = 2 periods

ALSA: final selected sample format for capture: 32bit integer little-endian

ALSA: use 2 periods for capture

09:45:13.982 Server configuration saved to "/root/.jackdrc".

09:45:13.983 Statistics reset.

09:45:13.993 Client activated.

09:45:13.996 Buffer size change (0).

09:45:16.971 Buffer size change (1024).

09:45:16.972 JACK connection graph change.

09:45:16.997 JACK connection change.

09:45:28.900 Client deactivated.

09:45:28.903 JACK is stopping...

jack main caught signal 15

no message buffer overruns

09:45:33.936 JACK was stopped successfully.

09:45:38.539 JACK is starting...

09:45:38.539 /usr/bin/jackd -dalsa -dhw:R16 -r96000 -p1024 -n2 -P -o2

jackd 0.122.1

Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.

jackd comes with ABSOLUTELY NO WARRANTY

This is free software, and you are welcome to redistribute it

under certain conditions; see the file COPYING for details

JACK compiled with System V SHM support.

09:45:38.570 JACK was started with PID=2919.

loading driver ..

apparent rate = 96000

creating alsa driver ... hw:R16|-|1024|2|96000|0|2|nomon|swmeter|-|32bit

configuring for 96000Hz, period = 1024 frames (10.7 ms), buffer = 2 periods

ALSA: final selected sample format for playback: 32bit integer little-endian

ALSA: use 2 periods for playback

09:45:40.660 Server configuration saved to "/root/.jackdrc".

09:45:40.661 Statistics reset.

09:45:40.671 Client activated.

09:45:40.674 Buffer size change (0).

09:45:43.600 Buffer size change (1024).

09:45:43.601 JACK connection graph change.

09:45:43.675 JACK connection change.

ALSA: prepare error for playback on "hw:R16" (Connection timed out)

DRIVER NT: could not start driver

cannot start driver

no message buffer overruns

09:45:48.627 Shutdown notification.

09:45:48.628 Client deactivated.

09:45:48.631 JACK is being forced...

cannot read server event (Success)

cannot continue execution of the processing graph (Bad file descriptor)

graph error - calling shutdown handler

09:45:48.831 JACK was stopped successfully.
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

jmancine
Thanks Atte.  I am not getting much help in the ALSA forums... will continue to mainly post here.

My best guess is that the problem still has to do with alsa trying to initialize the sample format (bitrate) for the R16 for 32-bit integer as opposed to 24-packed-in-32 or preferably  straight 24-bit integer.    Even when I specifically set the sample rate in the quirk, it still goes to 32 bit.

With the R16, I get this in the JACK log:

ALSA: final selected sample format for playback:  32bit integer little-endian


When I use other 24-bit only devices (like the Roland UA4FX I use for playback), I get this:

 ALSA: final selected sample format for playback:  24bit integer little-endian

It does work for capture with 32 bit integer, though.  Could that be different since the device isn't being forced to process data at 32 bits, rather the driver is receiving it in that format (i.e. 24 bits packed in 32)?  With playback, the driver is explicitly telling the device to playback a format it can't support.  Just a theory.

So, I think the next step for testing is to find a different way to force both capture and playback to 24 bits.  This is how I was setting it in the quirk before:

.formats = SNDRV_PCM_FMTBIT_S24_LE

Yet it still ends up as 32 bit.  Any other formats to try or other methods for setting the sample rate out there?


Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

sub_acoustic
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



Reply | Threaded
Open this post in threaded view
|

Re: re Zoom R16

Atte-4
CONTENTS DELETED
The author has deleted this message.
12345