Denafrips DACs might not actually be NOS?

[GoldenOne]

4 minutes ago, idiot_savant said:

My concern here is that latency growing over time is actually a sign of a lack of a PLL… be interesting to see if there is an upper limit. Oh, one other thing to check - with a 1kHz tone, does the AP measure it as 1kHz?

 

 

 

your friendly neighbourhood idiot 

Yep it is measuring as 1.0000khz so no issue there.

Short video of the delay thing here: https://streamable.com/vnz7j8

When the device is initially connected the delay is seemingly random. I've seen as low as 4ms and as high as 190ms.
I've got it at 155.6ms right now and am just going to leave it plugged in for the rest of the day to see what happens

 

[idiot_savant]

OK, so I think we could have 2 issues here, which we should try to separate:

 

Issue 1 : seemingly quite a big variation in latency between inputs changing or going away. 

Issue 2 : latency seeming to increase over time. 
 

issue 1 is not great and will irritate people trying to watch video, but apart from that, nothing to see

 

issue 2 is more problematic in terms of what’s going on - *how* is the latency increasing? At what rate? Is  there a maximum and minimum?

 

so, if you could just leave it running the continuous sweep doohickey and look at latency every say 15 minutes, we should be able to work out the rate latency is increasing, and if there is a maximum

 

 

your friendly neighbourhood idiot 

[GoldenOne]

1 minute ago, idiot_savant said:

OK, so I think we could have 2 issues here, which we should try to separate:

 

Issue 1 : seemingly quite a big variation in latency between inputs changing or going away. 

Issue 2 : latency seeming to increase over time. 
 

issue 1 is not great and will irritate people trying to watch video, but apart from that, nothing to see

 

issue 2 is more problematic in terms of what’s going on - *how* is the latency increasing? At what rate? Is  there a maximum and minimum?

 

so, if you could just leave it running the continuous sweep doohickey and look at latency every say 15 minutes, we should be able to work out the rate latency is increasing, and if there is a maximum

 

 

your friendly neighbourhood idiot 

So with #2, it seems that it's not always increasing.
In fact this run I started at about 156ms, and it has slowly decreased to 153ms over a few hrs.

So it seems that it changes one way or the other but isn't always increasing.

[idiot_savant]

Hmmm, interesting - can you offset the AP sample rate? If you can, add an offset of 10ppm ( or 44100.441Hz ) and see what happens?

 

thanks for looking into this!

 

 

your friendly neighbourhood idiot 

[GoldenOne]

1 hour ago, idiot_savant said:

Hmmm, interesting - can you offset the AP sample rate? If you can, add an offset of 10ppm ( or 44100.441Hz ) and see what happens?

 

thanks for looking into this!

 

 

your friendly neighbourhood idiot 

Can't offset to that level of precision, it auto-corrected to 44.1004khz
But in doing so that made the delay increase quite rapidly as shown here. Just taking measurements every couple secs:

https://streamable.com/k07tso

 

[idiot_savant]

That level of precision is plenty good enough, thanks! I should probably reiterate this *might* be OK in audio terms ( I think the video use case has been ruled out either way ) - but does the latency saturate ( i.e. get to a number of milliseconds ), wrap round ( i.e. jump back to a low number ), continue increasing forever or start  reducing?

 

All interesting stuff, and thanks again!

 

 

your friendly neighbourhood idiot 

[idiot_savant]

Poking about AP website:

 

https://www.ap.com/technical-library/continuously-repeating-apx-measurements/

 

 

your friendly neighbourhood idiot 

[davide256]

21 hours ago, GoldenOne said:

So with #2, it seems that it's not always increasing.
In fact this run I started at about 156ms, and it has slowly decreased to 153ms over a few hrs.

So it seems that it changes one way or the other but isn't always increasing.

I've been told that DAVE does liner interpolation before final D/A conversion. Any Chord DAC's in house to do a delay comparison with?

[GoldenOne]

19 minutes ago, davide256 said:

I've been told that DAVE does liner interpolation before final D/A conversion. Any Chord DAC's in house to do a delay comparison with?

Linear interpolation isn't what's causing the delay. The oversampling filter is a different thing.

I have a chord mojo here atm though, that gets 25ms delay on SPDIF

[davide256]

25 minutes ago, GoldenOne said:

Linear interpolation isn't what's causing the delay. The oversampling filter is a different thing.

I have a chord mojo here atm though, that gets 25ms delay on SPDIF

So linear interpolation may be causing ~ 20 ms of delay + another piece is adding variable delay, some kind of predictive algorithm added processing?

[idiot_savant]

Hi,

 

linear interpolation doesn’t add *any* delay - in the Chord, it will be the FIR filtering adding the delay. In a NOS DAC, what processing is going on?

 

It *looks* like a FIFO, which is why we’re trying to look at what’s going on. A FIFO is generally a good thing, but adds delay, so the question is why so much delay, and so variable?

 

 

your friendly neighbourhood idiot 

[semente]

11 minutes ago, idiot_savant said:

Hi,

 

linear interpolation doesn’t add *any* delay - in the Chord, it will be the FIR filtering adding the delay. In a NOS DAC, what processing is going on?

 

It *looks* like a FIFO, which is why we’re trying to look at what’s going on. A FIFO is generally a good thing, but adds delay, so the question is why so much delay, and so variable?

 

 

your friendly neighbourhood idiot 

Is theFIFO used as buffer before reclocking?

[idiot_savant]

@semente - so here we go-FIFO means First In First Out. It is a buffer, but with particular properties. 
 

At the basic level, a FIFO has something that writes into it ( let’s say an SPDIF receiver, “I’ve got a sample” ) and something that reads from it ( let’s say a DAC , “I need a sample” )

 

So the idea of it is if say your thing *writing* varies in time a bit, the FIFO takes up the slack so the thing reading never notices - so it takes care of short term timing variations. 
 

our designer has to work out how much variation there is likely to be against how much delay can be tolerated. 
 

So, there also clearly has to be a mechanism that ensures the reads and writes are matched - if the reads are consistently slower than the writes, for example, the FIFO will fill up, and vice versa the FIFO will empty itself. 
 

So in this case we can’t currently see this mechanism being activated ( the FIFO is filling, therefore the latency increases ). That’s not to say there isn’t one, just that this design may allow substantial latency. 
 

your friendly neighbourhood idiot 

[idiot_savant]

To put it another way, and this is the classic analogy:

You’ve got a bucket with a hole in it - you pour water in, some time later water comes out. If you put your hose filling the bucket at its maximum, the bucket starts to fill, and the water on the top will take longer to get through ( because of all the water already in the bucket ). Stop the hose, and the bucket will empty. 
 

your friendly neighbourhood idiot 

[MarkusBarkus]

...and if the hose flow rate grossly exceeds the output flow, and the "extra capacity" of the bucket, is that buffer over-flow? 

And for the record, my bucket has no hole. Not even a War-hole, thank you very much...

[idiot_savant]

As much as I find the bucket analogy painful, yes - if you put in way too much stuff, it overflows, that water is lost down the side. 
 

If your bucket/FIFO has no hole, it will certainly be quiet…

 

your friendly neighbourhood idiot 

[idiot_savant]

@GoldenOne - I don't suppose you ever found a limit on this?

 

 

 

 

 

your friendly neighbourhood idiot

[GoldenOne]

I've posted a full review here: 

 

[idiot_savant]

Nice review…

 

for the slow filter impulse, what happens if you reduce the gain going in a bit? i.e. less than full scale? Looks like it’s wrapping round…

 

 

 

your friendly neighbourhood idiot 

[Axiom05]

I think you mean 16x oversampling not 32X. 16 X 44.1 = 705.6

[GoldenOne]

1 minute ago, Axiom05 said:

I think you mean 16x oversampling not 32X. 16 X 44.1 = 705.6

Yep, whoops XD 

[tuna56]

Thanks for an excellent review.

 

My question about the NOS issue, since Denafrips /Musician DAC's all now use the new Thesycon U-HEAR USB receivers, could the NOS issue be with the Thesycon hardware/firmware? I notice they have released ver5.12 and Denafrips has that version now. Or, is this a quirk down the line with their DAC processing?

 

Also, did the original Ares, which used the X-MOS I believe, also have the NOS issue?

[GoldenOne]

5 minutes ago, tuna56 said:

Thanks for an excellent review.

 

My question about the NOS issue, since Denafrips /Musician DAC's all now use the new Thesycon U-HEAR USB receivers, could the NOS issue be with the Thesycon hardware/firmware? I notice they have released ver5.12 and Denafrips has that version now. Or, is this a quirk down the line with their DAC processing?

 

Also, did the original Ares, which used the X-MOS I believe, also have the NOS issue?

I can't say unfortunately as I've not tested others. Would like to try musician though. 

 

I don't think it'd make any sense for the issue to be related to the USB chip. The upsampling is done later down the line

[mitch751]

excellent review .. thank you

 

[GregWormald]

What I find interesting is that most 'just listening' reviews prefer the 'NOS' or 'slow filter' settings despite their oddities.