Maybe I can help you with these few things :
First off, LatencyChecker is a kind of useless here, but, it depends on what you try to observe from it. For example, if the playback thread runs on such a high priority that the LatencyChecker reports a high latency, it is because of just that (the playback) and it is a good thing.
I could post many more examples, but they all need too much inside information, and you won't be able to interpret it properly otherwise.
Maybe it helps if I tell you I will never use it
during playback.
Also note that reports of people are known that the reported latency siginificantly drops at the moment playback starts. I can explain that, but with the only conclusion the LatencyChecker is useless for this.
If I move others down to 0, then my playback gets interrupted occasionally for 0,5 s
This shows how complex it actually is, but which you will observe as such only when you know what happens with those Q2/3/4/5.
Well, I guess it is sufficient for you to know that they
add. Thus, because of added "processes" your interruptions can get less. How come ? task switching, idle times, interrupts, keeping things alive, etc.
Notice that those Qs were never meant to play a role at this (interruption of sound) level, but once you don't have the interrupts, they internally still play the same role but now far more on the micro level. Thus, the level that bits stay bits but sound different because of, well, ... fill that in yourself. It just does.
Watch out now : it is *not* my intention that everybody with interrupts starts moving those Q sliders in order to get rid of it interrupts. You will get crazy ... So, in this case you first incurred for the interrupts deliberately (find that Special Mode) and next try to get rid of them via a backdoor solution. No. As I told in the other topic, this is a too tedious operation for us actually wanting to listen to music. So I will try to automate it.
Peter
