Improving Push 2 Latency w/o an audio-interface

[ceounicom]

-Hi,

I'm new to push 2, and when i first got it running w/ Ableton i was disappointed to learn that it was more, shall we say "resource intensive" than other MIDI controllers i've used, most of which were just plug-n-go

Basically, i have a 5yr old PC and Push 2's display driver put a major hit (~15%) on the CPU, which was unexpected. Oh well. So i got a bigger/better CPU cooler and will just have a little less CPU overhead, which i can deal with.

The other thing that is more concerning is i've found there is sometimes some pretty bad latency when recording w/ Push while using more-complex device racks. This is probably not necessarily a "Push-problem", but rather a factor of having no external audio-interface at the moment.

Yes, I know i need a soundcard/box if i want to reduce latency, but i've being doing things without one for a little while and it works *reasonably* well, and i'm just trying to maximize the usability with what i've got at the moment.

So, 2 things i've done to try and improve the responsiveness of Push is 1) max out the pad sensitivity, and 2) when recording midi, run the sample rate up to 96kHz, which cuts latency about in half with the ASI0O4All driver (to about 7-12ms)

I don't generally do 96K *recording*; I'm still pretty much all 16/44.1 in everything, mainly because its what my legacy sample-library is in, and because i don't feel there's much benefit for my stuff.

But here's the question: do other people do this, "temporarily switch the sample rate up to 96K" just to record MIDI, then switch it back down when doing playback, so you can reduce the CPU-load with many instruments playing? It seems to be my current M.O., and i wonder if maybe i'm doing something wrong/stupid, even tho it seems to work, more or less.

What are your experiences/setups for getting the best responsiveness out of Push 2 as a recording-instrument? Please: spare me any "get a mac/upgrade-your-everything" canned-responses. I know, i know.*

(*The thing is, I'm just not doing any live audio recording at the moment, and if/when i do get a new audio-interface, i'm aiming to get one which will interface with some of my legacy recording equipment (e.g. digital mixer with 16 ADAT i/o); the cheapest ones which satisfy all my needs are like $400-800, so until i've got some real need to record live music again, i've basically put it off indefinitely)

anyway, thanks a bunch for any thoughts

[ceounicom]

Footnote:

that said, if people know of a *supercheap* interface option which can drastically improve ableton latency (say, $100 or less), I'd be interested in hearing people's experiences.

So far I've heard mixed opinions of some of the common stuff out there (some people have complained about latency problems with Focusrite scarlett stuff, etc) and generally, if it doesn't offer at least 8-ADAT i/o, it has limited utility for me.

I've also heard people say that there are a few other tricks to reduce latency, like turning off all audio inputs, disconnecting any other devices on your USB bus, etc. Curious to hear from people what actually works the best, vs. what is just 'theoretical' improvement.

[rekloos]

Don't think you'll find a silver bullet type of interface that'll fix it up for ya and i hate to say this to you but computer specs do matter...

Also, there will always be a 15-20% cpu hit as soon as you turn on Push, no way around it, it needs the resources to get those pretty colors/graphics proper.

Track count matter (less tracks+less cpu), routing of trax matter, things like that you can play with and see what works, i kinda learned to live with the cpu hit+latency, i'm usually recording @ 128-256 samples (inside Live's Preferences)and i'm fine but if you're a proper key player and 'quick response' matters to you, you'll have to cut some corners to get that 32 samples action.

[Stromkraft]

The other thing that is more concerning is i've found there is sometimes some pretty bad latency when recording w/ Push while using more-complex device racks. This is probably not necessarily a "Push-problem", but rather a factor of having no external audio-interface at the moment.

…

Please post the specifics. CPU, RAM, disk and so on.

I don't see how latency applies to the Push 2 at all here. There should be no different latencies during a session, unless you add devices at any point to your signal path that do processing that adds extra latency. Max For Live devices sometimes adds huge extra latencies on top of what you have already, and some plug-ins/devices do as well, at least in some configurations, like when oversampled.

I should investigate that first. Remember that MIDI performance latency is only partially affected by the audio buffer setting. The time from note activation to instrument is affected by everything on the path, both MIDI effects and audio effects as these typically need to be delay compensated. One track that's quite late is enough. What happens if you use "Reduced Latency When Monitoring"?

The normal reaction for the Push (I use the first), and the Push 2 as well I think, is for it to get more sluggish the harder the machine is working. I can't rule out that a sluggish Push 2 would add latency in practice, however feels unlikely, but if this is what you're experiencing then you're asking too much from your machine. It's simply too weak. Ask less from it or get a faster one.

One strategy can be to make sure you only use 0 sample latency instruments and processing when recording.

But here's the question: do other people do this, "temporarily switch the sample rate up to 96K" just to record MIDI, then switch it back down when doing playback, so you can reduce the CPU-load with many instruments playing? It seems to be my current M.O., and i wonder if maybe i'm doing something wrong/stupid, even tho it seems to work, more or less.

Do what actually works for you and don't worry about this too much. I change how I work when needed.

However, are you actually saying here that you were at the minimum buffer setting at 44.1 kHz and the only way to get less was to move up to 96?

[ceounicom]

Please post the specifics. CPU, RAM, disk and so on.

3.3ghz, 8core AMD processor, 8gb ram, 7200 hdd, win10 64bit

I don't see how latency applies to the Push 2 at all here.

Its possible i've only noticed existing latency-issues because i'm using Push so exclusively as an input device rather than regular midi key controllers, where keys have long travel and less of a sense of 'missed' strikes. The Push also add that 15-20% to CPU usage, which may not have any role in latency... but does ramp up when changing sample rate to try and lower it.

are you actually saying here that you were at the minimum buffer setting at 44.1 kHz and the only way to get less was to move up to 96?

I never really got any glitches/drops @ 44.1, but the latency was most noticable
When kicking the sample rate up to 96, it cuts the latency ~ in half

e.g. a 512 buffer in ASIO @ 44.1 produces about 32ms latency, a similar buffer @ 96K results in about 17ms which is distinctly more 'playable'.

There is obv much more hit on my CPU when running @96k, but if i just record parts @96, then switch back to 44.1 for mixing, it basically gives me back that extra CPU headroom.

My question was basically describing, "here's what i'm doing to get better results", and wondering whether this makes any sense, or whether people have better ideas/best practices for maximizing push-playability when dealing with the (admittedly crappy) driver-latency of stock computer MB audio.

A second side-question might have been, "any suggestions for cheap audio-interfaces that provide significant reduction in system latency"

[login]

I suppose you have tried reducing the buffer size to get lower latency? 512 samples is quite high but if going lower produces pops and clicks while using the asio4all driver I am sorry to tell you you have pretty much hitting the ceiling of your current configuration.

Turning off bluettoth, antivirus, even wifi can help also but really the only step that could help is getting an external soundcard with good audio drivers, your CPU is more than capable for running lower latency session.

The cheapest interface I would recommend with good ASIO drivers in windows is the Steinberg Ur22.

[ceounicom]

I suppose you have tried reducing the buffer size to get lower latency? 512 samples is quite high but if going lower produces pops and clicks while using the asio4all driver I am sorry to tell you you have pretty much hitting the ceiling of your current configuration.

I can start a project running lower - 256 in most cases - but as a projects adds tracks and VSTs, i generally have to slide up to 512 by the time its getting fully-fleshed-out.

I could could/should probably freeze tracks after i get more than a few, but generally with my workflow i'm making minor changes to everything as I go, so i tend to never bother w/ that.

Thanks for the suggestion.

[jestermgee]

Yeah AMD processors for a start aren't the best for audio stuff. Not to start any wars for AMD lovers, but most choose Intel.

If you do not have a dedicated audio interface, that would be the first I would suggest. If you can shell out all that cash for Live/Push you should also be prepared for the other links in the chain too.

Most of the performance issues you have with latency will be because of the lack of dedicated audio interface. Asio4all is a stop-gap solution that may improve things a little, but it still has to work with a device not designed for the strain of real-time audio reproduction.

- If you have a lot of junk installed on your PC it will cause a lot of extra stress on your processor.
- The speed of your RAM also matters in terms of Transferring data from memory to CPU to Audio Processor
- SSD drives will help a great deal especially with such a small amount of RAM
- Audio interfaces are very important to help cut down your overall latency

[ceounicom]

The cheapest interface I would recommend with good ASIO drivers in windows is the Steinberg Ur22.

I've been looking into this as an option, and noticed quite a bit of discussion surrounding problems people are having recently w/ audio dropouts and UR series interfaces

https://www.steinberg.net/forums/viewto ... 00#p692820

As recently as last month, many people say its still unresolved. They've released a number of driver updates (most recently Nov 30) and have another in beta-test. I'm curious: have you been using one of these interfaces yourself in a windows environment?

Are there any other models you think might have better-established drivers? I've heard mixed views about Focusrite gen1, but it seems like gen2 interfaces are better-received.

Yeah AMD processors for a start aren't the best for audio stuff. Not to start any wars for AMD lovers, but most choose Intel.

Thanks for the feedback, but i wasn't asking a question about 'what PC-CPU to buy'. I've built a half-dozen DAW rigs w/ AMD cpu's over the years and never had a single issue with any of them. Sure, they might underperform Intel on the highest-benchmarks, but in terms of general audio-work, they're perfectly adequate. I doubt if all else were the same, that merely having an intel processor would result in any less than the ~17-30ms latency i can squeeze out of the ASIO4ALL driver, sans any external interface.

If you have any recommendations for any low-cost USB audio interfaces with stable/low-latency win10 ASIO drivers, i'd be happy to hear them. thanks

[scheffkoch]

...kinda rude reply to someone who wanted to help you...there are a lot of other users with lower spec intel computers that don't have the symptons you describe...just sayin...

[ceounicom]

...kinda rude reply to someone who wanted to help you...there are a lot of other users with lower spec intel computers that don't have the symptons you describe...just sayin...

No offense intended. I thought my first question had pre-empted some of this.

Do you have some helpful suggestions?

[Stromkraft]

I never really got any glitches/drops @ 44.1, but the latency was most noticable
When kicking the sample rate up to 96, it cuts the latency ~ in half

e.g. a 512 buffer in ASIO @ 44.1 produces about 32ms latency, a similar buffer @ 96K results in about 17ms which is distinctly more 'playable'.

There is obv much more hit on my CPU when running @96k, but if i just record parts @96, then switch back to 44.1 for mixing, it basically gives me back that extra CPU headroom.

–
A second side-question might have been, "any suggestions for cheap audio-interfaces that provide significant reduction in system latency"

I see what you mean now. With native audio halving the buffer doesn't halve the output latency.

So with the native audio in a quite old MBP vs my RME Babyface:
1024 samples> 34.7 ms vs 24.6 ms
512 samples > 23.1 ms vs 13 ms
256 samples > 17.3 ms vs 7.23 ms
128 samples > 14.4 ms vs 4.33 ms
64 samples > 13 ms vs 2.88 ms
32 samples > 13 ms vs 2.88 ms

as was said output latency is only part of performance latency, but as you can see the difference between native audio and a dedicated high quality audio interface can be drastic. Note that this is not with the latest drivers from RME for macOS 10.12. I expect to be able to shave of at least a millisecond on most figures there.

You can see why getting a good audio interface could be a great idea. I've heard good things about some Roland interfaces, but never tried these myself. I will never get a Native Instruments audio interface again myself, at least not one of their cheapest ones.

Focusrite can be really good as well, but I understand the cheaper ones are perhaps not to recommend. I know some people feel they work great though.

Probably best to listen to people using interfaces with your OS and your Live version and maybe even hardware.

I don't think you can dismiss (some) developers stating they support Intel only and not AMD. That something should work and have worked, doesn't mean it always will.

But sticking to using AMD will teach you more about how well it can work. Just keep track of which makers support only Intel and maybe ask them why. Maybe it's a just a support question for them?

Like how I suspect Apple don't want to actively support the backup machine I'm using now, an older MBP, with macOS 10.12 "Sierra". So they actively prevent you from installing that. But here I am using it nevertheless, fully aware Apple won't help me if I have any issues.

[ceounicom]

I see what you mean now. With native audio halving the buffer doesn't halve the output latency.

Actually, the example i gave was comparing the difference i get in latency by doubling the sample rate, while maintaining a fixed buffer.

In my particular case, with this crappy ASUS motherboard's audio, the difference is not quite half (~30ms/17ms); i wouldn't expect this to be the same for other people's rigs, and i wouldn't expect it to scale linearly anyway.

the numbers you get with your own native-MBP-audio aren't terribly different than what i've seen on PC; the mac is better, but not by huge amounts.

I'm a little irked there aren't better/cheaper PCIe audio-card options out there; the interface i'd used for a decade+ was this guy

...and while it limped along with win7 for a year or two, it was more or less abandoned. The only comparable things currently out there seem to be RME/Motu. And while they're both totally worth the money, they tend to be far more than i need right now just to run some vst based-projects completely in the box.

Of the cheap/temporary options I'm looking at, the Focusrite Scarlett series seem to be the best-supported. I liked the look of the Steinberg U22 (and they are very affordable) but i'm a bit scared off by the user-base freaking out in their forums (link above)

Maybe interesting to some people as a resource: i came across this Gearslutz contributor who maintains a benchmark database of audio-interface latency. I don't think its intended as an example of absolute #s (everyone's rigs are obviously diff), but just for comparison purposes.

[ceounicom]

I don't think you can dismiss (some) developers stating they support Intel only and not AMD.

Probably not. But then i've never actually yet encountered a single piece of hardware/software that i absolutely *needed* (and didn't have any easy-replacement alternative) which has yet made any such statement. The aforementioned Frontier Designs hardware which abandoned development didn't do so because of 'processors'. They simply went bust, as companies are sometimes known to do.

[Stromkraft]

I see what you mean now. With native audio halving the buffer doesn't halve the output latency.

Actually, the example i gave was comparing the difference i get in latency by doubling the sample rate, while maintaining a fixed buffer.

Yes, I know that, but my counter-argument was "why not just halve the buffer?". If the output latency goes down by an equal amount in 44.1 kHz when halving the buffer, compared to go 88.1 or 96, then I'd assume the machine would have to work less hard in the former case, so that would be preferred.

Yes, the LLP Database is a great and useful resource. Thanks for posting that.