Does system performance matter when rendering not in real-time?

[UltraJv]

Most people don't realise that low latency audio requires some settings to be changed on your PC. It is a specialist area. One that CCRMA obviously didn't cover....

Actually they covered it. We rendered in LISP sometimes, really slow, taking breaks for garbage collection, etc. And yet, when the final WAV emerged, it had no crackling.

The info I gave from Steinberg is for hardware settings. I dont expect you to try them or anything productive. Youre doing well giving us the full benefit of your inexperience

[BachRules]

The info I gave from Steinberg is for hardware settings. I dont expect you to try them or anything productive. Youre doing well giving us the full benefit of your inexperience

I am asking you whether the VST's you've made generate audio defects when they render on slow machines? (Mine did not.) Why are you evading this question?

[JCJR]

Here is ONE possible way things can get messed up, that I have seen in the past. The proper recognition of the offline flag by host and plugin perhaps ought to make this impossible nowadays but to err is human and programmers are at least approximately human. Maybe your issue is something else entirely.

There are some plugins which spawn worker threads, I suppose so that they can garner a little more processor time and therefore have better odds of keeping up with realtime without dropouts.

The user doesn't want to wait longer than necessary for disk renders, so hosts will call the plugins process functions as quickly as disk activity, mixing, etc, will allow. Maybe on a fast system a song of several minutes duration will render in only several seconds.

So if something goes wrong and a plugin relies on a worker thread during a non-realtime disk render, then at this accelerated rate of calling the plugin's process function, the worker thread can fall behind, so that not enough data has been generated when the plugin process function is called, so the plugin "has no choice" but to return incomplete or erroneous audio data buffers to the host.

If the plugin knows it is being called non-realtime, then it can be written smart enough to wait on its worker thread, so that the disk render would take longer to complete, but the plugin output would be correct and complete. So if such a mechanism is responsible for your crackle, one would need to determine whether the host or the plugin is confused as to how it should behave.

[BachRules]

Here is ONE possible way things can get messed up, that I have seen in the past. The proper recognition of the offline flag by host and plugin perhaps ought to make this impossible nowadays but to err is human and programmers are at least approximately human. Maybe your issue is something else entirely.

There are some plugins which spawn worker threads, I suppose so that they can garner a little more processor time and therefore have better odds of keeping up with realtime without dropouts.

The user doesn't want to wait longer than necessary for disk renders, so hosts will call the plugins process functions as quickly as disk activity, mixing, etc, will allow. Maybe on a fast system a song of several minutes duration will render in only several seconds.

So if something goes wrong and a plugin relies on a worker thread during a non-realtime disk render, then at this accelerated rate of calling the plugin's process function, the worker thread can fall behind, so that not enough data has been generated when the plugin process function is called, so the plugin "has no choice" but to return incomplete or erroneous audio data buffers to the host.

If the plugin knows it is being called non-realtime, then it can be written smart enough to wait on its worker thread, so that the disk render would take longer to complete, but the plugin output would be correct and complete. So if such a mechanism is responsible for your crackle, one would need to determine whether the host or the plugin is confused as to how it should behave.

Thank you for your ideas on this. Depending on a worker thread without Waiting for it would seem to invite problems. Doing it while offline would be a bug. If you were programming a word processor and you used a worker thread but didn't Wait for it, and if it fell behind your program just inserted random words instead of what the user typed, you would not be making a good word processor, and if someone reported the problem, it'd be better business to fix the problem instead of telling the customer "you obviously have system problems, you need technical help to resolve them" and banning him, imho.

[Mayae]

It could sound like the plugin is rendering multi-threaded, and the threads can't keep up somehow, causing buffer underruns - possibly caused by the host offline rendering in threads as well, causing less time per thread..
It's still no excuse though, threads should be synced obviously.

Maybe you are suggesting a bug in Reaper (the host)? That would be technically possible, but I think unlikely, because they guys making Reaper seem very competent.

No, a bug in the plugin. The situation i wrote is exactly the same as JCJR.

[BachRules]

It could sound like the plugin is rendering multi-threaded, and the threads can't keep up somehow, causing buffer underruns - possibly caused by the host offline rendering in threads as well, causing less time per thread..
It's still no excuse though, threads should be synced obviously.

Maybe you are suggesting a bug in Reaper (the host)? That would be technically possible, but I think unlikely, because they guys making Reaper seem very competent.

No, a bug in the plugin. The situation i wrote is exactly the same as JCJR.

I see now what you mean. They'd need this:

Code: Select all

if Offline then Wait;

[JCJR]

Thank you for your ideas on this. Depending on a worker thread without Waiting for it would seem to invite problems. Doing it while offline would be a bug. If you were programming a word processor and you used a worker thread but didn't Wait for it, and if it fell behind your program just inserted random words instead of what the user typed, you would not be making a good word processor, and if someone reported the problem, it'd be better business to fix the problem instead of telling the customer "you obviously have system problems, you need technical help to resolve them" and banning him, imho.

I know nothing of the cust support issue. The person who responded inappropriately, COULD be an inexperienced low level employee or even a volunteer, and everybody can have bad days.

The mechanism I described may not be the only possible one, and it would be premature to place blame without at least testing the plugin in another host or two. It can happen that both host and plugin think they are doing the right thing, but wires get crossed regardless. Sometimes bugs will crawl out of the woodwork even after years of no complaints from the customers and one wonders why it took so long for a bug to show up.

I don't know how many plugins use worker threads. Am guessing that a minority of plugins spawn threads, but it is only a guess. Threading would make it more difficult to program properly, and I'd be afraid to try that unless its the only way to make it work at all, but there are lots better programmers out there than me.

[BachRules]

The person who responded inappropriately, COULD be an inexperienced low level employee or even a volunteer....

I know nothing of the cust support issue.

Their customer-support and coding-practices have earned them a reputation, which I won't go into here; but it's out there for anyone curious. I'd rather hear your thoughts about the technical side of this.

The mechanism I described may not be the only possible one, and it would be premature to place blame without at least testing the plugin in another host or two.

Another Spaces user wrote:

The more individual tracks you render to audio, assuming you have a separate audio drive, the more CPU resources you free up before final rendering to disc.... I,ll usually try rendering to Disc, but if I hear cracks and pops I'll start Rendering to audio, starting with the most demanding of CPU/HD tracks.... With Pro Tools this method has worked for me in the past so thought I'd throw it out there.

http://www.soundsonline-forums.com/show ... stcount=10

When he wrote "I'll start Rendering to audio", I think he meant he'd freeze individual tracks to prepare for rendering. Not sure what else he could have meant.

I don't know how many plugins use worker threads. Am guessing that a minority of plugins spawn threads, but it is only a guess. Threading would make it more difficult to program properly, and I'd be afraid to try that unless its the only way to make it work at all, but there are lots better programmers out there than me.

I'd be concerned that the thread-scheduler would not be tuned for low-latency realtime audio, but there are plenty of programmers here who know more about that than I.

[otristan]

FWIW, for a convolution reverb plugin, you use very often worker thread if you do a partitioned convolution.

You must in that case check for the offline flag in the plugin format and wait for it to be completed.
(You can do it in realtime as well depending if you want to fail on the sound level or on a miss buffer in case of late worker thread)

This is true as well for plugin which stream samples from the HD for example.

my 2 cents

[FLWrd]

Don't get upset, BachRules. They are trying to help, but their technical knowledge is not deep. I know off-line rendering shouldn't involve the audio interface, and that actually the DAW/sequencer is there as a shield between the plugin and the audio driver, so the plugin shouldn't even have to worry about drivers at all. But East-West always comes up with that excuse. The most positive reason that I can think of is that Play gets messed up internally by some audio drivers, the most negative one that that allows them to put the blame somewhere else and mark the issue as resolved.

BTW the threads issue might be testable. Open a process viewer, render without Spaces, and render with, and look at the difference in thread count.

[durkkooistra]

Pretty crazy they are still in business. Ever since the change from Kontakt to Play the only times I heard about them was because of either or both bugs and bad customer service.

[seldom]

Typical KVR.

[FLWrd]

Pretty crazy they are still in business. Ever since the change from Kontakt to Play the only times I heard about them was because of either or both bugs and bad customer service.

No, that's not so weird. Their samples are top-notch, and most customers just have one or two tracks with some simple arrangement. Problems start when you go a bit further. There have been complaints about the pianos for as long as Play exists. Never recognized, yet allegedly fixed in a recent update. But most people don't write complex music, so they won't notice it.

[hot_frequency]

Can you provide some further details, BachRules?

Processor of machine, amount of ramm, active track counts, plugin usage on each of the tracks?

[BachRules]

Can you provide some further details, BachRules?

Processor of machine, amount of ramm,...

... active track counts, plugin usage on each of the tracks?

Here is a Reaper project which causes crackling when I render it:

https://drive.google.com/file/d/0B5ZYXb ... sp=sharing

16 tracks, each with a heavy-duty VST, to challenge the system (I used EWQL Choir). No MIDI, except on track 1. One instance of Spaces, on track 1. When I render, I get crackling. Here is a WAV rendered from that test project on my system:

https://drive.google.com/file/d/0B5ZYXb ... sp=sharing

If I do the same thing without the 15 dummy tracks included, there is no crackling.