MQN

[sbgk]

r buf

[sbgk]

fer

[sbgk]

give

[sbgk]

s mor

[sbgk]

noise.

there is an overhead in transferring the data, there is a wait call, write call, event reset, pointer increment and then if the kernel code is expecting 10ms batches of data that's another complication.

I've had small buffers in asio and think you're just listening to noise, yes it sounds more detailed, is it music ?

[jesuscheung]

i think steady stream > fast stream

that might explain why chord dac sounds better with extra buffering (or just overhead?!)

[nige2000]

i think steady stream > fast stream

that might explain why chord dac sounds better with extra buffering (or just overhead?!)

buffer size could just be an attempt to cure the jitter. regroup etc, prob still a balance thing but still an overhead too

the whole system is still terribly flawed, otherwise we could stream direct?

[jesuscheung]

i think steady stream > fast stream

that might explain why chord dac sounds better with extra buffering (or just overhead?!)

buffer size could just be an attempt to cure the jitter. regroup etc, prob still a balance thing but still an overhead too

the whole system is still terribly flawed, otherwise we could stream direct?

sgbk, possible to make a version of like buffer=64 anyway? very interested to see what that sounds like

[minionas]

Are you guys listening to the latest mqn's with mmcs or without?

[jesuscheung]

Are you guys listening to the latest mqn's with mmcs or without?

clockrate in mmcss is still improving sound. not letting go mmcss