Tír Na HiFi

wademcinnis wrote:
So are you using the onboard audio stuff? Excuse my limited understanding of all the ways to use a computer for audio. All I seem to know is what I have used!

Sorry for such a late response. I feel like you're being facetious, but:

No wade, I'm disabling onboard audio, actually, and using a USB DAC. So, literally, I have another component outside of the computer, which communicates with my PC via USB connection (using an 'audiophile' Furutech USB cable, of course!), converts the digital packets to an analog waveform, which continues the signal path to my amplifier and then to my headphones. The only role my motherboard plays is transmitting the USB data (which, admittedly, is significant).

Thought you would be doing basically the same thing as I (Waveio to DAC) but wanted to be sure.

It effects what one can and cannot do with deletions, etc.

I have re-installation fatigue so my tinkering is taking a break.

I did try deleting the files you posted and they did not come back. Of course, they are still there until we take them out of system32. I figure most of them are "listed" there, too, but have not checked completely. But if they are not "listed" there they are somewhere else.

(The search function with SERVER 2012 is useless. With XP you could find out where things are in all of the nooks and crannies. Maybe I do not have the search thing configured properly since I have done nothing to it? )

system32 is much more particular as to what you can take away. I have found out the hard way many times. Sometimes you can repair the install by replacing the stuff from another computer but many times after replacement all I can get is that first grey screen, if I get that.

oy,ve ...

start to deleting things in c:\windows and in c:\system32

for c:\system32, think one can delete any exe file that has icon logo without affecting system stability.
however, SQ goes bad if any exe file is missing.
for example, delete 10 exe files. listen. copy them back. listen again. SQ changes immediately.

shame...

c:\windows\boot
now, i just picked a random folder. deleting files c:\windows\boot
if any folder is missing, SQ goes bad. in my case, intense sound.
if files are missing, think SQ might have gone strained. not sure. not sure soundstage got pushed forward or actually got bigger a little bit. didn't backup and compare.

JC,

At this point I know you are right.

Starting to think what works for XP does not NOW!

I appreciate your scientific/using one's ears approach.

Take care,

additional thread research brought me here but not for audiophile purpose though lol. It looks like you have different design philosophy and approach to mine so Fidelizer may not work great on your case. Do you favor audio buffering lowest or highest possible? From the looks of your tweaks, many of them are keen on believe to serve buffer large enough to match timing believed to be right approach making solid performance low latency optimizations a bad cure. These are 4 core things Fidelizer does

1. Set NTTimerResolution to lowest possible at 0.5ms (good for low latency audio and solve stuttering for some cases)
2. Optimize MMCSS differently to yours but doesn't leave permanent changes after reboot. Calculating clock rate to match audio samples is misconception because it doesn't schedule only audio but all resources to processor. So this is like resource scheduling timer and raising it means you're leaving low latency principles behind so I won't be surprised if Fidelizer can go wrong in your case due to different design philosophy.
3. Set audio thread priority to real-time level for NT6 platform. For XP and before, simply raise audio service controller process priority instead.
4. Optimize process prority/affinity. It's hard to say which is the best approach for every machine so I'm sticking with simple yet efficient approch for now.
5. Shutting down non-audio services freeing resources and reduce no. of interrupts/handles/latency spike.

Since people have different taste and perspectives, it's OK to try and find what they like. Blaming Fidelizer a bad tweak is also their choice from their experience but that would narrow their minds down to what they only prefer IMHO.

WindowsX wrote:additional thread research brought me here but not for audiophile purpose though lol. It looks like you have different design philosophy and approach to mine so Fidelizer may not work great on your case. Do you favor audio buffering lowest or highest possible? From the looks of your tweaks, many of them are keen on believe to serve buffer large enough to match timing believed to be right approach making solid performance low latency optimizations a bad cure. These are 4 core things Fidelizer does

1. Set NTTimerResolution to lowest possible at 0.5ms (good for low latency audio and solve stuttering for some cases)
2. Optimize MMCSS differently to yours but doesn't leave permanent changes after reboot. Calculating clock rate to match audio samples is misconception because it doesn't schedule only audio but all resources to processor. So this is like resource scheduling timer and raising it means you're leaving low latency principles behind so I won't be surprised if Fidelizer can go wrong in your case due to different design philosophy.
3. Set audio thread priority to real-time level for NT6 platform. For XP and before, simply raise audio service controller process priority instead.
4. Optimize process prority/affinity. It's hard to say which is the best approach for every machine so I'm sticking with simple yet efficient approch for now.
5. Shutting down non-audio services freeing resources and reduce no. of interrupts/handles/latency spike.

Since people have different taste and perspectives, it's OK to try and find what they like. Blaming Fidelizer a bad tweak is also their choice from their experience but that would narrow their minds down to what they only prefer IMHO.

Interesting, thought it did a bit more than that, I found it makes the sound a bit soft, but when I first started looking at computer audio it was a revelation and helped calm down the SBT a bit, yes the improved running of lms did affect the sq of the touch.

What would be your recipe for the perfect player software, have you thought of writing your own ?

wademcinnis wrote:JC,

At this point I know you are right.

Starting to think what works for XP does not NOW!

I appreciate your scientific/using one's ears approach.

Take care,

i am starting to deleting things in registry. registry size is about 200MB in win2012. so there is a lot to do.
think deleting things in registry helps SQ

i am hoping to strip my registry to about 150MB. that's about the size of my win7's size. i am sure XP has even smaller registry size.

WindowsX wrote:additional thread research brought me here but not for audiophile purpose though lol. It looks like you have different design philosophy and approach to mine so Fidelizer may not work great on your case. Do you favor audio buffering lowest or highest possible?

please read my earlier post. viewtopic.php?f=15&t=2456&p=47162&hilit ... ion#p47118

i believe audio buffer isn't about big or small. it is about in syn with clock rate.

for example, mqn has buffer of 1024. my DAC works best at 352. i rather have my clockrate in syn with 352 than with 1024.
352 is actually 7.981ms=8ms, which is multiple of timerresolution of 0.5ms, 1ms, 2ms etc.
in this case, the synchronization is ok.

with xa, i can set buffer to to exactly 352. this is perfect synchronization.

WindowsX wrote: 2. Optimize MMCSS differently to yours but doesn't leave permanent changes after reboot. Calculating clock rate to match audio samples is misconception because it doesn't schedule only audio but all resources to processor. So this is like resource scheduling timer and raising it means you're leaving low latency principles behind so I won't be surprised if Fidelizer can go wrong in your case due to different design philosophy.

my MMCSS reg file is copied from pkshan's blog.
i cannot change anything to make it better. so i just assume that's the best possible.

please compare your MMCSS vs pkshan's MMCSS setting using your ears. i did. i choose pkshan's solution.
sbgk also has some setting relating MMCSS. didn't change my mind. not yet hehe...

WindowsX wrote: 3. Set audio thread priority to real-time level for NT6 platform. For XP and before, simply raise audio service controller process priority instead.
4. Optimize process prority/affinity. It's hard to say which is the best approach for every machine so I'm sticking with simple yet efficient approch for now.
5. Shutting down non-audio services freeing resources and reduce no. of interrupts/handles/latency spike.

i am getting annoyed by you. you talk too much. test with ears first. reasoning is second.

WindowsX wrote: Since people have different taste and perspectives, it's OK to try and find what they like. Blaming Fidelizer a bad tweak is also their choice from their experience but that would narrow their minds down to what they only prefer IMHO.

you have some bad tweaks in terms of SQ. that's it. i have bad tweaks too.

when i have time, i shall try your tweaks and see if it improves CPU overclocking benchmark. that's my another hobby.

Your understanding about MMCSS's clock rate is incorrect. It might work in your believe if clock rate is designed solely for sending audio stream though I don't believe in that side but no. Clock Rate is used to assign everything be it audio/video/network and everything that count as resource to be fetched to CPU. Only thing that you can set like that is audio output buffering size. Since you don't believe in low latency performance, getting right harmonic and tonal balance is easier with larger chunk of data. But I won't say yours is bad tweak because we believe in different things and that's one of of showing my respect to your work.

If you get annoyed from just explaining what Fidelizer does, I don't know whether I should continue discussing with you to improve our tweaks. I tried all tweaks with reasoning and ears so don't force your prejudge on me saying things like I don't test tweaks with ears. I don't like talking with such attitude like that. If we can agree to talk in such good manners, I'm willing to continue discussing further about this.

P.S. Let me tell you the reason why I'm positive about clock rate. There's one registry key I suggested Marcin to try when he was still using XXHighEnd. From that key as starting point, he had to revise all of his tweaks and considered many of them bad himself, left XXHighend and found JPLAY with Josef. That registry key was 'Clock Rate'.

sbgk wrote:Interesting, thought it did a bit more than that, I found it makes the sound a bit soft, but when I first started looking at computer audio it was a revelation and helped calm down the SBT a bit, yes the improved running of lms did affect the sq of the touch.

What would be your recipe for the perfect player software, have you thought of writing your own ?

You may want to change processor scheduling to 'Background Services' . Since audio is background task so it will get highest possible priority that way. I used to think about writing own player but after seeing how poor hardware architecture and design of computer is, it's like trying to get clean water from mud as good as ones from onsen.