I'm afraid OS is not a problem here. Peter's post seems to me to be describing problems he is having with .Net memory management and, specifically, garbage collection.

If memory is allocated directly in OS (instead of via .Net) it is trivial to lock it in RAM and have OS's hands off: No paging, no garbage collection, no object reference counts yadayadayada - nothing. Just a piece of memory sitting there, quietly, undisturbed........

But if you go via .Net.....well, it is _still_ possible, but not nearly as simple.....

Peter, could you elaborate on this?

I'm not sure what goon-heaven had in mind but I was thinking what would happen if you used memory mapped files?
It would cut down XX memory requirements to (essentially) ~0 (compared with current SFS setting) .
It would leave more memory for RAMDisk.
It would avoid problems that you seem to be having with memory management (although I think in essence you are solving self-inflicted problems because you are using .Net).
It would, in theory, solve all SFS issues and provide more predictable resource usage instead of flurry of I/Os you have now when you load next track.

In theory, it would also have net negative effect on SQ when playing from HDD/SDD but shouldn't it be equal (maybe even better?) if RAMDisk is used?

Of course: theory & practice don't necessarily go hand-in-hand, so I'm curious if you have any experience with memory mapped files approach (especially in tandem with RAM disk) you'd like to share with us?

 

Ah, I knew we had a misunderstanding: 'case reopen' _was_ related to your post, specifically to this:

I thought you referred to Nick's Affinity Tool trick not working which I demonstrably proved _does_ work. But now I see you were instead talking about Affinity _key_ for MMCS which I said I did not even bother trying because none of those keys could possibly work in Engine #4 (again proved in experiments mentioned).

No offence, your posts sometimes are not exactly easy to follow (to say the least ) but in this case it was me not following _very_ closely what you wrote so I misunderstood - sorry for that!

Back to topic: About the MMCS keys themselves I think I completely agree with you: I did not look at it before but now I read that link on MS site and it pretty much clearly states that all those keys are not effective unless application specifically asks to join MMCS as managed thread:

"Each thread that is performing work related to a particular task calls the AvSetMmMaxThreadCharacteristics or AvSetMmThreadCharacteristics function to inform MMCSS that it is working on that task." 

And the code sample they refer to (http://msdn.microsoft.com/en-us/library/bb614507.aspx) clearly shows that application needs to call those APIs to have keys 'activated'. I believe Media Player is using those APIs as there was a much publicized scandal when Vista came out initially and it turned out it killed network speed whenever Media Player was playing music, lol - Culprit was, indeed, MMCS  

So yes - case closed on MMCS.

But maybe not quite, actually

Notice in my posts I showed that MMCS will indeed get activated every 10ms even with XX (Engine #3). While we can close the case on 'Profiles & Keys' being non-effective for XX, I'm afraid that MMCS is still doing _something_ as I can see an increase in #interrupts  whenever MMCS is active.

I don't plan to spend more time on this but I have been able to verify one thing that _does_ get changed regardless of whether those 2 APIs are used or not! It seems that system resolution timer changes from default 15ms to 1ms when MMCS is 'active'.
Gosh, who knows what else is that thing doing.....better to stay away from it....

Marcin: 2 cores (plain vanilla Intel Core Duo).

I solved the problem late last night but was too tired to post: What happened was that I did activation only in XX run from RAMDisk. When I did a _proper_ activation i.e. when XX was started from SDD it didn't go to demo mode after reboot.


I'm afraid I don't understand a word of what you just said (especially that thing about 'profiles').

We may have a misunderstanding here which is probably my fault for not more clearly explaining what I did and what I 'saw' so let's try it this way:

1. Open ProcessExplorer and add column 'CSwitch Delta' to display
2. Let XX play using Engine #4
3. You should _not_ see any increase in CSwitch Delta next to your svchost.exe processes (some go up & down at times but that is normal)
4. Now let XX play using Engine#3
5. You _should_ see one of those svchost.exe go to 100 CSwitch Delta: If you have a quiet system this will be obvious as previously it was probably not active at all (my case). And it is 100 because MMCS gets activated every 10ms per MS defaults. How do we know?
6. Right-click svchost.exe->Properties->Services: MMCS should be in the list.

That's it.

So this is purely an objective technique to prove when MMCS gets activated. As I said, what/if it does anything to sound and whether it is really influenced by registry tweaks is beyond this - I plan to test that later but it's not my priority (as Engine #4 simply sounds better).

And about testing IRQs: it's also easy:

1. Open ProcessMon and look at DPCs queued/sec & Interrupts/sec.
2. Do this with different Interrupt Affinity tool settings (e.g. affinity to CPU0, CPU1, none)
3. You should see a clear pattern of (especially DPCs!) following CPU you used for affinity

Again: keep in mind that reboot is required after changing affinities.
Also, and this is what I discovered later, if your sound device shares IRQs with other devices you MUST set all of those to same CPU! For example, my laptop has 2 USB ports but both share same IRQ. So, in effect, sound device (solo on port 1) was sharing IRQ with mouse & HDD on port 2. Device Manager showed 3 'Host Controllers' associated with this same IRQ. I had to set affinity for ALL of them to be the same, otherwise it didn't work.

So, again, no subjective (listening) impressions here just easily observable facts.

Please do try these 2 simple experiments and post your findings!
You never know, maybe there is something weird about my laptop or I have made a mistake (and I can certainly make some, like 'rogue' Q2 setting from last week Well, at least we all learned about what Q2 really does and it is quite amazing in it's own way but that should go into a different topic )

Not so fast: case re-open!

I was finally able to try out Vista (thanks Peter for the key!) and, indeed, I must admit that overwhelming positive response here is fully justified! (This is so weird I still have trouble believing it so my next step is to install clean Win7 just to make sure this is not a placebo or a corrupted Win7 installation.)

I was also able to test a couple of tweaks mentioned here and so far I can verify the following:

1. MMCS registry settings: These have no effect in Kernel mode (Engine#4).
This is very easy to verify as MMCS service is clearly completely inactive  when XX is playing via Engine#4.
However, it can also be seen that MMCS does work when WASAPI (Engine#3) is used and it works as advertised: popping up every 10ms and doing it's thing (whatever that is). (note I have not tried MMCS registry tweaks as I have used only Engine#4 so far).

An interesting note: seems that Foobar (which, btw, also sounds better under Vista) does _not_ really use Kernel streaming even though it can be selected! The reason is that MMCS is clearly active when Foobar works (whether WASAPI or Kernel is selected) while it's dead as rock when XX is playing via Engine#4 - a proof of just how difficult it is to get KS 'right' and/or proof of Peter's audio-programming prowes? Kudos to Peter anyway   (note I used 'older' Foobar 0.9.6.9 but Kernel Streaming component hasn't changed since 2006 so it should not matter...)

2. Much more interesting (at least to me) was Nick's Interrupt Affinity discovery as I was frustrated not being able to get it to work under Win7 and yet I believed in (at least) a theoretical merit of being able to manually appoint interrupts to CPU cores. Short story: Nick was right!

Affinity tool works perfectly well under Vista SP1 64 (not tried 32 and Peter I believe you are on 32?)
I could clearly hear DAC 'ticking' when tool asked to restart device. Likewise, my mouse stoppped responding for a while and USB HD came up from sleep. But, I did have to reboot - even with all devices properly restarting affinities were NOT applied until after reboot.
Curiously, XX reverted to demo mode so I had to reactivate it every time I changed affinities (it worked OK every time though).
I first observed interrupt & DPC distribution without affinities, then with USB Host Controller (with Offramp attached) set to CPU1 first and then to CPU0. When there is no music distribution is about equal between cores, as would be expected. However, playing music will drastically increase #DPCs from 200-300 to 1,400-1,500 range.
It could be clearly seen that CPU1 handled _all_ these 'extra' DPCs while CPU0 was practically unchanged from 'no music' state.
And when affinity is switched to CPU0 then _it_ would serve Offramp's DPCs and CPU1 would show no change. There is no way around this - this works! Kudos to Nick!

Now back to listening tests

>I wouldn't search for it, just try, it takes few minutes and you'll know

By reading about it I was able to ignore it straight-away as the consequence is apparently a disabled C3 CPU state which I have measured earlier and know to be active for 99% of time when XX is playing in my setup

But, (also found by reading ) if you have a Logitech gamer's mouse (or any similar 'ultra responsive' mouse) _maybe_ you indeed have a problem - Good thing is, you can prove or disprove experimentally by running this small utility: http://www.filefront.com/14309831/dimr.exe/

It will show you how often your Logitech (or any USB) mouse is being polled - If you get 1ms without registry tweak and 5ms with it then that would validate the tweak (or invalidate it

> I disabled some more hidden devices in device manager and applied the most recent optimisation from cics' site - the one responsible for reducing USB polling

Could it be you did _both_ of them at same time?
'USB polling fix' seems to be a known 'does nothing' thingy:

http://www.techradar.com/news/software/operating-systems/10-windows-speed-tips-that-don-t-work-686087?artc_pg=2

Ok, I braved to try this affinity trick but it does not work
The tool displays a weird error message - see screenshot. I rebooted, looked in registry and see that values are indeed there (screen2) - But if I start tool again I get same error: WTF?

That would be best but unfortunately is not what I saw last night: Most active IRQ was well-balanced between cores 0 & 1, while all DPC calls to MAudioTransit happened on core 0....(It might be specific to this driver though.)

And same thing happened with Foobar so it does not look it's XX-related...

I think I will have to disable all USBs apart from OffRamp connection, apply Nick's affinity tricks and see what happens in that case....

But does this imply that the "4GB outside of the OS" just works ? (IOW, use 3GB under the 32bit OS and in the mean time have the ram disk of 4GB)
[/quote]

It is my understanding that you'd need Win Server Datacenter or Enterprise edition in order to be able to use more than 4GB.
But why bother with 32-bit versions? 64-bit has no limit plus you get back RAM that your GPU may have 'stolen' (Half a gig in typical case).....

Yes - In theory, it makes a lot of sense because IRQ is only part of the story - In fact, IRQs most times won't actually _do_ much but rather schedule a DPC call which 'does the real job'.

Unfortunately, AFAIK DPC affinity cannot be influenced by user - it is set in driver code

Still, practice shows (at least for Transit driver) that DPC goes to core 0 all the time and it is sound-driver DPC we care most about as it probably makes sense to make sure it's _not_ interrupted ever!
 
Hence, sound-card IRQ should be 'solo' (because it generates most interrupts by far - assuming you have already made your setup 'quiet') and on a dedicated core but not on core0 because we want sound driver DPC to be un-interrupted at all times.

Again, this is all in theory and just trying to make sense of what is going on: I wish I had a quad & six-core to experiment
 

Thanks, Nick.

I _am_ using a laptop, indeed, so I have no option of choosing USB ports - there are only 2 physical ones: 1st for USB-SPDIF (older OffRamp model based on M-Audio Transit driver) and 2nd for external Hub with WD HDD and mouse (no PS/2 connections either...).

I think the important think when it comes to USB is never to have other devices on same port: I have tested this myself and, indeed, if I connect OffRamp via Hub it sounds terrible beyond repair. It works good on its own though, but it's really annoying for Intel to have put all USB ports on same IRQ...

There are, however, multiple 'USB Host Controller' devices in Device Manager: I will try disabling devices that share IRQ with OffRamp and see if Windows will switch HDD/Mouse to other 'Host Controller'....

But before that, I guess I should investigate booting from USB stick: that way, if anything bad happens, only the stick needs to be reformatted....

Oh, BTW: Putting affinities on devices without IRQ IMHO is worthless: as there is no IRQ to begin with those settings are ignored. I tried this with M-Audio Transit driver and can see that DPC calls are always serviced on core 0 regardless of affinity settings...

 

Mani, do you use 64-bit or 32-bit W2008? And for W7?

>If you want to try the settings add them say 10 at a time and reboot so that you can fault find if they do not work for you machine.

Nick, isn't this a bit dangerous? According to http://www.microsoft.com/whdc/system/sysperf/intpolicy.mspx :
"generally you should not use IntPolicy on any device sharing interrupts with another device"

Like you, I also have a USB-to-SPDIF and 'USB Host controller' apparently sits on IRQ 20. But that IRQ is shared by 2 other USB Controllers, one of which is 2nd USB port with mouse and external HD on it (and via External Hub to make matters more complicated...)
Is it wise to change affinity then? (I'd rather not risk if there is a chance of problems)

Also, in your Word Doc you suggest to set affinity for sound card i.e. driver: But the sound card itself does not have any IRQ assigned and according to above link:
"Even though all the computer devices appear in the Devices list, we recommend that you use IntPolicy only on devices that have interrupt resources"

They don't say why they recommend it, but it makes me having second thoughts.....

What is the situation in your system: Does your USB controller share IRQ with other devices? Have you then set affinity for _all_ those devices?