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
MQN
Re: MQN
I didn't interpret the master clock to mean the DAC's master clock but rather the mobo's master clock.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
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?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
www.Ciunas.biz
For Digital Audio playback that delivers WHERE the performers are on stage but more importantly WHY they are there.
For Digital Audio playback that delivers WHERE the performers are on stage but more importantly WHY they are there.
Re: MQN
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.jkeny wrote:I didn't interpret the master clock to mean the DAC's master clock but rather the mobo's master clock.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
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?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
makes a hell of a difference - v89 is just amazing. guess I could check which clock it's using, one for another day.
Re: MQN
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?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.
Great to hear this makes such a big difference.makes a hell of a difference - v89 is just amazing. guess I could check which clock it's using, one for another day.
www.Ciunas.biz
For Digital Audio playback that delivers WHERE the performers are on stage but more importantly WHY they are there.
For Digital Audio playback that delivers WHERE the performers are on stage but more importantly WHY they are there.
Re: MQN
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
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
sd card player, modded soekris dac, class a lifepo4 amp or gb class a/b amp, diy open baffle speakers based on project audio mundorf trio 10's
Re: MQN
yes, mobojkeny wrote: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?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.
Great to hear this makes such a big difference.makes a hell of a difference - v89 is just amazing. guess I could check which clock it's using, one for another day.
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.
Re: MQN
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.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.
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.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.
www.Ciunas.biz
For Digital Audio playback that delivers WHERE the performers are on stage but more importantly WHY they are there.
For Digital Audio playback that delivers WHERE the performers are on stage but more importantly WHY they are there.
Re: MQN
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.jkeny wrote: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.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.
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.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.
100ns was just the units, 1ms = 10000 100ns, we're using 10ms so something around 100000 * 2
-
- Posts: 2491
- Joined: Mon Oct 07, 2013 11:09 pm
Re: MQN
please try buffer = 64. can usb dac handle it?