Using Double instead of Float increase noise?

[Chris-S]

What if in the middle of the iteration of the samples, the control pass to another thread (which is on the same cpu core) and start to process the ProcessDoubleReplacing of another plug B? Plug B will execute with the flag setted by plug A. I'm in the same "Process" within the DAW (so control word are shared across plugins), since VSTs are DLL (but honestly this depends by the host DAW; some will use the same process task, some could fork it on every DLL, and so on).

The OS handles this - without which multithreading wouldn't be possible.

Yes, but normally different VSTs are running in the same thread.

[mystran]

What if in the middle of the iteration of the samples, the control pass to another thread (which is on the same cpu core) and start to process the ProcessDoubleReplacing of another plug B? Plug B will execute with the flag setted by plug A. I'm in the same "Process" within the DAW (so control word are shared across plugins), since VSTs are DLL (but honestly this depends by the host DAW; some will use the same process task, some could fork it on every DLL, and so on).

The OS handles this - without which multithreading wouldn't be possible.

Yes, but normally different VSTs are running in the same thread.

Yes, but normally control doesn't magically pass into another plugin in the middle of your process-callback in the same thread... so as long as you restore the CPU state in between process-callbacks in whatever thread the host decides to use, the OS will take care of the rest (ie. whatever is going on in other threads concurrently).

There is absolutely no problem in any of this, except the problem of understanding that no problem exists.

[camsr]

Now I'm confused though, if concurrent DLLs are called in the same thread, could a control register stay set between them?

[mystran]

Now I'm confused though, if concurrent DLLs are called in the same thread, could a control register stay set between them?

There are no "concurrent DLLs" because DLLs are not active entities, once loaded they are essentially nothing more than blocks of memory. When threads execute machine code in memory they don't care about where the memory came from. It's just memory.

The control registers are registers. Registers are properties of threads. None of it has absolutely nothing to do with DLLs. If you set a register it will stay like that in that particular thread (and that particular thread only) until another piece of code sets it to something else.

In order to "play nice" with code written by other people, it is considered "polite" to save and restore any "non-standard" state that you change during the execution of your code.

Seriously.. just make a RAII object that saves old state and sets new state in constructor and then restores the old-state as-is in destructor. Then as long as you only ever construct these in the stack you can't possibly screw it up.

[Tale]

What if in the middle of the iteration of the samples, the control pass to another thread (which is on the same cpu core) and start to process the ProcessDoubleReplacing of another plug B?

I don't think the OS can pass control to another thread on the same CPU core in the middle of your processing function. AFAIK a CPU core will execute your code continuously, until your processing function returns control to the OS (by actually returning, or perhaps by calling an OS function).

[hugoderwolf]

I don't think the OS can pass control to another thread on the same CPU core in the middle of your processing function. AFAIK a CPU core will execute your code continuously, until your processing function returns control to the OS (by actually returning, or perhaps by calling an OS function).

Sure it can, that's the "preemptive" in preemptive multitasking. What you describe is more or less cooperative multitasking.

Put an infinite loop in your process function and try it out. Audio will stop, but the rest of the computer won't. Even on a single-core machine.

[matt42]

I don't think the OS can pass control to another thread on the same CPU core in the middle of your processing function. AFAIK a CPU core will execute your code continuously, until your processing function returns control to the OS (by actually returning, or perhaps by calling an OS function).

Some pointless history; you're describing cooprative, or non preemptive, multitasking which was how things worked pre windows NT, maybe earlier? It's before my time in terms of windows programming anyway. And was the reason those early sytems had a hard time multitasking. Not all processes would play nice and share.

[stratum]

Some pointless history; you're describing cooprative, or non preemptive, multitasking which was how things worked pre windows NT, maybe earlier? It's before my time in terms of windows programming anyway. And was the reason those early sytems had a hard time multitasking. Not all processes would play nice and share.

Actually it's not even "pointless" history. Even back in the days of visual basic 6, which are not far away, the GUI was single threaded and that could be enforced. While in its day I did not use it, I still recommend that model to newbies. It keeps their silly questions away, in this way: "Ah, I do not know how that code crashed and what that stack trace shows, is your GUI multithreaded? It was not meant to be, and I do not want to hear about it."
Is it harsh? Well, maybe, but I even keep threads out of my own code and do not use them unless it is absolutely necessary. As this thread also exemplifies, somehow it is very hard to explain them to beginners and when used carelessly they can cause a lot of headache to everybody, regardless of how much experience they may have, 'stay away unless it is absolutely necessary to get involved in that mess'' is a timeless advice. I know there are simple ways that result clean code that is easy to debug, well, try explain them to a beginner and we'll see how much progress can be made:)

[Tale]

Sure it can, that's the "preemptive" in preemptive multitasking. What you describe is more or less cooperative multitasking.

Yeah, you are right, doh!

Put an infinite loop in your process function and try it out. Audio will stop, but the rest of the computer won't. Even on a single-core machine.

I'm running four for(;;) loops right now (on a Core2 Duo), and it is getting harder to do stuff. But it is still possible, so Windows must indeed be interrupting my for(;;) loops.

However, for (almost) all intents and purposes this doesn't matter, and you can assume your process function will always run its course before the OS decides to do something else again, because usually your process function won't notice any interruptions.

[JCJR]

It is probably improper terminology somehow, but hardware interrupts were the "functional equivalent" of multitasking on early small computer systems which didn't even have cooperative multitasking. IOW, the way to manage time based events and input/output "transparently interleaved" with a foreground single threaded process. I suppose that is true even today though I haven't kept up with details of interrupt handling of modern systems. Even with 8 or 16 cores I suppose interrupt handlers "jump in" on-top of threads whenever they want to do it unless maybe modern multi-core systems will reserve one core for interrupt handlers?

The same precautions had to be observed with interrupt handlers making sure to preserve register states and such when returning control to the foreground loop, to avoid crashing the foreground code. Though it was overall simpler back then. IOW, "How to write a sequencer on a commodore 64 or toaster mac."

[stratum]

The same precautions had to be observed with interrupt handlers making sure to preserve register states and such when returning control to the foreground loop, to avoid crashing the foreground code. Though it was overall simpler back then. IOW, "How to write a sequencer on a commodore 64 or toaster mac."

At least they were called 'hardware interrupts'. Anybody who worked with interrupts was aware of the fact that it is a very low level thing and anybody else wouldn't be able to set one and manage to execute a few lines of code without crashing the whole machine anyway.

[Smashed Transistors]

I've not looked in windows internals for a long while... so, i'm quite interested by the subject.

Is it possible, today, to ask the system for a certain amount of CPU before doing the job ?
"Hey, windows, i'll need 1500 cycles to process these 128 samples, do you agree ?"

[stratum]

Is it possible, today, to ask the system for a certain amount of CPU before doing the job ?
"Hey, windows, i'll need 1500 cycles to process these 128 samples, do you agree ?"

That looks like a feature for the so called "realtime operating systems".
I have never used one, but neither windows, nor linux nor mac os is a realtime OS.
That means such things are not guaranteed, but nevertheless in practice one can say that a particular thread has real time requirements, and the OS will interpret it in some way as best as it can, without giving any guarantee about timing.

[Smashed Transistors]

I used to work with this kind of OS in the last century/millennium.
That's strange that they did not implement such features on our multicore systems. That would make life much easier.

It would be so nice to have some hybrid system: say 2 CPU cores for a pre-emptive system and 2 CPU cores for the real-time oriented system.

Anyway, as we code plugins, let's say, that it is the hosts problem

[camsr]

General purpose consumer CPUs probably could be used for real-time processing, but not on Windows or Mac, maybe Linux, maybe. 64 samples of latency from the audio driver at 96khz is about .66ms of latency, single buffered. With the amount of data that has to be fetched from far RAM, lower latency is troublesome.