Board.KolibriOS.org

art_zh wrote:forart.euplease stop lecturing me on the subject I was studying for over 25 years!

...lecturing you ?!?

I've posted this idea here exactly 'cause I perfectly now that asm-devs are *pretty familiar* with clocks, executions x clock, timings, latencies, etc. (I still remember the controversial "realtime-OS" 3ad...)

art_zh wrote:you better start thinking by your own:

Q: what is CPU clk jitter range? >> A: ~100ps @ 1GHz
Q: what is audio sampling freq? >> A: let's say 44kHz, or ~20,000 times lower than CPU's
Q: can we improve random jitter dividing the frequensy by factor of 20,000? >> A: yes. the Gaussian averaging factor will be sqrt(20000) ~ 150
Q: what the resulting jitter we expect at 44kHz after such division? >> A: less than 1ps (!!)

I know that you all (devs, of course) know *mutch* more than me (I'm just IT high-school graduated in Italy... I've writed a dozen lines of ASM in my life... just a little more than "hello world" !!! Now I "typewrite" some PHP... I'm definitely *not* a developer.)

EDIT: BTW *should be* 24 (or even 32) bits / 192 kHz (note that win7 x64/i5-2500k @ 3.6/4Gb can't in WASAPI mode, at least with foobar).

art_zh wrote:Q: and what shall we think about this sentence:

one audiophile wrote:The best sounding one was a cMP²-configured i3, one core disabled and underclocked to optimize the jitter...

A: nonsense.

Q: but, in general, why downgrading CPU can improve audio quality at all?

I don't care about that guy... and honestly I don't like - as CMP author suggests - to use my OS @ 16 bits color depth !

art_zh wrote:A: it is 100% due to hardware problems: EMI, power spikes, line crosstalks, poor PCB layout etc.

Of course, better electronics produces better results... but "some" improvements could be achieved with a well-calibrated software (read "dedicated OS/distro"), IMHO.