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.
setup pro audio in mmcss as background and low latency, also used the new win 8.1 wasapi features of raw and background, not sure if raw works as it seems to want a compatible device, but seems to affect the SQ.
Am trying out ks players at the moment and the best sq seems to be at the lowest latency settings, but with wasapi I was trying to align the sample size with the 4k pagesize which seemed to work as well.
Why do you say that larger sample sizes are perhaps better ?
WindowsX wrote: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.
ok...
WindowsX wrote:
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'.
what did XXHighend and jplay agree with you on clockrate? what is the exact value and settings.
tell me exactly what to do. so i can test it and compare. otherwise. you are just making claims i cannot verify.
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.
setup pro audio in mmcss as background and low latency, also used the new win 8.1 wasapi features of raw and background, not sure if raw works as it seems to want a compatible device, but seems to affect the SQ.
Am trying out ks players at the moment and the best sq seems to be at the lowest latency settings, but with wasapi I was trying to align the sample size with the 4k pagesize which seemed to work as well.
Why do you say that larger sample sizes are perhaps better ?
For WASAPI, internal audio latency in WASAPI is 5ms. I dicussed with Josef a few times about KS VS WASAPI and the strong reason why Josef and Co. favor KS over WASAPI is being able to get 1ms latency natively while you can never archive real 1ms through WASAPI because MS framework can't get below 5ms.
As for sample size, I never say having larger sample size is better. Longer processor scheduling quantum to audio thread in background task is.
jesuscheung wrote:
WindowsX wrote: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.
ok...
WindowsX wrote:
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'.
what did XXHighend and jplay agree with you on clockrate? what is the exact value and settings.
tell me exactly what to do. so i can test it and compare. otherwise. you are just making claims i cannot verify.
you know my exact settings. what is yours?
I thought stating about low latency made it explicitly clear already sorry. What I meant to say is setting clock rate as low as possible. In Windows Vista, Microsoft even added 100ns invterval guarantee but that consume battery a lot and removed in later versions. Just tweaking clock rate from 10000 (1ms) to 5000 (0.5ms) or 1 (100ns) may not give you positive result just like Fidelizer since you didn't tune your system in favor for low latency audio. If you see its potential and willing to correct your own tuning, you may find something new to improve your system. Otherwise, you can just ditch clock rate and stick with what you prefer.
A breath of fresh air WindowsX....nice clear and easy to understand clarifications on an area of windows I know little about.
Hope you hang around here a while longer and educate those of us who are new to the underbelly of windows!
Cheers, Pearse.
WindowsX wrote:
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'.
jesuscheung wrote:
what did XXHighend and jplay agree with you on clockrate? what is the exact value and settings.
tell me exactly what to do. so i can test it and compare. otherwise. you are just making claims i cannot verify.
you know my exact settings. what is yours?
WindowsX wrote:
I thought stating about low latency made it explicitly clear already sorry. What I meant to say is setting clock rate as low as possible.
lowest clockrate is 1 in MMCSS registry. this is what you would recommend over any other higher clockrates?
Last edited by jesuscheung on Thu Jan 30, 2014 3:38 am, edited 2 times in total.
wademcinnis wrote:With XP we were able to reduce the whole installation to a little over 18 mB. That was the total size of the root directory.
Registry was 24kB.
From what I have experienced with SERVER 2012 we will NEVER get anywhere close to that. Not even an order of magnitude close.
Makes me wonder if XP 64 is the way to go with MQN?
JC, what do you think?
24KB?! that's impossible for win2012! haha
take for example,
in win7/8, MS stores information about windows update in registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing
when i export this as a reg file, it is about 10 to 15MB! you can totally delete most things under it.
if you do, your registry is already reduced by 10%.
(still not sure why MS won't store things in a SQL file. insists on using tree)
jesuscheung wrote:
24KB?! that's impossible for win2012! haha
take for example,
in win7/8, MS stores information about windows update in registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing
when i export this as a reg file, it is about 10 to 15MB! you can totally delete most things under it.
if you do, your registry is already reduced by 10%.
(still not sure why MS won't store things in a SQL file. insists on using tree)
Interesting, JC.
I definitely like the idea of trimming the registry, somehow never occurred to me. Much easier of an exercise than tackling more of SysWow64/winsxs etc., it would seem.
Wade you probably remember more than I, but wasn't there an ISO floating around Computer Audio Asylum in the cics thread where JackWong(?) or someone or another had stripped XP down to somewhere around 16MB? Might be interesting for JC/others to hear if we can track it down...
WindowsX is providing some good insights, too. He usually was a little less forthcoming on other forums, but to his credit people on other forums tended to be bits is bits idiots and basically harassed him, as if fidelizer was going to irreparably break their Windows install if he didn't reveal its source code.
trying to make a audiophile installation ISO for win2012. Microsoft is already breaking my face
only trying to delete a printing driver using powershell:
PS E:\> Remove-WindowsDriver –Path .\Mount –Driver prnxxcl3.inf
Remove-WindowsDriver : The specified driver cannot be removed. Removing a default driver package is not supported.
gonna have to go through the hardcore way... kill me already...