Tír Na HiFi

Is the synchronisation to do with alignment of the ks signal to the dac master CLK?
That's probably just a bad guess

Sounds very important all the same

The mobo clks are one thing only but I was surprised at the type of improvement which was mostly more fluidity but fluidity with lashings of detail and resolution
Which I think is something we're all looking for The best of two worlds

nige2000 wrote:Is the synchronisation to do with alignment of the ks signal to the dac master CLK?
That's probably just a bad guess

I didn't interpret the master clock to mean the DAC's master clock but rather the mobo's master clock.

Sounds very important all the same

The mobo clks are one thing only but I was surprised at the type of improvement which was mostly more fluidity but fluidity with lashings of detail and resolution
Which I think is something we're all looking for The best of two worlds

Well, Gordon's identification of this KSTime parameter seems to, in my mind, throw some light on how better(more stable, more accurate) mobo clock timing might have an audible effect. Hope I'm not over-reaching here?

jkeny wrote:

nige2000 wrote:Is the synchronisation to do with alignment of the ks signal to the dac master CLK?
That's probably just a bad guess

I didn't interpret the master clock to mean the DAC's master clock but rather the mobo's master clock.

Sounds very important all the same

The mobo clks are one thing only but I was surprised at the type of improvement which was mostly more fluidity but fluidity with lashings of detail and resolution
Which I think is something we're all looking for The best of two worlds

Well, Gordon's identification of this KSTime parameter seems to, in my mind, throw some light on how better(more stable, more accurate) mobo clock timing might have an audible effect. Hope I'm not over-reaching here?

there are other instructions to assign a master clock to a pin, so guess it's the driver synchronising presentation time with master clock time as it passes the data to the device via dma.

makes a hell of a difference - v89 is just amazing. guess I could check which clock it's using, one for another day.

sbgk wrote:there are other instructions to assign a master clock to a pin, so guess it's the driver synchronising presentation time with master clock time as it passes the data to the device via dma.

Right but it must be the mobo clock. I can't see how it could be the master clock from a connected device that's meant - some device don't have clocks & USB connection wouldn't give anything near to 100nS accuracy - it's update cycle is 1mS AFAIK?

makes a hell of a difference - v89 is just amazing. guess I could check which clock it's using, one for another day.

Great to hear this makes such a big difference.

Yea it's more likely to be a mobo CLK
But which one the usb clk the mobo master CLK or the realtime clk
Because their replacement all provide a similar increase in sq
But I never got the three replacements to work simultaneously well not reliably anyhow
I believe jitter in timing has a knock on effect

jkeny wrote:

sbgk wrote:there are other instructions to assign a master clock to a pin, so guess it's the driver synchronising presentation time with master clock time as it passes the data to the device via dma.

Right but it must be the mobo clock. I can't see how it could be the master clock from a connected device that's meant - some device don't have clocks & USB connection wouldn't give anything near to 100nS accuracy - it's update cycle is 1mS AFAIK?

makes a hell of a difference - v89 is just amazing. guess I could check which clock it's using, one for another day.

Great to hear this makes such a big difference.

yes, mobo

read that the default device cycle is 10ms, can be reduced from the driver itself, because the human ear can't hear anything smaller was the reasoning.

most players will use timestamps by querying a clock during the render loop, but we know the buffer size so just need to convert that to time thus avoiding the call to the clock and any inaccuracy from varying clock response time.

sbgk wrote: yes, mobo

read that the default device cycle is 10ms, can be reduced from the driver itself, because the human ear can't hear anything smaller was the reasoning.

wrong reasoning, I reckon, This 10mS timing only applies to how closely two signals arriving at the same ear can be perceived as distinct (I don't even know if 10mS is the lower limit for this?). It fails to recognise that we are dealing with two channel stereo & two ears. We are much more sensitive to timing differences between the signals entering our two ears - the interaural timing difference - the minimum ITD is 4us - 2,500(?) times less than 10mS. Whoever came up with 10mS seems to be short on psychoacoustics knowledge.

most players will use timestamps by querying a clock during the render loop, but we know the buffer size so just need to convert that to time thus avoiding the call to the clock and any inaccuracy from varying clock response time.

So buffers are the way to avoid timing issues then? I was thinking that this couldn't be real-time - mainstream PC & OS architecture is too unreliable for this 100nS I would imagine.

jkeny wrote:

sbgk wrote: yes, mobo

read that the default device cycle is 10ms, can be reduced from the driver itself, because the human ear can't hear anything smaller was the reasoning.

wrong reasoning, I reckon, This 10mS timing only applies to how closely two signals arriving at the same ear can be perceived as distinct (I don't even know if 10mS is the lower limit for this?). It fails to recognise that we are dealing with two channel stereo & two ears. We are much more sensitive to timing differences between the signals entering our two ears - the interaural timing difference - the minimum ITD is 4us - 2,500(?) times less than 10mS. Whoever came up with 10mS seems to be short on psychoacoustics knowledge.

most players will use timestamps by querying a clock during the render loop, but we know the buffer size so just need to convert that to time thus avoiding the call to the clock and any inaccuracy from varying clock response time.

So buffers are the way to avoid timing issues then? I was thinking that this couldn't be real-time - mainstream PC & OS architecture is too unreliable for this 100nS I would imagine.

if you are processing data then multiple buffers can avoid timing issues, otherwise it's just a way of getting the data to the device as one is being filled as the other is playing.

100ns was just the units, 1ms = 10000 100ns, we're using 10ms so something around 100000 * 2

Have you tried lower buffersize yet?

please try buffer = 64. can usb dac handle it?