XXHighEnd

I've got a tiny little bug, as you could call it, in my system.
I'm sadly still using a demo version under Win XP, but maybe someone else got the same problem. Here it is:
When I change the Player prio from standard normal to above normal, not only XXHighEnd.exe goes above the normal priority but (almost) all programs go above normal priority.
Was this intended? Is there any big mistake I'm missing?
I'm currently using 0.9t-o but I've got the same problem with 0.9sb-2.
Is it a bug anyhow? Or is this alright?
I'm greatful for any comment
Ava

Hi Ava,

I must honestly admit that for me myself the logic has gone since indeed PlayerPrio changes more than the player alone. That is, I have to set my mind to obtaining the logic explicitly (which is not a good thing). But what happens is this :

First, for conveniency, let's define "Player" as "Controlling section". That would be the graphical user interface you see on the screen, but it also controls what to play when, provides the Library functions etc.;

For Engine#1 and #2 counts that the sound coming from those are provided by "threads" (a technical means of providing processor capacity in a dedicated area, also implying virtual parallel processing next to other processes/threads).
Now, if you give low(er) piority to the Player, the threads producing the sound get cpu cycles more easlily.

For Engine#3 in fact the same counts, though technically (and for techies) it works differently, because Engine#3 runs in a separate main process. However, still the same is applied : the Player (controlling section) could be given less cpu cylces than the process that produces the sound.

In either case all is applied to the whole system : all processes/threads not producing the sound (like the "Player" = XXHighEnd.exe) would receive the low(er) priority, while the process/threads producing the sound receive a higher priority.

Of course above is so when PlayerPrio is set to (e.g.) Low and ThreadPrio is set to (e.g.) RealTime.

The most important is the ThreadPrio setting relative to the rest of the system (the latter set by PlayerPrio). So when ThreadPrio is higher than PlayerPrio, the process/threads procuding the sound get cpu cycles more easily.
Note that some (or at least with other players) perceive better sound when the sound producing threads receive a LOWER priority opposed to the rest of the system.


Concluded, what you see is by design, but your brain told you to set the (relative) priorities just the opposite of how it should be (my problem too).

Peter

Thank you very much for your help. And so quickly!!!
I think I understand it better now.
I will be testing it from now on, because I didin't gave so much time on tuning with the prios.

ps:Merry Christmas everyone!