RAMDisk

[Telstar]

Very shortly, xxhe from ramdisk and in Vista sounds the best.
Thanks to Marcin that got the idea and everyone who worked on it, particularly Peter, who has been a wonderful host for the second time.
All the frickin hours of travelling were worth. 

[PeterSt]

Can somebody run this test on Vista and let us know if Vista does indeed make less context switches? (I used W7)

Vista from RAMDisk :

SFS = 70. 4450 Context Switches for 45 seconds of a larger track, that 45 seconds not fitting into memory. But also less threads than your picture (notice the lack of 44c3 lines).

Next : track fits into memory, but notice that I realized this with increasing the SFS, but also by means of playing native 16/44.1 now (which before was 32/352.8 ).
1280 context switches. Further picture looks the same.
It may say nothing, but Dynamic Priority is 11 now. Before it was 10.

Next : Same as above, but 32/352.8 again. Switches : 4000. Needed one trackpart load.

Next : Back to SFS = 70, now XX started from the OS disk. Switches : 4300.

Next : Start XX from normal HDD (OS elsewhere), further the same as before. Switches 4700.


Tried a few things more, and it is the conclusion that nothing matters for the number of context switches, except the sample rate; It is my estimate that since buffer sizes were kept the same always, this is just a matter of buffers being full 16 times more early (16/44.1 vs. 32/352.8 ), and this hands things over to the driver 16 times more often.
Further noticed variations will be because of not starting the stopwatch at the same time always; this varied 3-5 seconds easily.

In all cases the (number of) threads were the same, and nothing looked unexpected to me (which I can't say from your W7 graphs, Josef).

Peter

[PeterSt]

AHUM.

Josef, I am so so sorry -not only for your efforts, but also for the idea to have found something-, but this is your Q2/3/4/5 settings ...
You just forgot to set them in your RAMDisk setup.

Btw, with whatever other "install" I do myself, I *always* forget to set the Q settings (only Q1 in my case), so I will try to do something about it. You just don't see them automatically, you know ...

So, I know how difficult it is not to see ghosts, but I'm afraid this was one of them. These are the worker threads for those Q settings (and yes, they really do something ... now you know hehe).
Case closed I suppose.

Again, so sorry. Peter
(but keep 'm coming !!)

[PeterSt]

Could it be that its all down to the SATA cable? Presumably, running XX from RAM would eliminate any ill effects that the SATA cable and HDD/SDD might be introducing.

It's a hypothesis (a far-fetched one, I know), that's all.

Now, on to this one;

I read that one too, but I always laughed louder on the "you have to burn in your downloads" soap. But ok, I kind of learned to not think about anything like a soap, because then we wouldn't be where we are today. So, can be, can be (the cable thing). But I see no electrical explanation in it. So, can not be.
For now.

However, there might well be other things going on, which are in a kind of same direction. So, first remember that this never is about the I/O's which are not there in the first place, once your SFS is large enough. But for example, look at the Resource Monitor how long it takes to let die out *other* processes, which emerge just because of that I/O once in a while. There are dozens of processes in the beginning (after reading a file (part)), and only with some luck they all have died out before the next I/O. So, the I/O has implications. Whether those implications are "audible" by itself I can't tell.
But now with the RAMDisk;

I can imagine that with the RAMDisk our necessary "I/O's" are not I/O's as such anymore, and thus those processes won't fire either (I didn't check it). Also, it may not be about the amount of those processes, but merely about a single nasty one implies. Avoid that nasty one, and the whole problem may be gone.

So, for now I'll leave it to this, but there sure is logic in eliminating that disk, be it a spinning one or an SSD, and many things becoming different because of it.

Haha, nice actually; suddenly there is no doubt in anyone's mind that *everything* matters. Now it's merely about "but what the heck is doing it". And this is only because suddenly things are *wrong* after a virtual improvement. Would it have been the other way around, not much thoughts would have been spent on it.

Now, who is able to boot the PC from a network card like the good old days from Novell could do it; The network card just took care of that job, at reading the OS image from a network drive, and next boot from its own internal memory. Or actually the ROM on the card;
If you look at a network interface card from today, the place for the ROM is still there, but the chip itself (3-4cm or so long) has been left off.

Oh well, Playtime I guess. Just music I mean.

No, one other thing which just slips my mind;
We also know about the "monitor falling asleep" and that being audible. Not that I heard that much myself, but this may be because I give it 45 minutes before falling asleep. Anyway, the other day, at observing my new system's problems, and looking at the clock speed of the processor and the SFS thing, my monitor fell asleep (after 15 minutes this time), and right after that there was no way my clock speed would ever change (the monitor awake again). So, the monitor not being "addressed" is BS, but the implications of it falling asleep are not. You see ?
And don't tell me we never heard about in fact huge problems with energy management, when it comes down to SQ ...

Peter


PS:
... which also may be related to a Disk falling asleep (which an SSD can do too I think). IOW, what happens if the thing has to go to sleep (watching watching watching) or whatever changes once it actually falls alseep (the monitor thing) or even when it wakes up again. Not so with a RAMDisk ...

[Josef]

>These are the worker threads for those Q settings (and yes, they really do something ... now you know hehe).

LOL, you're right about settings: luckily I did not close RAMdisk so was able to verify that all Q settings were 0 whereas, for whatever reason, disk-version had Q2=30. So, Q2=30 means XX creates extra 30 threads? Ouch. And indeed, after setting Q2=0 OS-XX behaves the same as RAM-XX!

But this exercise was not all for naught: it is very interesting that XX does _far_ less  #context-switches than Foobar and, even more interesting, that Vista has a LOT less than W7! (yours ~1300 vs mine ~5500!).

Now that Vista number just seemed waaaay too much to me (even taking into account I use a laptop where you have a dedicated PC) so I tried playing with Q1: Whereas Q2 always increased #context-switches Q1 _reduced_ them, and did _not_ create any extra threads!
Test track went from ~5500 with Q1=0 to ~1900 with Q1=11!

At least to me, this looks like Q1 is a really powerful tool as it seems to only influence the size of internal sound card buffer or somesuch without messing around too much, and produces something measurable which can be compared to other players - in process providing at least a hint why bit-perfection does not necessarily equate quality music playback (more switching = more jitter?)

On the other hand, Q2 though seems like a hack (sorry ) and if one has to use it then it most likely indicates a problem somewhere else down the line in equipment chain?

(note that Q3/4/5 at 0 or 30 had no effect at all on #threads/context-switches so it's unclear what they do)

[PeterSt]

Nice ... 

But FYI: Those threads balance out things in a way it was empirically defined by users' comments about SQ and what they did to incur for it. Never mind how exactly (please), and you may call it a hack.

About your further Q1 findings ... yes that will be correct. That is, assuming (and what I suggested) that it's the driver's turn to come into play when the buffer is full.

I have been looking somewhat further too (because this is all just a new angle anyway), but I think we have to look at it the other way around :
Not what XX is doing, but what it may imply. So, look at all the other processes and what they "consume". Not for processor capacity, but for that task switching (as how I call it, but "context switching" may be the official term). So, the more another task requires a time slice, the more XXEngine3 will be "swapped out". And thus : the less of those others, the more it will continue. And well, I found sufficiently enough processes with 100ds of thousands of switches (the PC being up for some 14-15 hours). But it's a hell of a job, and next you don't know much what to do with it anyway. So I started killing processes of which I knew they wouldn't harm, but after half an hour I had enough of it. Anyways ...

If the switching of Engine3 in W7 doesn't show significantly more compared to Vista, it is just not that. It may not even improve on sound ... I don't know (also don't forget : if you use Q2 etc., you now know what it does ... CREATE that stuff ... and you feel it's better. So ...).

And thus it may be a dead end. But still I feel it's something like that. Also : once a task (XX) is swapped out, *how long* does that take ? This theoretically is again a matter of priorities, and there things s*ck too.

At the moment I don't know.
Great thanks,
Peter

[Marcin_gps]

So Peter, would you say that XXHE is a multi-threaded app? I'm asking because I may have another small tweak from a hardware side. My memories could work in two dual channel modes - ganged and unganged. Ganged means you will have a large 128bit pipe and unganged means you will have a 2 x 64bit pipes. Unganged mode is supposed to help multi-threaded applications. I wonder if there would be any difference for XXHE?

[Josef]

Forgot to mention: One more place where it's interesting to observe #switching is WASAPI vs KS:

KS: Q1=0 ~5500 WASAPI: ~28000 (!)
KS: Q1=11 ~1900 WASAPI: ~3800
(both used Adaptive mode with 1024 buffer size)

So I guess this proves that there are indeed big internal differences in buffer sizes between KS & WASAPI which should help explain SQ differences...

[PeterSt]

Haha, I was waiting for this. But both are uncompareable. But let's say that the 28000 from Q1=0/WASAPI explains the more "detailed" sound, which actually is "stressed" (listen to violins).

In either case it has nothing to do with the Device Buffer Size in XXHighEnd. And, to really compare you must put the *real* device buffer size in the equation. Something like KS/Special Mode with a sound card buffer size of 48 and Q1 to 1. The monitor will not be able to keep up with the number of switches (I expect).

Now, be a man, and explain why this is all still bit perfect eh ?
hahaha.
Then I know it too.


Peter

[PeterSt]

So Peter, would you say that XXHE is a multi-threaded app? I'm asking because I may have another small tweak from a hardware side. My memories could work in two dual channel modes - ganged and unganged. Ganged means you will have a large 128bit pipe and unganged means you will have a 2 x 64bit pipes. Unganged mode is supposed to help multi-threaded applications. I wonder if there would be any difference for XXHE?

Marcin - Thanks. And yes, as multi threaded as can be. But :

Maybe better first try to (really !) proove to yourself what is working how for the better. Find that *real* thread on that *real* forum that *really* can explain it unambigiously. My bet : you can't. Nobody knows exactly. Not even your processor manufacturer.

It would be more "economical" to find how the Registry can be tweaked so drivers can get Affinity. I know it can, but I never really looked for it. But today it suddenly seems important to me.

Anyway, multithreaded yes ... the result ? no clue. Try it ?
You are most often right anyway, so ...

[Josef]

>Something like KS/Special Mode with a sound card buffer size of 48 and Q1 to 1. The monitor will not be able to keep up with the number of switches (I expect).

~46,000

[PeterSt]

Haha. But I forgot : not only the real soundcard's buffer size needs to be set to that, also XX's "Device Buffer Size". *And* Q1= ... to any value your system can bear (the label above Q1 shows the samples). So, this will be sub-48 sample buffer. But 46000 ? that's 1022 per second. Seems too low to me. At no upsampling it merely must be in the range of 44100 per second.

All just for fun and your understanding. I wouldn't bother too much !

[Josef]

Ah - I have set XX Buffer to 48 (Q1=1 then shows but sound card driver (Transit) cannot go lower than 128 bytes - and if I try another DAC via Windows built-in USB driver then I have no clue where to set buffer size....
I guess that is that then....

[Raj.V]

Hi all,

I better mention this while Ramdisk is the flavour of the week...

I looked up on Ramdisk benchmak and picked one of the top three (not free but has trial period). The read/write rates are higher than the free one suggested earlier by Marcin.

Result:
I thought I couldn't improve my laptop it anymore... but I was wrong.
Even blacker and more separation between the instuments and vocals. Cearly better for me.

I guess it follows the law of nature... If you want something free and good then get Fo*b*r and if you want something more rewarding then buy XXHE.

Please try it and don't forget to share findings... and explain if you know why... I thought ram is just ram.
Just create ramdisk with different SW, have separate XXHE installed and run it to compare.

Should also be able to check Ramdisk performance using HDTune. Just compared my HDD with the Dataram ramdisk and almost fell off the chair.

Raj

[Marcin_gps]

I was afraid that different ramdisk software would matter as well    Does your choice have ability to run from an image at Windows startup? What filesystem did you apply?

Cheers,
Marcin