Using Double instead of Float increase noise?

[Smashed Transistors]

It was possible to be almost real time with early versions of Windows by using very low level nasty tricks. Some guy at Canam Computers did some tricky stuff to make "Quartz Audio Master" work low latency and multitrack before Steinberg introduced the ASIO drivers. Anyway even in the late 90s we had glitches when the soundcard fought the videocard :-/

Today, with my Akai EIEpro... the problem is still there. Most of the time everything is OK, but suddenly... glitch and sproutttchhh. Maybe it's driver needs some resource at the same time as another device... who knows ?...

Maybe things will evolve in the right direction thanks to hardcore video game players : they want speed and low latency for video and audio.

[mystran]

Today, with my Akai EIEpro... the problem is still there. Most of the time everything is OK, but suddenly... glitch and sproutttchhh. Maybe it's driver needs some resource at the same time as another device... who knows ?...

You might want to check what priority DWM is running at.. since it kinda likes to schedule itself at high real-time priorities (using MMCSS) and this can occasionally cause your audio threads to glitch even if the actual audio driver itself was fine.

It's definitely possible another device is causing issues (there is a couple of applications for checking DPC latencies) .. but it's also possible the actual problem is in user-space instead.

[stratum]

I always have that problem with ableton live (after a while), but the issue is known for me- when using two different audio interfaces for input and output it's sure that some glitch will happen sooner or later as each one has a slightly different clock. The only way to solve it is to use a single interface both for input and output.

[Smashed Transistors]

You might want to check what priority DWM is running at..
...

Thanks for the tip mystran, I'll try that !

[Nowhk]

Hi all! I bump this topic for a small observation...

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.

Maybe I've noticed this using IPlug this morning.

Within the ProcessDoubleReplacing, at the beginning of every sample iteration, I reset a modAmount double value. Than, in the middle, I calculate the amount for the current sample and later I'll apply it to the filter:

Code: Select all

void MainIPlug::ProcessDoubleReplacing(double **inputs, double **outputs, int nFrames) {
	modAmount = 0.0

	// some other task
	
	// recalculate modAmount for this iteration
	modAmount = CalculateModAmount();
	
	// filter by modAmound
}

If in the GUI thread I draw to the screen this modAmount, I can clearly see that "sometimes" the value (for very few ms) prints 0.0. So the amount increment/decrement gradually, but sometimes I can see 0.0/glitches on screen.

The only cause I think is possible is that it interrupts in the middle of ProcessDoubleReplacing and pass the control to the GUI thread, which get the actual value of modAmount and print it (since its in the middle, it get 0.0 instead of the last-edited value).

Or maybe its just because of "multicore" which process in parallel the GUI and Audio thread and I've barely make a mistake?

[Max M.]

The only cause I think is possible is that it interrupts in the middle of ProcessDoubleReplacing and pass the control to the GUI thread, which get the actual value of modAmount and print it (since its in the middle, it get 0.0 instead of the last-edited value).

Or maybe its just because of "multicore" which process in parallel the GUI and Audio thread and I've barely make a mistake?

Both (depending on whether OS puts processing and GUI threads into the same core or not).
In short, `modAmount = 0.0` at the start of the processing loop does not make any sense, why are you doing this?

[Nowhk]

Both (depending on whether OS puts processing and GUI threads into the same core or not).

I see So let say It switches in the middle of pdr: isn't a trouble for load/save control word states?

In short, `modAmount = 0.0` at the start of the processing loop does not make any sense, why are you doing this?

Basically, on every sample, I got many mod sources. This amount increments by diff mod amounts, so I first reset the amount, than I iterare various mod, thus I process the final value.

[Max M.]

... so I first reset the amount, than I iterare various mod, thus I process the final value.

Then reading this variable within GUI thread (w/o any kind of synchronization) does not make sense even more. Well, I guess you already realize this on your own, but hoped for some auto-sync magic (e.g. "function boundaries"?) that would choose/fix the proper value of that variable for you. No, there's no magic in multi-thread environments .

After all, regardless of the threading, the way you do it above is simply inefficient. For intermediate values use local/temporary variables and modify the shared/"global" variables only when necessary (e.g. for the code above it's when you get that "final" value).

[Chaotikmind]

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.

Actually there is a real time linux distro.
https://rt.wiki.kernel.org/index.php/Main_Page

[mystran]

If in the GUI thread I draw to the screen this modAmount, I can clearly see that "sometimes" the value (for very few ms) prints 0.0. So the amount increment/decrement gradually, but sometimes I can see 0.0/glitches on screen.

You need some kind of "synchronisation" for any inter-thread communication to work correctly. The minimum you can get away with is to declare a variable volatile (or use a memory fence) to force all access to go through memory. Otherwise the compiler is free to assume there is just one thread and keep everything in registers. On x86 (or x64) the actual memory is cache coherent across threads, so you don't really need a CPU-level fence, but you still need a compiler fence to make sure the stores/loads don't get optimised (or reordered in cases where ordering matters, even though that probably isn't the case here).

For feeding things like meters from audio to GUI, the easiest approach generally is to first calculate the new values for the processReplacing() block in the audio thread (in a value private to audio thread, so you never need to store incomplete values where GUI would read them) and then at the end of the processing block just copy the final values to shared memory (volatile, or do a memory fence after stores) from which the GUI can then read it.

[BertKoor]

You could init your var to NaN. Then the GUI can see that its value is not defined. But thread synchronisation can be done in much more elegant ways.

[Nowhk]

Yeah, I see there are better methods for sync
My "bump" was about context switch passing to other threads in the middle of the current PDR, and control word stastes.

But as mystran said in older post, there won't be any problem, since a thread (where control word are stored) won't switch to another PDR of the same thread "magically" (where I could effectively get some problem).

Thanks guys, as usual! You are really helping me everytime