Hey guys - anybody spent some time listening to different RAMdisks?

I mean, this whole thing really makes no sense at all: as XX is pre-loading files into RAM before playing it should not matter, right?....ugh, then it should also not matter if HD/SDD is used......yet, it seems everyone here is noting a difference and mostly positive ones to boot ....gosh....

But, if we assume that RAMdisk makes a difference (even though it should not), could it be that different RAMdisks sound different too? (even though it should not matter at all?)

Indeed, Raj suggested that this was the case and, specifically, he found GiliSoft preferable to Dataram. Was anybody else here brave enough to venture into this highly improbable realm?.....No?

Well, why playing with benchmarks I also played same tracks from different RAMdisks and, as much as I hate to admit, it would seem that Raj could be onto something...

Contrary to Raj, though, I just can't stand Gilisoft....in short, found it too 'mechanical'....
On the other hand, Dataram was good but maybe just a bit 'thinnner' than QRam which I preferred in the end......

OK, I know this sounds weird (to say the least, LOL) but then I looked a bit under-the-covers and it seems RAMDisks go about their memory allocation differently: it seems that both Dataram & Gili rely on 'local device driver' memory (which is a bit of a no-no per MS recommendations when it comes to such large allocations, btw) whereas QSoft defaults to Kernel non-paged pool (although it can be configured to behave in similar manner or use Kernel Paged-pool instead...)

Now, in theory, this _could_ make a difference if one has a swap file.... I don't, so I'm stumped...

Anybody tried this? (or care to explain why this is all a placebo, please?...

That RAMDisk benchmark someone posted here was run on a very old hardware so I've re-run it with best 3 on not-so-old hw (CoreDuo 2.2Ghz).

Top row NTFS, bottom FAT16.
From left to right: QRam Enterprise, GillSoft, DataRAM.

Not much difference between 3 packages except it seems that:

1. DataRAM consistently slower. (but also significantly lower DPC latency on 4K test!)
2. NTFS consistently slower.

So, going with FAT seems a no-brainer. Not only is it faster but it leaves more usable memory (notice NTFS ate 22MB on disk with no data).
Other than that, choosing one is a personal preference.
I've picked QRam as it has a ton of options on which part of RAM to use (might come in handy one day) and is cheaper than Gill (or free if you re-install once a quarter or so)...

Not sure if it's related but there have been, in fact, many problems reported with Intel i3/5/7 processors related to incompatibility between new intel chipsets with certain USB 1.1 equipment used by DJs - some people ended up going back to Core Duo and others bought newer models of equipment (presumably USB 2-based).
You can read the whole thread here (is very long): http://www.serato.com/forum/discussion/258955

Curiously, nobody seems to have verified a fix posted by user ashare80 near the end of that thread - Here it is copied verbatim if you are lazy to read the whole thing

I've used both an sl-1 and a ttm57 for a week now on my i7 windows 7 laptop with no problems by turning off "speedstep" and "usb emulation" in the bios under "advanced" as well as turning off the "allow the computer to turn off this device to save power" in the device manager under the "power management" tab of each usb root hub properties.

*Note*
Make sure you also change the "power plan" settings to reflect the changes in the device manager. To do this click the battery then More power options->Change plan settings->Change advanced power settings->USB settings->USB selective suspend settings->Disabled

I've realized by simply un-checking this option in the device manager does not keep the settings after rebooting because the "power plan" settings must be changed to keep it from reverting back when it loads.

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....

>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

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...

>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)

>That would explain why Mani experienced better SQ running XXHE from a 2nd SSD, compared to running on only one SSD, wouldn't it?

Yep, sure seems that way
Still, I speculate that RAM disk is probably always a better option as everything is contained within MB i.e. less internal/external hardware gets powered up/down around and more stable power is always preferable for audio....

Fun part is that implications of using #context-switches as measure may go far beyond: For example, what if it can be used to explain (at least to a degree) why different players sound different even though they are all bit-perfect?
And why, e.g. Foobar set to pre-buffer music into RAM before playing and also using KS or WASAPI still sounds worse (eh, different than XX?

So, for fun I tried same experiment with Foobar. One thing immediately becomes painfully obvious: Foobar is context-switching like crazy all the time - even when not playing at all Interestingly, this does not seem to change during playback very much and is very similar to what XX does when run from OS disk. However, #threads is drastically better (=smaller) with Foobar and does not seem to be affected with where Foobar was started from...
So, there seems to be some code in XX which, for whatever reason, is highly susceptible to where XX is run from.....

Hmmm - I think I've found a method which clearly demonstrates that XX indeed behaves _very_ differently when run from RAM disk!

Experiment is simple: make a playlist with 1 track (preferably short so you don't have to wait long for results but it works with any length). I used Pink Floyd's 'Goodbye Cruel World' (The Wall) as it lasts only 45 seconds.
It does not really matter that much what settings you have but, to simplify, disable 'Copy to XX drive' and make sure Split File Size is big enough for your test track to fit in RAM in 1 piece (I just set it to 100MB). And, oh yeah, I used a WAV file as input: no FLAC conversions etc and no upsampling mumbo-jumbo: just straight 44/16.
Open Process Explorer, open XX from RAM disk and play the track in Unattended mode.

You should see something like this on XXEngine3.exe properties dialog: (Capture1.PNG)


XX has 9 threads of which only 2 are active 99% of time. This makes sense: one thread for XX and other for .Net main loop: Nice & clean.

Now try running XX from OS disk (does not matter if it's HD or SSD) and look at same dialog: (Capture2.PNG).


Ouch. Instead of 9 there are now 39(!) threads and about 32(!) of those are active 99% of time!
And all these damn extra threads keep 'context switching' all the time so at end of song there are in total about 10,600 context switches (~240/sec): (CaptureOS.PNG)



In contrast, when XX is run from RAM disk there were in total about 5,600 context switches (~120/sec): (CaptureRAM.PNG)



Don't ask me what 10x more threads are doing and what 2x more context switches do or mean but my gut tells me that more threading & switching probably is not good for music playback....

And a small shocker for the end: Try the same thing but start XX from _any_ disk (HD or SSD) as long as that is not OS disk and you should get pretty much same numbers as with RAM disk

So, it would at least seem that XX is best run from a non-OS disk.

An exciting speculation is that perhaps less context-switching has beneficial impact on sound quality?

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

If it does, then perhaps we can push Peter to investigate how to make XX do 0 context switches in next version?

I'm not sure I buy Nick's theory when it comes to XX:
For simplicity, let's say there is only 1 track in playlist - As I understand, before playing XX will first perform conversion to WAV (if needed) and then load resulting file into a pre-locked RAM - Only then, it starts playing i.e. reading music bits from there.
So the path bits have to travel to get to XX engine is identical to one used with RAM disk: no SATA cables magic etc...bits come directly from RAM in both cases.

If, however, RAM is not locked but merely 'allocated' and memory-mapped files API is used instead then it's a different story.... 

Peter, can you comment if this is not too much proprietary info you'd rather not disclose?

>As how I call it, a pre-process happens all in memory, while a pre-pre is happening even before the sound engine starts

Aaah, gotcha...

I've finally found an old licensed copy of secret rabbit resampler I knew I had somewhere but never really needed before now Since discussion seems to indicate that SRC is more important than dither I made couple 90 secs samples from master 24/176 with secret rabbit (with 2 different dithers - just to be sure), sox (http://sox.sourceforge.net/SoX/Resampling) and same pro-resampler used for v1 but this time set to max aka 'ideal' filter steepness.

So, for those still not totally fatigued :
http://www.filemail.com/dl.aspx?id=SWAJCATOPTNNITT

Peter, can you put your head again in your horns and check if distortion ('quantization noise') in <0.5 sec is still there? (I honestly can't hear it: maybe because I'm on the road and putting my head into 10cm portable speakers does not quite work, lol
If it is, then it can't be aliasing filter can it? (with 4 different algorithms?)

On a separate note: Did I understand correctly that AP is performed in real-time? If so, doesn't that go against the principle of no processing during playback? (or did you compare to AP pre-processed files and found no impact?)

>My understanding is that dithering has nothing to do with HDCD decoding, so shouldn't be an issue here.

Yeah - but it has to do a lot with encoding...
Or maybe not a lot as Peter suspects and as I will try hopefully try to test soon

And oh:

>Josef, why do you 'suspect' that Keith Johnson and Michael Ritter (of former Pacific Microsonics) would be lying about the decimation processes in the Model Two?

Please, where did I state they were lying? People use marketing terms 'freely' all the time and these guys would not be the first so it does not hurt being suspicious - just look at that guy's Goodwin's site - PM Model 2 has processing power of '200 million instructions per second' - Wow that's as fast as 3x 486/66MHz computers or almost half of Pentium Pro from 1996
 
Let's keep this discussion open no need to get excited (and especially not over some product )

>Yes, quantization noise will be there, but therefore is the Anti Alias filter. So, in your decimation you didn't apply that, right ? (or a bad one perhaps ?). Anyway, this is not about dither ...

Alias was used - but only the default, I'll try something else.
And you may be right that we should focus on aliasing filter: I was just thinking - if version 2 without dithering but with different aliasing is sounding closer to native then maybe dither is not important.
Still - I think it will be important at least to a point: I think I know how I can test this (if I can find a piece of software I bought long time ago but never used, lol    

And, just to clarify: did you use mode AD_44.1 or AD+DD44 or something else for 16/44 version? And I assume word length was set to HDCD16?