Rather then being theoretical - can we get practical?
E.g. Would you care to share how you configured a superior WASAPI system so everybody can test it as well?

LOL: Yes, but there is a reason why this is such a controversial topic - in short, I'm not sure anybody completely understands what exactly is going on as some of it is counter-intuitive (which is a nice way of saying it makes no sense at all  ) and experimental findings are not always positive i.e. sometimes low latency can become 'too much' and distort the sound or, should I say, impart our enjoyment of music. (which, by definition, is subjective, so it makes the topic even more difficult....)

But - that is why we have Marcin!


Ah, forget about Peter  ( I'm sure he won't mind as everybody else went to church anyway )

We also exchanged some mails on the subject and I think you are really The guy who has tried more then anybody else out there! AND is willing to share what he had found 

I say, give us the goods and let the controversy begin!

This really is not about wasting memory - rather, it's about memory being as continuous as possible!

For example: if you implement Windows Large Page feature, for e.g. 100MB SFS (=setting of 50 in z3, 100 in z2) you will have 50 pages.

Suppose average size of WAVs is 5 minutes i.e. ~50MB. Now that you convert it to 32 bits you need 100MB i.e. all 50 pages. But if you keep SFS at 16 bits (if DAC==16/44) then you only need half RAM i.e. 25 pages: In other words, on average, you increase the chances of having the complete WAV fully continuous in RAM by 100%.... (likewise, for 24 bit DACs you'll increase the chances by 50%.) Why? Because while each 2MB block is guaranteed to be continuous, individual blocks can (and, chances are, will be) scattered around! So, less blocks = better chances of having more of WAV continuous in RAM

After all, it seems it's only when using your DAC that 32 bits make sense as AFAIK you use extra bits for digital volume control so you really do need them....(but even that is debatable if people opt to use pre-amps instead )


Yes - Agree it does not make a difference but there's more to it as you will get the same thing with HD or SDD (nothing special about RAMDisk). Ultimate rule master here is Windows' virtual memory manager which _always_ works with 4KB pages.

Cluster sizes do have a role though: they are meant to enable fine-tuning of disk access times for particular loads. For example, both music & video files are rather large. Having larger cluster sizes helps improve disk read speeds on HDDs by reducing fragmentation. In theory this is also beneficial for RAMDisks as for, e.g. 64KB cluster you need less RAM accesses then for 4KB (1 in best-case vs up to 16 RAM accesses in worst-case!)
In practice, however, if you defragment your HDD you get all the benefits even with default 4KB clusters and RAM access is comparatively so fast that it does not matter what cluster size you use....
It might, however, matter if we were playing directly from RAMDisk but we don't do that so it's a moot point

Don't feel bad Actually, I suspect .Net is _not_ your problem here - rather, it is Windows itself. I'm afraid the only way to get all SFS memory contiguous would be by writing a kernel device driver: drivers can allocate contiguously, user applications cannot....

Think the most you can achieve in user space is have 2MB contiguous blocks by using large pages feature (I'm pretty sure that's not what you're doing at the moment). It's still a lot better then default 4KB pages and also has added benefit of having everything locked in RAM (it can't get swapped out). Additionally, CPU caching would be improved even further so all in all it should have a rather positive effect on SQ.

However, if you decide to pursue this then I'm afraid you will have to first convert XXEngine3.exe process into an auto-start service (which should be relatively easy). The way it works now (memory being released after playback stops and then allocated again when it starts) would probably result in Out Of Memory exceptions very, very quickly....


If you decide to pursue above strategy then memory will become scarce quickly and maybe you'll need to 'optimize' by not expanding to 32 bits if DAC is selected as 16/44.....(would reduce SFS RAM needs by 50% and thus make it much easier for Windows to find contiguous blocks)


 

This is a bit confusing to me: Does it mean one would need an Express Card sound card? (e.g. like Indigo? http://www.echoaudio.com/Products/ExpressCard/IndigoIOx/index.php)

And for PC is a special PCI card required or is that supplied with DAC?

Nice to meet you all guys there! I agree it just wasn't working but these things happen - hopefully next time it will be better.

For those not present, maybe it's interesting to know: I saw an USB input on DAC but after talking to Peter it turned out it was NOT for audio! Apparently only PCI Express is supported as input so if you don't have it (e.g. my laptop doesn't) you're out of luck.
Also notice that you will absolutely need PCIExpress as there are also no SPDIF/Toslink etc connectors - The 'PC D/A Converter' on the box really does mean you'll need a PC!

No, it does not work like that.
For native application (e.g. written in C++) you would get twice the memory allocated only if you are e.g. allocating an array of integers instead of bytes AND you recompile with 64-bit compiler.
In .Net however, integers (and other data types) stay the same size. Only pointers are expanded to 64 bits (for obvious reasons). You can also force 32-bit pointers to be used always (look in compilation flags and utilities e.g. corflags.exe)


I noticed that z3 uses twice as much memory as z2: z2 used 3xSFS size and z3 uses 3x2xSFS - I wanted to ask you if this was by design and by looking at above it seems it is.

But I guess you wanted to say that last part should be 1/2 SFS size and not 1 SFS? (because that's what I see: e.g. for 100MB SFS there are 3 blocks of 200MB and 1 of 50MB)

I am not sure what you mean by 'contigious' though: Looking at memory it can be seen that SFS blocks are NOT contiguous - maybe that's another idea to implement?

> If I say (in the program) I want A to have priority over B, this doesn't work in W7 because it seems to have its own rules.

Wow - I didn't know it was that bad I thought it's just design changes in kernel which made W7 lose it's luster over Vista....
But if you are seeing such bad behavior then maybe it's just a bug and there is still hope for W7 - Perhaps it's an idea to try SP1 (think it's in RC stage now so pretty much done) and see if maybe MS fixed it?

> And as you know we can now reach 1/88200 at 32 bits easily which is over 100 times lower than 1ms. So, how real time do we want real time to be ?

Excellent question!

It's pretty impressive that you can get 11 microseconds latency with your DAC - I am not able to even get close to those numbers
Could it be because of USB (my case) vs PCI (your case)?

If such low latencies are indeed important then due to way it works seems USB would be doomed in this regard?
 
In other words:

- what is your position on need for low latency?
- and do you think that for 384kHz playback a latency of 1/384 i.e. 2-3 microseconds might be needed for absolute maximum performance?

I have read quite a few discussions on this subject and people generally seem to fall into two camps: Either they believe low latency is absolutely necessary for high-quality audio playback or they completely dismiss the idea and even go in opposite direction by _increasing_ latency ('just get bigger buffers' camp).

Also, on this forum while pretty much everyone has moved to KS it seems that there is significant amount of people using Adaptive vs Special mode. Wouldn't it be interesting to find out if people with USB statistically tend to prefer Adaptive and vice versa? (Would you consider making a poll on the forum? )

(Please note this post is not a red herring: I've been reading around and it seems 'low latency playback' is a super-controversial topic that spilled a lot of blood in some internet forums. I'd completely understand if you'd rather choose not to answer and risk being vilified in some of those other forums. However, as someone who has spent years on getting 44.1 to 384kHz and making it work in both SW (ArcPrediction) and HW (your NOS DAC) it obviously makes you uniquely (and much more) qualified to voice your personal observations). 

That's interesting as, purely in theory, due to its infinite tweakability Linux could be made superior to Windows (including current 'gold standard' Vista): Are you at liberty disclosing what were those Linux implementations you heard?
 

In reality, apart from obvious suspects like 'Indexing/SuperFetch' etc (i.e. high I/O usage services) most other services just sit idle and have zero net effect on SQ.

I'm afraid Vista simply has too many architectural changes which are beneficial to SQ (in theory). For example, thread scheduling is drastically improved and let's not forget that whole audio stack has been completely re-written from XP (just look at addition of MMCS service as an example what kind of attention MS has given to audio playback).
Likewise, I'm also afraid that Win7 has introduced several more kernel changes which might make for a better 'general-purpose' OS but result in worse 'audio playback' OS and, sadly, it seems those changes aren't reversible...

I doubt you will get better sound from XP but do keep us posted - it makes for an interesting read!

Ivo,

You do not need network - in fact, you want to get rid of it for best SQ!
You do need .NET as XX is written in it.
You will need to activate Vista with a legal key - not doing it is illegal, so don't even think about it even if you find a workaround, it's just wrong!

As for 'cutting out too much' I will refer you to my post once again.
Please read & try once more - as Marcin reported he got vLite to work with Server 2008 SP2 it _should_ work with Vista SP2 as well!

Ah, that's something else - I had the same problem and it drove me nuts: I guess you had Win7 installed before?
Turns out Win7 will create a 200MB partition for BitLocker before 'real' Win7 partition.
Unfortunately, Vista just assumes that first partition should be used to copy installation files so it will use that small partition
You'll have to delete BitLocker partition (if you are not using it) or move it after your Win7 (or Vista) partition. Think this one will work: http://www.extend-partition.com/free-partition-manager.html

Note that moving partitions around is not recommended if you have important files on HD without making  a backup first.

If you followed instructions from my post then it's more likely vLite simply does not work with SP2.
But here's my .ini file so you can check...

Oh, your feeling is right: you will not be able to get 'Vista sound' - I'm just curious whether it helps resolve glitches. (BTW when you mention BluRay that may be related to having proper codec: I had extreme stuttering until I got a proper one....)


I'm afraid not...