Quantifying CPU / RAM optimization

[Brian McCully]

I’m using a Mac G5 dual core 2.3GHz, 4GB RAM, OSX 10.4.9, hammerfall card for MIDI and lightpipe. TTSolo operating S2.1 only, with a small MAX app booted to combine the MIDI inputs from a TD-10 and a TD-3, since TTSolo doesn’t support merged inputs. Nothing else booted. It’s a dedicated to drums only computer.
I load up a full S2.1 kit (~950 Mb), playing off my E-Drums (~30 possible trigger notes total), and experience intermittent clicks and pops.
Latency is set to 64. Noticeable sluggish response if latency is 128.
I’ve read the manual many times through – especially on the CPU and RAM topics of Resource Management, and I conclude that all that is presented is general suggestions, with nothing quantified. Fine. The manual suggests that I can go to 16 bit mode, or try caching, or turn off all of the bleeding channels, or perform voice limiting (on individual articulations…that should be fun typing in all those 0 0 0’s), or turn off a few cymbals that I hit every so often, or turn off the meters, etc etc…
I opened the Mac application Activity Monitor to check out CPU usage, RAM allocation, etc. while TTSolo is booted. Seems to be plenty of RAM available (2 Gigs free) and playing a lot of notes (lots of long decay cymbal rolls, etc) gets the CPU % user up to about 65% max (idling is about 25%). Some clicks.
Is there an actual visual and quantifiable method of determining how much is too much, before the clicks and pops start?
Secondly, what is the exact suggested order to turning things off – to stop the clicks? Bleed, first? Less Articulations? thanks, -Brian

Topic

[Damian Blunt]

I’m not a mac user but a couple of questions –
 
Do you have may effects enabled in the mixer?…that can increase CPU hit
 
Have you tried running the MIDI out on your TD-3 into the MIDI in on your TD-10? (make sure you have soft thru selected) I’m sure this wouldn’t have a huge impact but it would mean something else not running and maybe worth a try
 
 

Damian Blunt - Toontrack
Quality Assurance
Betatesting

[Rogue]

I think the first thing I would check is whether your MAX-DSP based MIDI driver play any part in your issue (and use Gdaddy’s advise to interlink your two TMC as an alternative)… at the end of the day, let’s face it, if at 128 buffer you get noticeable latency then whatever is going on with the incoming MIDI stream must be non trivial in term of CPU time, and therefore must have a cost. It’s only a step to assume this translates in CPU spikes?

Anyway, I would not recommend a software based input merger. Hardware MIDI mergers are cheap and (typically) operate fast enough to be transparent in use. Solo will support multiple inputs in the not too distant future although I can’t make any promise at this stage whether it will drop in within weeks or a couple of months. It won’t be much more than that in any case.

Rogue Marechal - Toontrack
Configuration Manager

[Brian McCully]

ORIGINAL: grandaddy
Do you have may effects enabled in the mixer?…that can increase CPU hit

Have you tried running the MIDI out on your TD-3 into the MIDI in on your TD-10? (make sure you have soft thru selected) I’m sure this wouldn’t have a huge impact but it would mean something else not running and maybe worth a try

I have no effects enabled. Just using the default full kit as a testing ground while I try to figure it all out.
The MAX app only takes 1-2% of the CPU, which is a lot less overhead than booting a sequencer to host S2.1. It’s a very simple merge patch. I haven’t tried patching a soft thru – I’ll have to investigate whether the TD-3 output triggers anything in the TD-10 that I don’t want triggered (trying not to have overlapping midi note maps that work easily with S2.1 has been a royal pain to set up), as I’m using the TD-10’s 8 outputs and TD-3’s stereo audio as well, mixing it with the S2.1 output (via ADAT optical) to a separate console for 5.1 type monitoring – VDrums just sound a lot better when playing them in surround.

[Brian McCully]

ORIGINAL: Rogue

I think the first thing I would check is whether your MAX-DSP based MIDI driver play any part in your issue

I can assign just the TD-10 as the MIDI input (it is the trigger for most of the pads) in TTSolo and not use MAX, resulting in no difference in latency – i.e. there is latency at 128 regardless of whether the MAX patcher is involved or not. There is no latency at 64 (using MAX or not). Does the Latency setting affect MIDI triggering – I thought it was a sample related setting?

I also do not quite understand the ‘non trivial’ assessment – any host sequencer DAW will perform MIDI merging – and there is much more CPU headroom loss associated with booting a Cubase or DP or Logic, etc. than a simple MAX patcher. Is it recommended that users do not use a DAW/Sequencer to play S2.1 live?
I was only using TTSolo for just this reason.

Adding a hardware merger will definitely introduce latency. I have them, have used them. They definitely slow things down and also do not always work properly, depending on the type of data put through them. I’d rather avoid one more thing in line anyway.

Back to my original questions…
Is there an actual visual and quantifiable method of determining how much is too much, before the clicks and pops start?
Secondly, what is the exact suggested order to turning things off – to stop the clicks? Bleed, first? Less Articulations?

[Damian Blunt]

ORIGINAL: Brian McCully

I also do not quite understand the ‘non trivial’ assessment – any host sequencer DAW will perform MIDI merging – and there is much more CPU headroom loss associated with booting a Cubase or DP or Logic, etc. than a simple MAX patcher. Is it recommended that users do not use a DAW/Sequencer to play S2.1 live?
I was only using TTSolo for just this reason.

I think the idea is to remove anything unknown that could potentially cause CPU spikes etc……..It may not be this but it’s worth trying

ORIGINAL: Brian McCully

Back to my original questions…
Is there an actual visual and quantifiable method of determining how much is too much, before the clicks and pops start?
Secondly, what is the exact suggested order to turning things off – to stop the clicks? Bleed, first? Less Articulations?

The extra articulations will just take up more RAM and not have an impact on CPU.  Disabling bleeds will decrease CPU use. 

There would be no way of determining how much is too much….it’s very much dependent on the audio hardware / drivers and the system they’re installed in….plus any other stuff that may be running in the background….hardware conflicts etc. etc.

I have a dual core PC with 4gb Ram and RME 9632 card and can play my TD-12 live with a 3gb kit loaded ( all bleeds selected ) at the lowest 32 sample buffer setting with no clicks or pops whatsoever.

Damian Blunt - Toontrack
Quality Assurance
Betatesting

[Rogue]

Does the Latency setting affect MIDI triggering – I thought it was a sample related setting?

Let’s try to answer your question another way. what you perceive as latency is the time for a number of distinct processes to occur, from the ‘trigger to midi conversion’ in the module, the MIDI interfacing part, the audio processing inside Superior and finally output to sound card by solo. The buffer size inside solo only affects what happens after the MIDI reaches the program.

If you are significantly affected by the latency at a low buffer value then the issue must be before it even reaches solo. If you have tried to take the MIDI processing that sits, in software, in front of solo then your problem may be at your MIDI interface level. Have you tried turning your module(s) to ‘local off’ to minimize latency in front of your interface? update your MIDI drivers?

Regardless, I think that you should try to look for the issue in any background processes that may interfere with the audio processing first and foremost (hence my suggestion to discard the MAX processing). Turn off Airport and disable Bluetooth. These are known causes for CPU hangs and perhaps are what you are experiencing.

Rogue Marechal - Toontrack
Configuration Manager

[John]

Hi,

I’d check 2 things besides what’s been suggested:
1) your Audio/MIDI device driver, it may need updating
2) turn LOCAL=OFF in your module

Running @ 64 samples gets you a latency of 1,45 ms in TT solo(not considering the module’s latency and your D/A converters)
Running @ 128 samples will only add another 1,25 ms (totals=2,7 ms), which seems hard to imagine it should count as considerably sluggish compared to the former setting.

Best Regards,
John

John Rammelt - Toontrack
Technical Advisor

[Brian McCully]

The extra articulations will just take up more RAM and not have an impact on CPU.  Disabling bleeds will decrease CPU use. 

There would be no way of determining how much is too much….it’s very much dependent on the audio hardware / drivers and the system they’re installed in….plus any other stuff that may be running in the background….hardware conflicts etc. etc.

I have a dual core PC with 4gb Ram and RME 9632 card and can play my TD-12 live with a 3gb kit loaded ( all bleeds selected ) at the lowest 32 sample buffer setting with no clicks or pops whatsoever.

Most DAWs have a CPU ‘usage gauge’. TTSolo doesn’t. I did not see any CPU spikes register in the Activity Monitor application.
I’m using the RME 9652 card (2nd generation). I don’t know if it’s possible to set it to 32 samples – there is no menu selection for that low of a setting in its software, and Digital Performer only allows a lowest setting of 64 via this card (not sure about Logic or Cubase). But 64 in TTSolo seems to work for me for a latency setting. 128 seems to be ‘spongey’ for lack of a better term – it’s playable but not squeaky tight. Definitely a difference between the two settings, all else being the same.
It’s pretty amazing that you can load up all of 3GB of drum sounds, set latency to 32 and have no glitches…is everybody else experiencing this?

[Brian McCully]

Let’s try to answer your question another way. what you perceive as latency is the time for a number of distinct processes to occur, from the ‘trigger to midi conversion’ in the module, the MIDI interfacing part, the audio processing inside Superior and finally output to sound card by solo. The buffer size inside solo only affects what happens after the MIDI reaches the program.

If you are significantly affected by the latency at a low buffer value then the issue must be before it even reaches solo. If you have tried to take the MIDI processing that sits, in software, in front of solo then your problem may be at your MIDI interface level. Have you tried turning your module(s) to ‘local off’ to minimize latency in front of your interface? update your MIDI drivers?

Regardless, I think that you should try to look for the issue in any background processes that may interfere with the audio processing first and foremost (hence my suggestion to discard the MAX processing). Turn off Airport and disable Bluetooth. These are known causes for CPU hangs and perhaps are what you are experiencing.

Thanks for all of the suggestions from everybody.
Since the buffer size inside solo only affects what happens after the MIDI reaches the program, and I know that 64 is fine and 128 is spongey, then it’s inside of TTSolo that is at question. If I could play at 64 with no clicks or pops (with a full kit loaded), I’d be ace. Anyway, I tried a number of things – I updated the system to OSX10.4.11, made sure the RME 9652 card driver was the latest, made sure that system prefs Energy Savings was for ‘Highest’ processer speed (it was), tried both TD-10 and TD-3 modules with Local off, and Airport and Bluetooth are long ago turned off (they were, although bluetooth doesn’t exist on this Mac). Still the same results, so far.

[Brian McCully]

ORIGINAL: John

Hi,

I’d check 2 things besides what’s been suggested:
1) your Audio/MIDI device driver, it may need updating
2) turn LOCAL=OFF in your module

Running @ 64 samples gets you a latency of 1,45 ms in TT solo(not considering the module’s latency and your D/A converters)
Running @ 128 samples will only add another 1,25 ms (totals=2,7 ms), which seems hard to imagine it should count as considerably sluggish compared to the former setting.

Best Regards,
John

Yes – I did those checklist items. And I’m sure that your math makes sense, and I know that a couple of milliseconds don’t make a difference (below a detectable level) – but…I know for a fact that changing between 64 and 128 is a definite feel difference. I’ve been trying to convince myself otherwise, but…no luck so far in what I perceive. I wish it was my imagination and not this software/hardware combo. -Brian

[Jason Runyon]

Have you tried disabling your wireless while running these apps?  there was an airport update a while back that was known for causing these issues.

[Brian McCully]

There’s no wireless. This G5 is off-line, not connected. Not even on a hub or router. No Airport, bluetooth, etc.
If I need to update the machine, I’ll stick the ethernet cable into it every once in a while. thanks,-Brian

[Brian McCully]

ORIGINAL: John
I’d check 2 things besides what’s been suggested:
1) your Audio/MIDI device driver, it may need updating
2) turn LOCAL=OFF in your module

Running @ 64 samples gets you a latency of 1,45 ms in TT solo(not considering the module’s latency and your D/A converters)
Running @ 128 samples will only add another 1,25 ms (totals=2,7 ms), which seems hard to imagine it should count as considerably sluggish compared to the former setting.

For comparison I switched from using the RME card to using a firewire MOTU 828 interface, plus updating all of the MOTU drivers. Still get the same results.
Latency settings: 128 is playable, 64 is better and tighter, but not usable for the occasional clicks/pops. 256 is barely usable for real time (I wouldn’t attempt this normally – I was just trying it) and 512 is definitely unusable, basically a slapback (and sanity check). Using the Apple Utility’s Activity Monitor I did notice about a 5% (maybe 10%) CPU usage decrease when I toggled off the Mix window meters and visual ‘hit’s in the Construct window. I have a Intel dual core MacBook that I will try soon with the VDrums and 828 – it’s about the same speed as the G5 (2.2.GHz), but it’s limited to 2GB max of RAM. I loaded up a full S2.1 kit with it and it seemed ok just mousing around.

[John]

OK,

personally I’m using a Digidesign 96 I/O Audio interface and a USB MIDI interface/keyboard connected to my TD-12.
I have it set at 64 samples in Toontrack solo and load pretty big kits (2-3GB) and to me it’s quite playable and I do not get pops.
This is in OS 10.5.6 on a 4 Core Mac Pro with 8GB RAM.

Best Regards,
John

John Rammelt - Toontrack
Technical Advisor

[Brian McCully]

ORIGINAL: John

OK,

personally I’m using a Digidesign 96 I/O Audio interface and a USB MIDI interface/keyboard connected to my TD-12.
I have it set at 64 samples in Toontrack solo and load pretty big kits (2-3GB) and to me it’s quite playable and I do not get pops.
This is in OS 10.5.6 on a 4 Core Mac Pro with 8GB RAM.

Best Regards,
John

Seems that you’ve got a newer system that is more in line with what is required to get this application to work properly for E-drums. And G’daddy’s. I re-checked the listed system requirements for S2.0 and a minimum ‘dual G4 1.25GHz’ would probably be sufficient for playback only, maybe. That’s what I was using for EZ Drummer. While the recommended system states a ‘modern G5’, I think it’s going to be borderline – like in my case – for live triggering. I -think- I have plenty of RAM installed, but the answer so far is there’s no answer, as ‘systems’ are too variable, i.e. too many possibilities of hardware or software conflicts, etc. But I’m running it bare-bones. Quite possibly TT may want to re-consider or hone what the recommendations are (maybe they are posted elsewhere for TTSolo and live performance…), and address the TTSolo feature set, to allow for some system performance monitoring, which is a standard DAW feature (like a gas gauge on a car). And/or hopefully help me figure out why a stock 2.3GHz G5 can’t handle the performance. Bench tests? -Brian

[Author]

Replies