Core Infinity listening impressions and comparisons

[KIBM]

Forgot to add that I also tried out the UPNP feature. To get as short a path as possible I used QPlayer to pipe files from my QNAP NAS. Unfortunately I did not get as good a result as Inox. Everything worked well first time but after a few tracks it was clear that fidelity was significantly lower to that I described above with Air and Roon in either wifi or ethernet mode. It just sounded small, less dynamic and a bit thin. It may be that more sophisticated players can give better results. They always sounded good with previous incarnations of Air but crashed far to often in my hands to be tolerable. 

I could dig out my Krell Connect streamer to try with UPNP but that involves another box, power, ethernet and spdif cables, Twonkey and Krell's woeful Connect player software. After Roon/Air I just don't have the stomach for this route!

Regards

Kevin

[Confused]

Yes, I got confirmation that all sources get their clock (improved) from the CI board, therefore improvement in applicable for every entry, not only to the Air/Streaming.

Jean-Marie

This would appear to be consistent with the information @Celts88 posted a while back.  To be honest, I am not sure if this is good news.  Consider that the reason devices like the Mutec MC3+USB and Mutec REF10 can deliver such good results is because the AES/EBU input is a synchronous input, so it derives it's clock from the source feed.  However, if the AES/EBU input is now deriving it's clock from the CI board then it is effectively configured as an asynchronous input, thus removing the potential for 'super clock' devices like the Mutec REF10 to deliver the clock signal.

[f1eng]

Yes, I got confirmation that all sources get their clock (improved) from the CI board, therefore improvement in applicable for every entry, not only to the Air/Streaming.

Jean-Marie

This would appear to be consistent with the information @Celts88 posted a while back.  To be honest, I am not sure if this is good news.  Consider that the reason devices like the Mutec MC3+USB and Mutec REF10 can deliver such good results is because the AES/EBU input is a synchronous input, so it derives it's clock from the source feed.  However, if the AES/EBU input is now deriving it's clock from the CI board then it is effectively configured as an asynchronous input, thus removing the potential for 'super clock' devices like the Mutec REF10 to deliver the clock signal.

Strange though, how could that work?
Surely the SPDIF and AES/EBU input have to be clocked by the source to maintain long term synchronisation. Trying to use 2 slightly different clocks was a source of early AIR dropout problems iirc.
Since there is no mechanism to send timing data back from the Devialet clock to the supplying source in the AES/EBU standard (or any way for the source to synchronise thus anyway) I think there much have been some misunderstanding somewhere.

[Jean-Marie]

Yes, I got confirmation that all sources get their clock (improved) from the CI board, therefore improvement in applicable for every entry, not only to the Air/Streaming.

Jean-Marie

This would appear to be consistent with the information @Celts88 posted a while back.  To be honest, I am not sure if this is good news.  Consider that the reason devices like the Mutec MC3+USB and Mutec REF10 can deliver such good results is because the AES/EBU input is a synchronous input, so it derives it's clock from the source feed.  However, if the AES/EBU input is now deriving it's clock from the CI board then it is effectively configured as an asynchronous input, thus removing the potential for 'super clock' devices like the Mutec REF10 to deliver the clock signal.

Yes, I got confirmation that all sources get their clock (improved) from the CI board, therefore improvement in applicable for every entry, not only to the Air/Streaming.

Jean-Marie

This would appear to be consistent with the information @Celts88 posted a while back.  To be honest, I am not sure if this is good news.  Consider that the reason devices like the Mutec MC3+USB and Mutec REF10 can deliver such good results is because the AES/EBU input is a synchronous input, so it derives it's clock from the source feed.  However, if the AES/EBU input is now deriving it's clock from the CI board then it is effectively configured as an asynchronous input, thus removing the potential for 'super clock' devices like the Mutec REF10 to deliver the clock signal.

Strange though, how could that work?
Surely the SPDIF and AES/EBU input have to be clocked by the source to maintain long term synchronisation. Trying to use 2 slightly different clocks was a source of early AIR dropout problems iirc.
Since there is no mechanism to send timing data back from the Devialet clock to the supplying source in the AES/EBU standard (or any way for the source to synchronise thus anyway) I think there much have been some misunderstanding somewhere.

I’m not a hardware designer, so I did not enter in any details. I would assume that for synchronous entries they may be driving the internal clock of the Devialet, which would be equally true for the new clock on the CI. If the clock on the CI is better than the previous one it is not too far fetch to think that the locking from synchronous sources has been improved too. 

Jean-Marie

[thumb5]

The AES/EBU (and S/P-DIF) inputs use Manchester coding, meaning that a single input signal carries both data and clock information from the source.  The input circuitry on the Devialet has to "recover" the clock from the input and use the recovered clock to extract the data (audio bits). The clock is usually recovered from the input by using a phase-locked loop (PLL) based on a reference clock internal to the Devialet.  The quality of the clock recovered by the Devialet will depend to some degree on both the quality of the input, which in turn depends on the source's clock, and the quality of its own reference clock.

So I'd interpret the information that "all sources get their clock from the CI board" to mean that the PLL's reference clock now comes from the CI, which might mean it is a higher-quality reference than in the non-CI case.  This could result in a more stable/accurate recovered clock, and wouldn't necessarily negate the value of a well-clocked source such as a Mutec.  That would be my thinking based on first principles - what it sounds like in practice is of course another matter entirely

[Jean-Marie]

The AES/EBU (and S/P-DIF) inputs use Manchester coding, meaning that a single input signal carries both data and clock information from the source.  The input circuitry on the Devialet has to "recover" the clock from the input and use the recovered clock to extract the data (audio bits). The clock is usually recovered from the input by using a phase-locked loop (PLL) based on a reference clock internal to the Devialet.  The quality of the clock recovered by the Devialet will depend to some degree on both the quality of the input, which in turn depends on the source's clock, and the quality of its own reference clock.

So I'd interpret the information that "all sources get their clock from the CI board" to mean that the PLL's reference clock now comes from the CI, which might mean it is a higher-quality reference than in the non-CI case.  This could result in a more stable/accurate recovered clock, and wouldn't necessarily negate the value of a well-clocked source such as a Mutec.  That would be my thinking based on first principles - what it sounds like in practice is of course another matter entirely

Yes, you are probably more correct than my over simplification.

Jean-Marie

[Confused]

Yes, I got confirmation that all sources get their clock (improved) from the CI board, therefore improvement in applicable for every entry, not only to the Air/Streaming.

Jean-Marie

This would appear to be consistent with the information @Celts88 posted a while back.  To be honest, I am not sure if this is good news.  Consider that the reason devices like the Mutec MC3+USB and Mutec REF10 can deliver such good results is because the AES/EBU input is a synchronous input, so it derives it's clock from the source feed.  However, if the AES/EBU input is now deriving it's clock from the CI board then it is effectively configured as an asynchronous input, thus removing the potential for 'super clock' devices like the Mutec REF10 to deliver the clock signal.

Strange though, how could that work?
Surely the SPDIF and AES/EBU input have to be clocked by the source to maintain long term synchronisation. Trying to use 2 slightly different clocks was a source of early AIR dropout problems iirc.
Since there is no mechanism to send timing data back from the Devialet clock to the supplying source in the AES/EBU standard (or any way for the source to synchronise thus anyway) I think there much have been some misunderstanding somewhere.

There was much discussion regarding this topic on Computer Audiophile.  John Swenson made an interesting comment stating that there are different mechanisms for recovering the AES clock from the feed, these vary from DAC to DAC. This is John Swenton's description of how a Mutec MC3+USB functions:

Both USB and S/PDIF inputs have their own clocks which run their respective chips. The outputs from these fill a FIFO in the FPGA, clocked by their own clocks. The samples are read from the FIFO using the output of the synthesizer.  The FPGA reads information from the receiver and sets the synthesizer to the correct frequency for the sample rate being received. The FPGA keeps track of the FIFO, if it is getting too full or too empty it changes the output frequency of the synthesizer by a tiny amount to keep the FIFO around half full. This means that the overall average sample rate is controlled by the input source, the quality of the clock generating the output stream is determined by the reference to the synthesizer. Thus a better reference (such as the Ref10) will lower the phase noise of the output data.

In a later post, John made this specific point regarding Devialet: 

The circuitry used to generate clocking in a DAC from a S/PDIF (AES3 etc) feed vary radically from DAC to DAC. There are many different ways to do it and they all have very different "clock transfer functions", how the quality of the input signal affects the clock feeding the DAC chip. I have no idea how the Devialet does it so I can't come up with even a speculation as to what that transfer function might be.

So in conclusion, yes you must be correct, there is no mechanism to send timing data back from the Devialet clock to the supplying source in the AES/EBU standard.  However, exactly what the Devialet does with the AES feed remains unclear, to those of us outside of Devialet at least.

Link to the CA thread:

https://www.computeraudiophile.com/forum...ck/?page=7

This is going a little off topic here, but does have some relevance to the subjective observations from some that the S/PDIF / AES inputs have improved performance following the CI upgrade.  I know a few people have delayed the CI board update to the new year, hopefully we will get a few more reports and insight over the coming months.

[GuillaumeB]

Hi guys just spent the afternoon with Rufus comparing Roon/AIR to my Totaldac d1 server (which is also Roon Ready) feeding my Od'A.

The test track was "Ricky the Lobster" on Mo' Blow's "Live in Berlin". Amazing album by the way. German Jazz funk played live in a club. Wonderful recording with exceptional musicians all interacting and feeding off one another and the audience cheering them on. Bass, drums, electric piano and saxophone. You literally feel as though you are there, almost front seat stuff! Come to think about it standing is far more likely, with a bottle of beer in one hand of course! 

This was the first time Rufus had heard Roon/Air with the new CI board so I was keen to get his impressions.

Anyway due to how things were set up we started with the Totaldac feeding my Od'A. Rufus seemed very impressed and clearly liked what he was hearing. Like I said it's brilliant live music.

Then we switched to Roon/Air, which only took me a few seconds literally pulling the ethernet cable out of the d1 server and connecting it to the master, then changing input and then adjusting the volume so that it stayed the same. Roon seemed to behave itself with these changes which was nice. 

Instantly there was a change in the presentation but it took a while to sink in. We finished the track then went back to the Totaldac and repeated the process.

Then we started discussing what we were hearing. I think it's fair to say we were experiencing similar things. The Totaldac was clearly better offering a much more engaging experience with instruments sounding more natural (less forced?) and the music being easier to follow particularly in busy moments. I particularly focussed on the piano. With Roon/Air it seemed to stab at me with the attack dominating, at times a little strident. The Totaldac seemed to offer more sustain and release, it was a more textured and musical sound. And quite a bit easier to follow, particularly when the other musicians were joining in. Basically more enjoyable. I seem to recall Rufus saying that he felt there was more air around instruments.

I'll let Rufus interject if he fancies it though. 

Guillaume

[Rufus McDufus]

Yes, this was an interesting test. With the Roon/AIR setup I was immedialtey quite impressed (as impressed as with the Totaldac option) but there were differences. The tracks played are quite forward, and straight away I felt the Roon/AIR setup perhaps had a tiny bit more depth to them, but over time it seemed a little murkier and just a bit harder to follow. The Totaldac d1-server setup seemed pretty supreme with these tracks and just sounded 'right' from the get-go.

[disarmamant]

Hi guys just spent the afternoon with Rufus comparing Roon/AIR to my Totaldac d1 server.

Could you clarify how the Totaldac was feeding the Devialet please?

Digital or analog out from the Totaldac?



Sent from my iPad using Tapatalk