You are here

Audio Interface - Low Latency Performance Data Base :

Page 25 of 31

Re: Audio Interface - Low Latency Performance Data Base :

PostPosted: Tue Sep 24, 2013 1:23 pm
by ef37a
Thanks Sam.
Been meaning to ask, how do you sync two units together please?

Dave.

Re: Audio Interface - Low Latency Performance Data Base :

PostPosted: Tue Sep 24, 2013 1:40 pm
by Sam Inglis
Sync uses the S/PDIF in and out according to the manual. I haven't had two units at the same time to try it.

It's a nice piece of kit, all told.

Re: Audio Interface - Low Latency Performance Data Base :

PostPosted: Tue Sep 24, 2013 5:00 pm
by ef37a
Sam Inglis wrote:Sync uses the S/PDIF in and out according to the manual. I haven't had two units at the same time to try it.

It's a nice piece of kit, all told.

Yes I see now. I had some trouble getting hold of the manual. Each unit goes back via its own usb cable to the PC, the pictures do look impressive.

Dave.

Re: Audio Interface - Low Latency Performance Data Base :

PostPosted: Tue Sep 24, 2013 11:08 pm
by Goddard
Sam Inglis wrote:Well...

I was just getting ready to feel smug about having exposed the Roland Studio Capture's poor low-latency performance, when Roland got in touch. They have sent me a second unit for testing and provided some additional guidance as to how to get best results. I have updated the online version of the review <a href="/SOS/aug13/articles/roland-studio-capture.htm" target="_blank">here</a> if you want the details, but the nitty-gritty of it is that the driver is set up by default for operation under WDM. To achieve best ASIO performance you need to tick a small box labelled 'Reduce CPU Load'. This isn't enabled by default, and the documentation makes no mention of it having an effect on latency (whenever I've encountered options like this in other interface drivers, they invariably make latency worse!).

With this box enabled, ASIO latency is roughly comparable with many other USB interfaces, and unlike some, I could get the Studio Capture to work at a 32-sample buffer size in my system.

Sam, thanks for your update.

FWIW, the "Reduce CPU load" ASIO driver setting option is documented on p.55 of the Studio-Capture pdf manual, and afaik was first introduced in Roland's version 1.50 VS drivers (as documented in the V. 1.50 Quad-Capture driver update release notes).

And tying in with Pete's 'peek under the lid' reveal, came across this earlier info tidbit.

Re: Audio Interface - Low Latency Performance Data Base :

PostPosted: Thu Sep 26, 2013 1:10 am
by TAFKAT
Sam Inglis wrote:Well...

I was just getting ready to feel smug about having exposed the Roland Studio Capture's poor low-latency performance, when Roland got in touch. They have sent me a second unit for testing and provided some additional guidance as to how to get best results. I have updated the online version of the review <a href="/SOS/aug13/articles/roland-studio-capture.htm" target="_blank">here</a> if you want the details, but the nitty-gritty of it is that the driver is set up by default for operation under WDM. To achieve best ASIO performance you need to tick a small box labelled 'Reduce CPU Load'. This isn't enabled by default, and the documentation makes no mention of it having an effect on latency (whenever I've encountered options like this in other interface drivers, they invariably make latency worse!).

With this box enabled, ASIO latency is roughly comparable with many other USB interfaces, and unlike some, I could get the Studio Capture to work at a 32-sample buffer size in my system.

Hey Sam,

Its inane that they set up the unit to primarily work under WDM and to be hobbled for the vast majority of DAW's using ASIO. For that matter, I can't even remember the last time I attempted WDM even in Sonar.

I would still like to see the full RTL listing as well as comparable performance, maybe Pete can offer up something there. My understanding there are still a few grey areas with the units overall , its very interesting that they are using an Analog Devices Controller , which could tie in with some of the grey.

In the end its the delivery that matters and cudos to you for stepping up and addressing the earlier review, at least it got Rolands attention and we are all the more informed over it.

Peace.

V.C

Re: Audio Interface - Low Latency Performance Data Base :

PostPosted: Thu Sep 26, 2013 12:32 pm
by Pete Kaine
TAFKAT wrote:
I would still like to see the full RTL listing as well as comparable performance, maybe Pete can offer up something there.

I was under the impression Tom had already furnished you with one a few months back? Let me check to see if he has one on record when he returns from the show next week, otherwise it can go on the to do pile.

My sticking point with it appears to come down to compatability with the X79 chipset and I've multiple confirmations on it now from Roland themselves. I may have a couple of skype chats lined up with Japan to look into this in more depth if no easy answer is found, so it looks like those guys are getting on top of it now which is great to see. Needless to say I'm a lot happier at this point too!

Re: Audio Interface - Low Latency Performance Data Base :

PostPosted: Thu Sep 26, 2013 6:11 pm
by Sam Inglis
Goddard wrote:

FWIW, the "Reduce CPU load" ASIO driver setting option is documented on p.55 of the Studio-Capture pdf manual, and afaik was first introduced in Roland's version 1.50 VS drivers (as documented in the V. 1.50 Quad-Capture driver update release notes).

The 'Reduce CPU Load' box is indeed documented, but the documentation doesn't mention it having an effect on latency. The way it's described made me think that if anything it would make the latency higher.

Re: Audio Interface - Low Latency Performance Data Base :

PostPosted: Thu Sep 26, 2013 10:08 pm
by Goddard
Sam Inglis wrote:
Goddard wrote:

FWIW, the "Reduce CPU load" ASIO driver setting option is documented on p.55 of the Studio-Capture pdf manual, and afaik was first introduced in Roland's version 1.50 VS drivers (as documented in the V. 1.50 Quad-Capture driver update release notes).

The 'Reduce CPU Load' box is indeed documented, but the documentation doesn't mention it having an effect on latency. The way it's described made me think that if anything it would make the latency higher.

True enough, although Patrice B. had previously noted (in 27th March post #1040100 above) lower RTL when the 'Reduce CPU load' option was ticked.

Re: Audio Interface - Low Latency Performance Data Base :

PostPosted: Thu Dec 05, 2013 3:13 am
by Patrice Brousseau
Unfortunately, I've been away from this forum for a lot of reasons but...

I repeat, 48 samples (Windows or Mac): 6.3-6.4 ms RTL, not bad I think for an USB2 device ...

64 samples equal 7.1 ms RTL in Mac and somewhat a little bit higher in Win7 64.

Now, I can't do the other tests as I don't have the needed software for the complete Soundcard Latency Tests. So, I don't know how well the Roland interfaces scores in this department.

And obviously, I use an I5 chipset on a MacBook Pro early 2011 with Reaper.

Greatly satisfied with this interface.

**Strangely, moving the buffer slider in the Roland control panel under OSX impacts the safety buffers and it could read as low as 6ms in and out but I don't know if it is real or if audio breaks up more easily with such little safety buffers (reported by AuLab BTW).

Should I also add that the performance of the Roland/Reaper combo seems better under Bootcamp. However it is quite fine for my use in OSX Lion/Mavericks.

Patrice

Re: Audio Interface - Low Latency Performance Data Base :

PostPosted: Thu Dec 12, 2013 9:59 pm
by TAFKAT
Patrice,

I see you are posting across multiple forums re the cryptic lower RTL settings , you went off 1/2 cocked at G.S claiming flawed data , etc, when I don't even have these interface in the database, so lets connect the dots shall we.

I'll repeat what I posted at GS, RTL is only one factor in calculating the LLP, we need to know the actual performance at the respective latencies to have a true comparative , maybe Pete or Tom at Scan can help clear that up for us.

The LLP result you noted was Scan's internal testing which has been right on the money comparatively to mine, despite having different reference systems, so I have full confidence in their data.

If they have the time and energy they may be able to test with the new driver / decrypted settings.

V.C

Re: Audio Interface - Low Latency Performance Data Base :

PostPosted: Mon Dec 16, 2013 7:15 pm
by Patrice Brousseau
Thanks for your reply. Sorry to be so obsessive about it...

BTW, I don't know what "1/2 cocked" means (French speaking here) but I would guess that it's not a compliment :)

Patrice

Re: Audio Interface - Low Latency Performance Data Base :

PostPosted: Thu Dec 19, 2013 3:27 am
by Martin Walker
Patrice Brousseau wrote:BTW, I don't know what "1/2 cocked" means (French speaking here) but I would guess that it's not a compliment :)

Going off half-cocked means "to speak or act prematurely." ;)


Martin

Re: Audio Interface - Low Latency Performance Data Base :

PostPosted: Fri Apr 18, 2014 11:05 am
by Goddard
What about benching at different sample rates?

(also posted in parallel thread over on GS)

Re: Audio Interface - Low Latency Performance Data Base :

PostPosted: Wed Apr 30, 2014 1:00 am
by TAFKAT
Goddard wrote:What about benching at different sample rates?

(also posted in parallel thread over on GS)

I'll have a go at converting some of the sessions to 96K , I have some DAWbench DSP Cubase sessions already , I'll just need to convert the DAWbench VI's.

As I mentioned on the other thread, it will be impossible to retest all the interfaces, but I'll try and do some runs at 96K on future tests.

V.C

Re: Audio Interface - Low Latency Performance Data Base :

PostPosted: Sun May 04, 2014 2:35 pm
by Goddard
Great! Much appreciated. Should be very interesting (even though I'm no longer personally using Cubendo).

The only benching data I've come across so far wrt high-sample-rate audio was in Noel B's CW blog post wrt proprietary 192k testing of Sonar X1 under Win 8 of which you are already well aware. ;)