0.9z-7-4: My most annoying problems #3 - ClockRes not honored

[charliemb]

[I said of "at least 2"]

If I do anything that consumes memory outside of xx, from then on, I get a message that 15ms is requested but that only 1ms will be honored (paraphrasing).

What do I have to do to always get 15ms?

[Sometimes I get this message after a while, even without running anything that consumes memory outside of xx.]

[PeterSt]

First of all this is an OS thing. Second this is about other programs "hogging" the Clock resolution State. In fact what XXHighEnd does (when lower than 15) and where other programs would complain. The program with the lowest number (highest resolution) is the boss.

You shouldn't be running anything else together with audio playback. Well, not with serious playback that is.
But I'm sure you knew that.

Hope this all gets you on some track somewhat. But please feel free to disagree with everything. But what I said in the other topic - approach all by the elements and you will see that nothing is wrong with them, OR you will be able to see where improvment is needed (to be performed by me I mean). Now you have one big pile of nothing working (as posed), and this simply is not true. Okay, IMHO.

Peter

[benananda]

I had the same problem with Windows 7 enterprise 64bit.  Anything over 1ms didn't work.  I think Peter suggested using MinOS as an attempt to override the OS, but I never got that far.  Now using Windows 8 pro 64 with a full 15ms. :-D  It sounds a touch more relaxed to my ears.  I'd say it's not a deal-breaker of a difference, but I like it, and I certainly like having the option!  Windows 8 is turning out to be a real gem, if you can handle disabling metro (turning off UAC in registry disables all Metro apps. lol)

[charliemb]

First of all this is an OS thing. Second this is about other programs "hogging" the Clock resolution State. In fact what XXHighEnd does (when lower than 15) and where other programs would complain. The program with the lowest number (highest resolution) is the boss.

You shouldn't be running anything else together with audio playback. Well, not with serious playback that is.
But I'm sure you knew that.

Yes, I know that;  I try to avoid doing anything other than music playback.   But even if I want to copy newly ripped CDs to the drive, this problem props up.   I'm leaving the message because I want to know when to reboot.

BTW, sometimes xxHE gets to this state all by itself.  Well, at least I don't do anything other than run xxHE and I'm using Minimize OS.   And it happens.

Hope this all gets you on some track somewhat. But please feel free to disagree with everything. But what I said in the other topic - approach all by the elements and you will see that nothing is wrong with them, OR you will be able to see where improvment is needed (to be performed by me I mean). Now you have one big pile of nothing working (as posed), and this simply is not true. Okay, IMHO.

Peter

Not a big pile of nothing, obviously.  xxHE provides the best sound.  In attended mode, it partly works.  But it is just annoying.  Some nights its acceptable.  Some nights it feels like a pile of nothing in attended mode with mixed resolutions and long mixed lists.

[PeterSt]

In brief and after reading your responses in the two other topics : agreed.

No idea about your Clock Resolution issue, sadly. The only thing that I can recognize as sometimes happening is the ClockRes changing to less than 15 when Hires is in order. I really have no clue when exactly this happens as it is not always the case. But as I said, it is an OS thing. Ever back, when I tried to tweak things in the area (this is about Multi Media scheduling / priorities) I could find no consistentency at all. IOW, in my view something is wrong in there (OS) in the first place. Also, from Vista to W7 this changed and NOT for the better.
Possibly it is inconsistent because we apply it to Kernel Streaming while it's really made for WASAPI (this Multi Media Scheduling). This is how engaging Engine#3 *always* will drop to 10ms (this is really unavoidable by me).

If XXHE does it (by) herself as you say, think about XXEngine3.exe really doing this. So, kill that, and it should be back to normal again (until it's triggered for the same reasons (??) again).

What is and remains important for you is the understanding of the program implying the lowest number being the boss. So, when e.g. you fireup Latencty Checker, that will set the ClockRes to 1ms; as long as that runs, nothing can get it back to 15ms. But kill it, and all is back to whatever is boss next. Was that XXHighEnd playing through WASAPI (Engine#3) and XXEngine3.exe is still in memory, then that boss determines 10ms. Until you kill that program.

Generally, any program with recording capabilities implies 1ms. This is not done by the program but by the OS, because it is "known" (by Bill Gates et al) that 1ms is needed for glitchless recording.

Hope it helps ...
Peter