Multicore HW from Reaper's sense of view

[karbomusic]

Originally Posted by Dr Bob

Of course, but on which cpu that audio thread sits is what can cause disruptive audio behaviour if that cpu is also expected to do a lot more extra processing. From what I have seen, pushing the RT value gets you ultimately into crackle territory, so anything which can diminish the RT use has to be a good thing.

I'm not sure about that because anytime the RT core has issues, it appears to be because the audio processing really is the consumer. The only thing I can think of is if it was always on core zero which tends to handle lots of DPCs (but that means you'd get pops/clicks when it isn't maxed out) but I'm unware of anyone actually exploiting this to a performance advantage but who knows. I'd feel better with objective proof though.

I also have not tweaked my new Windows 10 system at all (yet!), and everything is ticking away very nicely.

dB

I see zero good reason to tweak anything until you have a symptom to resolve. My machine is zero tweaked, and isn't just a DAW and I have no issues with 100 tracks and 200 VSTs. I know I keep saying that but the comparison keeps coming up.

[Dr Bob]

The "proof" I see is that if I simply take any song and modify it to take the FX off the master track, I see the RT go down considerably, sometimes quite dramatically. I only have fairly simple master fx too - Eq, Tape sat, comp/limit - nothing fancy at all.

e.g SlickEQ, Ferric, Limiter No.6, or say 1973,Bombadier,L3.If the RT was simply reflecting the audio consumer, why the quite big difference between the two methods of using the master fx chain? It does seem clear that on the master track anticipative fx are not on - and maybe the fx are also confined to one cpu which is when they can compete wth the audio thread?

Maybe Justin knows more (well I'm sure he does) - we have seen a lot of speculation about this and it would be good to know more detail.

WIN10: I also have the view that if it ain't broke, don't fix it.

dB

[karbomusic]

Originally Posted by Dr Bob

The "proof" I see is that if I simply take any song and modify it to take the FX off the master track, I see the RT go down considerably, sometimes quite dramatically. I only have fairly simple master fx too - Eq, Tape sat, comp/limit - nothing fancy at all.

I misunderstood. I haven't run into that more CPU usage issue with FX on the master (just tested a week ago or so based on seeing it talked about here) so I have no way to 'reverse engineer' the behavior. I assume that maybe it's the master aka the thing that sends the audio to the SC and thusly processing also ends up or has to be on that thread, but don't quote me, I'm guessing based on an issue I don't seem to have for whatever reason.

WIN10: I also have the view that if it ain't broke, don't fix it.

dB

Excellent.

[Dr Bob]

With my new machine I have no problems - my old 7yr old quadcore was starting to choke on some songs - oodles of tracks and fx. Doing the "make a new master buss" thing helped quite a lot.

New machine is 8700K, 32Gb ram, ssd, 2* 2TB, liquid cooler, noise damped case etc - fab box indeed. Got it from CCL in Bradford. Can't praise them enough and really a good price (but expected it to be expensive!). Mind you, similar machines from other suppliers were about £400 more.

dB

[karbomusic]

Yea I get ^it, it's just that when I tested, I don't remember the CPU usage changing at all but it's possible my machine fast enough that the difference wasn't enough to be >1%. I'm sure it's real as enough people have talked about it, I just assumed I'd see 'some' difference but no biggie.

[vanhaze]

Originally Posted by Jack Winter

IMO it would be real nice if the master fx could also optionally be anticipative, as long as there are no recarmed tracks...

Agreed 100% !

[Jack Winter]

Originally Posted by Dr Bob

If the RT was simply reflecting the audio consumer, why the quite big difference between the two methods of using the master fx chain? It does seem clear that on the master track anticipative fx are not on - and maybe the fx are also confined to one cpu which is when they can compete wth the audio thread?

If you look at the signal flow of a track, each fx needs the output of the previous fx, so they can only be calculated sequentially, and not in parallel.

Say you have a project with 20 tracks, each of them with 4 FX on them. That can be processed on multiple cores, but if you had more than 20 cores, then some of them would idle, or the 20 tracks would be shuffled around among them which would lead to slightly higher cpu use but better load balancing.

On reaper this is pre-calculated before it needs to be played back (anticipative fx) and stored in a buffer. This is an efficient way of doing things, but leads to a delay in plugin metering and the time between changing a parameter and hearing the result. Still IMO a worthwhile tradeoff.

Now the master FX can't be calculated until all the other tracks have been calculated and summed. In reaper's case it's also not done before hand and stored in a buffer, it's done in realtime.

This leads to the concept of RT CPU, which is orthogonal to CPU use. What is quantifies is how long does it take to calculate the entire signal chain versus how much time is available (given by buffersize / samplerate). The higher the RT CPU is the closer you are to a dropout. The more plugins you add to the masterbus the longer it will take to calculate, and the higher the RT CPU will be.

Note that a CPU can be at less than 100% utilisation and still not be able to calculate everything in time, which would lead to the situation of having say 30% CPU and 100% RT CPU.

Now if you move the master processing to a normal track it can also be pre-calculated (anticipative fx) and all of a sudden you don't have the impact on the RT CPU measure and much less chance of an audio dropout. You get more delay in the metering and response time of the plugins though.

[Dr Bob]

Thanks Jack - succinctly put ...

dB

[Jack Winter]

An easy workaround is to put all tracks in a folder, and to add the master FX to the folder track.

[Cableaddict]

Originally Posted by Jack Winter

Now if you move the master processing to a normal track it can also be pre-calculated (anticipative fx) and all of a sudden you don't have the impact on the RT CPU measure and much less chance of an audio dropout. You get more delay in the metering and response time of the plugins though.

Jack,

Do you know this for a fact, Jack? Because it doesn't really make sense, intrinsically. Let's say you have compression on your master track. How can it compress your mix, before the mix gets there?


(Clearly, I don't understand how "anticipative fx" works, but I don't see how it can defeat the time-space continuum.)



If you are correct, then one could simply add a "pre output" track in front of the master, put all mastering FX on that, and then feed THAT to the master. (As Dr. Bob suggests, earlier.)

-------------------------

- But I also don't see how the RT audio thread can really be just the final 2-mix.
Wouldn't it have to be ALL audio streams leaving the audio interface, such as additional cue sends, etc?
Heck, doesn't it also have to be any audio coming IN to the interface?
And wouldn't it ALSO have to be any audio being summed, anywhere inside Reaper?

- This all happens in real time, unless you have delay compensation on. - But if you're going for the lowest true throughput, then you would NOT have delay compensation on.


I'm kinda' lost here.

[Cableaddict]

Originally Posted by karbomusic

Sounds like some are conflating this with the fact that the thread that talks the "audio driver" can only be one thread no matter how many cores/procs you have. There is no setting for that because it is a physical limitation.

True, but it does raise another interesting question:

Evidently reaper allocates all threads to all cores evenly. (And it does a great job of this.)

BUT WHY?

Why not give the RT audio thread it's own core? - Preferrably the last core on the cpu, since the first core typically takes care of a lot of Windows stuff, hence heavy DPC traffic.

And then let the rest of Reaper share all the other cores? (Again, except maybe for core 0.)

Given that it's common to see a maximum total cpu usage of only maybe 20%, this surely would not be a problem, and then the RT audio thread could probably really fly.

[karbomusic]

Originally Posted by Cableaddict

Why not give the RT audio thread it's own core?

It's probably more complicated than that. Pretty much everything, anyone ever wanted to know about thread scheduling in Windows can be found here...

http://www.i.u-tokyo.ac.jp/edu/train...Scheduling.pdf

[Cableaddict]

Originally Posted by karbomusic

It's probably more complicated than that. Pretty much everything, anyone ever wanted to know about thread scheduling in Windows can be found here...

http://www.i.u-tokyo.ac.jp/edu/train...Scheduling.pdf

OMG.

That's it, I'm going back to analog !

[G-Sun]

Originally Posted by Dr Bob

Moving ALL FX off the Reaper MASTER track makes a big improvement on the RT cpu.

Hm.. thanks for the find.
Should be an FR to make some pref-setting to get Master-track optimized

[Dr Bob]

Given we don't have all the facts to hand - and there are a lot of competing resources for that precious cpu time - all I can suggest is that you try the "pre master" track idea, and see if it helps.

As Jack says, a dead easy way for fairly simple song layouts is to put a folder around everything which normally feeds the Reaper master track, and then duplicate your master FX chain to the folder parent.

As a simple test, just leave your FX on the Reaper master and simply enable and disable them or the same FX on the "pre master" track or parent folder. A simple A/B toggle, and watch the RT cpu in the Performance Meter. If you get an improvement, all's well and good, if not, well, nothing really lost but a few minutes of your albeit precious time.

Cheers,

dB

[Cableaddict]

Originally Posted by Dr Bob

As a simple test, just leave your FX on the Reaper master and simply enable and disable them or the same FX on the "pre master" track or parent folder. A simple A/B toggle, and watch the RT cpu in the Performance Meter. If you get an improvement, all's well and good, if not, well, nothing really lost but a few minutes of your albeit precious time.

Cheers,

dB

True dat, but it begs the question:

Just because your RT thread size goes down, how do you know that's an overall improvement in your system? If you're not currently running into HW buffer size issues, or some other low-latency issue, perhaps doing this will just limits track count, or how many reverbs you can run, or whatever .....

[Jack Winter]

Originally Posted by Cableaddict

Do you know this for a fact, Jack? Because it doesn't really make sense, intrinsically. Let's say you have compression on your master track. How can it compress your mix, before the mix gets there?

What I wrote above is simplified and missing detail, but yes AFAIK that is how it works. It wouldn't have to compress the mix before it gets there, it would just precalculate everything instead of precalculating the tracks and calculating the master fx in "realtime". Again at the cost of plugin meters being early, and there being a delay between changing a fx paramater and hearing the change.

If you are correct, then one could simply add a "pre output" track in front of the master, put all mastering FX on that, and then feed THAT to the master. (As Dr. Bob suggests, earlier.)

Yes of course, using a folder track is just less work. Otherwise you have to route each track that would have gone to the master to the new track, and then disable the master send for all of them.

- But I also don't see how the RT audio thread can really be just the final 2-mix.
Wouldn't it have to be ALL audio streams leaving the audio interface, such as additional cue sends, etc?
Heck, doesn't it also have to be any audio coming IN to the interface?
And wouldn't it ALSO have to be any audio being summed, anywhere inside Reaper?

Of course what really needs to be processed in the RT audio thread is exactly the I/O, that is to say the incoming audio data needs to be copied to the application, and outgoing audio data needs to be copied to the soundcard's buffer to be played back at the next cycle.

But if a project has no rec armed tracks that need to be summed to the mix before being passed through the master FX, then there is no reason that you couldn't calculate the master FX too in advance..

[Jack Winter]

Originally Posted by Cableaddict

True dat, but it begs the question:

Just because your RT thread size goes down, how do you know that's an overall improvement in your system? If you're not currently running into HW buffer size issues, or some other low-latency issue, perhaps doing this will just limits track count, or how many reverbs you can run, or whatever .....

It's not about "RT thread size", it's basically about how long it takes to calculate the final output. There is a deadline imposed by buffer size / samplerate. At 64 samples buffer and 44k1, you have roughly 1.45ms to read the incoming audio from the soundcard, calculate the output to be be played at the next cycle, and then to copy that audio to the soundcard. If you can do that fast enough audio plays back without problem, if not you get drouputs and if you take far too long, you'll lose incoming data.

In the context of this thread, it's being said that if you move the master FX to a track in the project, that can (excluding in certain circumstances) be pre-calculated too, and just leave the copying of audio data in the RT thread, thus far less chance of a dropout. How much of a problem master FX presents, depends on what and how much master FX you use. Some calculate a buffer really fast, others take longer to do so. And if it takes to long, then..

[Cableaddict]

Originally Posted by Jack Winter

It's not about "RT thread size", it's basically about how long it takes to calculate the final output. There is a deadline imposed by buffer size / samplerate. At 64 samples buffer and 44k1, you have roughly 1.45ms to read the incoming audio from the soundcard, calculate the output to be be played at the next cycle, and then to copy that audio to the soundcard. If you can do that fast enough audio plays back without problem, if not you get drouputs and if you take far too long, you'll lose incoming data.

In the context of this thread, it's being said that if you move the master FX to a track in the project, that can (excluding in certain circumstances) be pre-calculated too, and just leave the copying of audio data in the RT thread, thus far less chance of a dropout. How much of a problem master FX presents, depends on what and how much master FX you use. Some calculate a buffer really fast, others take longer to do so. And if it takes to long, then..

Well, sure.

But how does that negate what I just posted, Jack?

[Cableaddict]

Originally Posted by Jack Winter

...But if a project has no rec armed tracks that need to be summed to the mix before being passed through the master FX, then there is no reason that you couldn't calculate the master FX too in advance..

Ah, yes. I wasn't thinking in those terms. (thanks.)

Of course, in this scenario (just mixing) there's also no need for low latency. One can up the buffer, and turn on delay compensation, and it doesn't matter. So...



- Which reminds me to complain once again to the Reaper gods about not having a way to GLOBALLY turn off all delay compensation! (But they've been ignoring me for ten years now, so I won't hold my breath.)

[Jack Winter]

Originally Posted by Cableaddict

Ah, yes. I wasn't thinking in those terms. (thanks.)

Of course, in this scenario (just mixing) there's also no need for low latency. One can up the buffer, and turn on delay compensation, and it doesn't matter. So...



- Which reminds me to complain once again to the Reaper gods about not having a way to GLOBALLY turn off all delay compensation! (But they've been ignoring me for ten years now, so I won't hold my breath.)

If you live process FX then this discussion is completely unrelated. It's essentially about using a lot of extra latency (a buffer) to make sure that there are no dropouts due to the processing taking more time than the deadline allows.

[Cableaddict]

Regarding the suggestions here about plugins on the master track:
Maybe some of this works for some of you, BUT NOT FOR ME.

My simple test:
-----------------------

I created a"Pre Master" track, just in front of my master track.

I routed all my audio to THIS track, then had this track feed into my master track.

I put all four of my "standard" mastering plugins on both tracks, so I could disable each set separately to test the information on this thread.

I created a dense audio / midi loop, with lots of tracks in record-monitor, but also lots of track just playing back audio. Then I watched Reaper's performance meter.
----------------------

RESULTS:

1: Whether those mastering plugins were on the master track itself, or my new "re master" track, the numbers in my performance meter DID NOT CHANGE AT ALL. (Nor did the very slight crackling I get with this test session.)

2: On the "pre master" track, if I then added another cpu-hungry plugin, I instantly saw a large increase in the size of my RT thread.

So obviously, I was correct that the T thread includes all summing within a session.

And, at least for my setup, there is no point in moving plugins off of the mastering buss.



What can I tell you? YMMV, I guess.

[Cableaddict]

But then it gets stranger:


So now I figured I was right about how the RT thread must include all outputs and summing busses.
But does it?


In that same test setup, above, I have three stereo outputs going to cue system feeds. They were open during the above test.

Since these outputs get fed from an internal subgroup, not from the master track, they must be separate summing processes. So, it was reasonable to assume that if I muted these tracks, my RT audio thread would get smaller.

Except it didn't.




I'm really, REALLY confused.......

[Dr Bob]

Confusion and speculation does seem to be the case with the RT thread issues etc ...

I wonder if a dev could pop into this thread and let us know if we are being sensible or downright stupid about moving stuff around?

The improvements I see are only at mixing stage, no rec-armed tracks etc. Just plain and simple mixing - either of stems or tracks with midi feeding VSTi's.

So, really simple use cases - which might well be the case for a majority of users.

Devs????

Cheers,

dB

[Dstruct]

Originally Posted by Jack Winter

IMO it would be real nice if the master fx could also optionally be anticipative, as long as there are no recarmed tracks...

Agreed.

[serr]

Or the vestigial "Master" track could be removed altogether since it makes little sense to have a unique and somewhat restricted hardware send track when we now have universal tracks in Reaper that can be routed as you please?

If you come from hardware mixing boards, it's intuitive to just use the "Master" for one of your stereo hardware sends (and nothing more). I can easily see how someone without that history of experience would think to start inserting plugins there though just because you can. That's the thing though, now Reaper gets to support the fallout now that the feature is there.

Anyway, just to throw in more confusion:
I had a project with a few instances of iZotope RX broadband NR and some wild routing (source audio track to multiple parallel processing tracks and then summed back together.

Aside: These iZotope plugins have bugs. Not showstoppers, just annoying. For example, you need to open the GUI for all broadband NR plugins inserted on any tracks before hitting play for any instances you have the audio quality choice set to level 4. Possibly the scenario of reporting an incorrect value to PDC? Who knows. Buggy!

So using buggy plugins, that are maybe also slightly resource hungry, and a handful of them. I had a scenario where if I muted one of the parallel buses, the project would 'crash' and act CPU starved with dropouts. (Note: Muted tracks are set to be processed. This isn't the case of using them as on/off buttons with a PDC recalculation.) Just to restate that, the crash happens when muting a bus, not unmuting it! (And the classic telltale of the buggy plugin: Nowhere near maxing CPU use.)


The point being that I've seen odd PDC related behavior too that is related to more complex routing. Insert a buggy plugin that reports PDC incorrectly and you can really have a lot of fun times on the mixing board with it and see all sorts of things!

[studer58]

Originally Posted by serr

I also disagree with the conventional wisdom of setting a single core for audio processing in Reaper. (I've always seen it mentioned to use 1 core, not 2 or 4 FWIW.)

Reaper absolutely wants two things: Control over how it determines multi core use and full access to your CPU. Turn hyperthreading off in your EFI firmware. In Reaper preferences, set the number of cores for audio processing to the number of physical CPU cores you have.

Is that the setting in Buffering preferences:"Auto detect the number of needed audio processing threads" (have sent you a PM query about this also ) ?

[Cableaddict]

### So what are we supposed to do with VSTi's that have their own multiple core settings?

Kontakt, for instance. It defaults to "allow multi processor support." Should this theoretically be turned off, so Reaper can control things?

------------

And what about other audio apps, not within Reaper but running concurrently?

For instance, Traktor. - Which I always have running in the background during live performance, & which also has its own cores setting.

With Traktor, I've tried both ways, using my "on the edge" Reaper session, and I don't really see any difference. - Though I'm also not doing a lot with Traktor. I'm just playing files, no recording, no resampling or whatever.

[seymour22]

Originally Posted by Cableaddict

I must bump this thread, to correct a SERIOUS error:

Yes, the little prompt at the bottom of Reaper's buffer settings window DOES say this, but it's wrong, wrong WRONG.

(Did I mention that it's wrong?)

That's my story, and I'm sticking with it.

Wow! Thanks a lot! Frankly, I took for granted it should be 4 as max (so, no more attempts on my side). I will practice it shortly!

Thanks again!
Kr
Tomek

[seymour22]

Originally Posted by Dr Bob

Just to add to the RT cpu use part of this thread ...

As I and others have pointed out in various threads ...

Moving ALL FX off the Reaper MASTER track makes a big improvement on the RT cpu.
dB

Hi Bob,
do you mean when I use some FX(s) on Reaper Master track (like bus compressor, etc.)?

kr!
Tomek

[seymour22]

Originally Posted by Jack Winter

An easy workaround is to put all tracks in a folder, and to add the master FX to the folder track.

While reading this thread I was thinking aroud exactly the same. Actually in Reaper there is same difference: folders or bus tracks (from my experience). Of course there is no 'bus' at all, just a new track

kr!
Tomek

[Dr Bob]

Yes, just group the output of all your tracks which normally go to the Reaper master by default. Easy for simple projects is group all those tracks in a folder, as Jack says. Or, just make a new track (Track 1)!!! Then route everything there, making sure you disable their master sends. Stick your master fx chain on the new track.

As I have said in this thread, this works well for me when using a MIXING ONLY scenario. No record enabled tracks, or send to hardware and back ... just plain and simple mixing of stems OR stems + midi tracks.

If you are struggling a bit with RT cpu consumption, could be worth a try. Nothing lost if it doesn't work for you.

dB

[Dr Bob]

Originally Posted by Cableaddict

### So what are we supposed to do with VSTi's that have their own multiple core settings?

Kontakt, for instance. It defaults to "allow multi processor support." Should this theoretically be turned off, so Reaper can control things?

Good point this ... maybe a dev can help here please?

Schwa,Justin?? Where do we stand with this? Do we have competing systems trying to optimize core usage? Who wins????

Cheers,

dB

[Cableaddict]

Originally Posted by seymour22

Wow! Thanks a lot! Frankly, I took for granted it should be 4 as max (so, no more attempts on my side). I will practice it shortly!

Thanks again!
Kr
Tomek

Bear in mind that, of course, I'm only reporting on my own rig & Main (live performance) Reaper setup

YMMV.

Definitely let us know what you find.

[Xenakios]

Originally Posted by Cableaddict

### So what are we supposed to do with VSTi's that have their own multiple core settings?
Kontakt, for instance. It defaults to "allow multi processor support." Should this theoretically be turned off, so Reaper can control things?

If you turn the multithreading off in the plugin, that's how it's going to be, the host can't magically redistribute the load for a single plugin instance. (The plugin APIs like VST have nothing to deal with things like that.)

[seymour22]

Originally Posted by Xenakios

If you turn the multithreading off in the plugin, that's how it's going to be, the host can't magically redistribute the load for a single plugin instance. (The plugin APIs like VST have nothing to deal with things like that.)

Hi,
I am not sure if got it well... For instance, from Kontakt guide/forums I looked up I should turn multiprocessing in VSTs off, however they say - test it yourself in your env. Below I quote little bit so you can see that for stand alone NI implemented multiprocessing as switched on by default, for plugins opposite.

From Kontakt guide:
>>Multiprocessor Support: KONTAKT can make use of multiple CPUs or dual-core processors. To switch multi-processor support on and off and to set the number of processors / cores you want to use for KONTAKT, select the corresponding entry from the Multiprocessor support menu. Multi-processor settings are saved independently for a) the stand-alone and b) all plug-in versions. On multi-processor or multi-core systems, many factors influence the system’s behavior. When running KONTAKT as a plug-in, multi-processor mode can sometimes cause crackles and drop-outs. Whether or not these noises occur during playback strongly depends on your individual software and hardware setup. Therefore, the only option is to test which multi-processor setting works best for you when using the KONTAKT plug-in. Note that multi-processor support is disabled for the KONTAKT plug-in per default (off entry in the Multiprocessor Support menu). <<

Kr!
Tomek

[acousticglue]

Karbo: what is your motherboard, CPU RAM speed, bus speed, sound card used and buffer settings? What plugins do you use the most of?

Funny how its always audio/video guys who have to push the frontiers.

My older thread of interrupts doesnt come from not knowing Windows or settings etc. What it comes down to is some humans cannot even hear some very low audible crackling in the audio if it were to occur. I almost always have noticed this more in Amplitube 4 on any system I ran it on. 3 version or 4. Tried VST3 or 2. Sometimes buffer handling of mixing plugins and the seriousness of using a shimmer reverb algo vs plate can do this. Leaving network card on or off sometimes matters due to MS call home or wants to call home. Pace/iLok wants to check in. Programs with check for updates on. BiasFX checks to see if logged on to cloud to be able to play your FX you have rights to. All these things matter when using real time cleaner sounds that make things audible.

I have turned off all apps I dont use. Turned off services in Home 10 Windows that are not relevant. Tweaked sharing to not be on. No print spooler. Yet with so many plugins that may not play well together when building a pedal board and cabs such as 3rd party reverbs or Torpedo WOS cabs. I find adjusting cabs in and out at some time length of doing so introduces the very low artifacts.

[acousticglue]

and to add I changed everything to 88.2/256 on Focusrite saffire and little difference on guitar sounds if any to me but no comparison done recording using many different plugins but Pitchproof only plugin didn't work. Latency same but no crackling so far.

[seymour22]

Originally Posted by Cableaddict

Bear in mind that, of course, I'm only reporting on my own rig & Main (live performance) Reaper setup

YMMV.

Definitely let us know what you find.

Ok, I spent around 30 min. to figure out best settings I can find to optimise the multicore speed. Best I found (on mac 4 physical cores 3,7Ghz, displayed as 8, 4 as boost):

1). Audio reading/processing threads (on auto - Reaper discovered 8 cores and this is best).
2). Allow live FX multiprocessing on: 4 cores. I tried 8 cores (but it was worse).
3). In Kontakt as Reaper plugin I switched off multiprocessing (this approach is best).

To test I was playing some Kontakt piano. When buffer set as 32 it was some clicks. No problems when set as 64 and the latency was still acceptable.

So is in my environment.


kr!
Tomek

[vanhaze]

Many thx for this info !

What are your test settings regarding "Thread priority" and "Behaviour" ?

I am on mac also:

Macbook Retina 2015
OSX 10.13.2.

I have a Dell Monitor attached to it (via minidisplay), at a moderate scaling modus.
I experience tiny dropouts in not that big projects but with some rather heavy plugins (also some UAD's).
The dropouts always occur when my macbook fans are spinnin' quite fast so i suspect the macbook throttles cpu (and gpu ?) down to avoid overheating, thus, creating the micro dropouts.