Click to view our Accessibility Statement or contact us with accessibility-related questions
Showing 1 of 295 conversations about:
GraceDesignLove
24
Nov 14, 2016
bookmark_border
CalebRoberts
56
Nov 20, 2016
bookmark_border
GraceDesignLoveS/PDIF, TOSLINK and AES3/EBU are all decoded by the same receiver - CS8416, There should be no difference in performance unless there are faulty cables. Except - TOSLINK doesn't always work correctly at FS > 96kHz. Typically optical transmitters are not capable of the bandwidth necessary for S/PDIF at 176.4 or 192kHz. The m920's S/PDIF and TOSLINK inputs are both galvanically isolated but TOSLINK is vulnerable to contamination at the lenses of the transducers (hence the little windows that help keep dirt out). Not all TOSLINK cables are of adequate quality to do the job. It seems that they are all vulnerable to damage from bending, kinking.
Many consumer grade sources (often with TOSLINK output) have very high jitter, usually because they do not use a proper oscillator. They are often quantized signals with edge-rate jitter amplitude of the period of a computer system oscillator (for example 25, 50 or 100MHz). Some of the early devices (I think it was commonly early Apple TV) generate S/PDIF sample rate outside the lock range of even some of the most capable VCXOs.
Some sources (or very long cables) may have very high jitter but the CS8416 has very high jitter rejection. Additionally, the m920's clock recovery is a 3-stage PLL and so jitter is entirely rejected once it reaches the DAC.
The ESS DAC's built-in S/PDIF receiver has some built-in limitations but it is also not compatible with this implementation. In the m920, the ESS DAC is operated in synchronous clocking mode. The ESS DAC's S/PDIF receiver can only operate if the DAC is operating in Asynchronous Sample Rate Conversion mode. We considered it to be most advantageous not to subject the digital audio stream to ASRC.
Theoretically, the USB interface wold have the cleanest clock because it is not synchronizing to an external source. The fixed internal oscillators determine the rate at which data is transmitted from the host computer. But, our clock recover system is so effective a rejecting jitter, we feel that there is no effective difference. Also, USB enables plaback of 32-bit PCM. But, I don't think a double-blind test would reveal that listeners can reliably demonstrate a preference for a 32 bit source over the same source properly quantized to 24-bit. Connecting your audio device to a computer with a 480MHz serial communication link would seem to be inviting noise into the system. We have taken great care to isolate the USB interface from the audio circuit and to reject the associated digital noise as effectively as possible. The USB interface is a separate PCB that is completely galvanically isolated from the chassis and the main PCB. We use some very expensive high speed isolation buffers for the digital audio signals from the USB interface. This is a very uncommon feature inUSB audio products.
Many consumer grade sources (often with TOSLINK output) have very high jitter, usually because they do not use a proper oscillator. They are often quantized signals with edge-rate jitter amplitude of the period of a computer system oscillator (for example 25, 50 or 100MHz). Some of the early devices (I think it was commonly early Apple TV) generate S/PDIF sample rate outside the lock range of even some of the most capable VCXOs.
Some sources (or very long cables) may have very high jitter but the CS8416 has very high jitter rejection. Additionally, the m920's clock recovery is a 3-stage PLL and so jitter is entirely rejected once it reaches the DAC.
The ESS DAC's built-in S/PDIF receiver has some built-in limitations but it is also not compatible with this implementation. In the m920, the ESS DAC is operated in synchronous clocking mode. The ESS DAC's S/PDIF receiver can only operate if the DAC is operating in Asynchronous Sample Rate Conversion mode. We considered it to be most advantageous not to subject the digital audio stream to ASRC.
Theoretically, the USB interface wold have the cleanest clock because it is not synchronizing to an external source. The fixed internal oscillators determine the rate at which data is transmitted from the host computer. But, our clock recover system is so effective a rejecting jitter, we feel that there is no effective difference. Also, USB enables plaback of 32-bit PCM. But, I don't think a double-blind test would reveal that listeners can reliably demonstrate a preference for a 32 bit source over the same source properly quantized to 24-bit. Connecting your audio device to a computer with a 480MHz serial communication link would seem to be inviting noise into the system. We have taken great care to isolate the USB interface from the audio circuit and to reject the associated digital noise as effectively as possible. The USB interface is a separate PCB that is completely galvanically isolated from the chassis and the main PCB. We use some very expensive high speed isolation buffers for the digital audio signals from the USB interface. This is a very uncommon feature inUSB audio products.
GraceDesignLove
24
Nov 21, 2016
bookmark_border
CalebRobertsThank you very much for your detailed answer.
Are you an engineer at Grace Design?
The path of the digital input of m920 is shown in the block diagram, S/PDIF, TOSLINK and AES3 /EBU on user manual, I knew that they were all entered on the same route.
Still sounds are slightly better for S/PDIF. Perhaps as you say, it will be a cable quality problem.
I also knew that the m920 digital input, including the USB, can almost rejection jitter and reclocking by "great" s-lock™, I know that USB is a newly designed m920, ground isolated.
But still S/PDIF is better than USB.
Well, especially in S/PDIF the higher tone elongation is better, USB sounds a little jammed.
I do not worry about jitter, but maybe the noise from the transport is superimposed on the USB communication data or usb bus power signal?
The path of the digital input of m920 is shown in the block diagram, S/PDIF, TOSLINK and AES3 /EBU on user manual, I knew that they were all entered on the same route.
Still sounds are slightly better for S/PDIF. Perhaps as you say, it will be a cable quality problem.
I also knew that the m920 digital input, including the USB, can almost rejection jitter and reclocking by "great" s-lock™, I know that USB is a newly designed m920, ground isolated.
But still S/PDIF is better than USB.
Well, especially in S/PDIF the higher tone elongation is better, USB sounds a little jammed.
I do not worry about jitter, but maybe the noise from the transport is superimposed on the USB communication data or usb bus power signal?
CalebRoberts
56
Nov 21, 2016
bookmark_border
GraceDesignLovePerhaps there's a configuration problem with your playback software or operating system. You want to make sure that there is no sample rate conversion or signal processing enabled, especially the system ASRC and mixer. Not knowing your system, I couldn't direct you on how to do this. But if you use Windows, the easiest is to use the ASIO driver. If you have trouble finding info on this then I suggest you contact Alex (Grace service dept.). He is familiar with many of the OS and various media player application configuration settings.
GraceDesignLove
24
Nov 21, 2016
bookmark_border
CalebRobertsThanks for the advice.
Since I am a programmer at all, I understand roughly about OS.
Among the m920 digital inputs, S/PDIF is experimenting with the WASAPI(exclusive mode) driver provided by the transport motherboard manufacturer (ASUS). For USB input, i am trying WASAPI (exclusive mode) and ASIO from the latest Class 2 driver as well. Both should be bit perfect.
With the USB driver, ASIO feels slightly better than WASAPI, KernelStreaming sounds a little high, treble is too strong.
The impression that S/PDIF is good is unchanged, but the USB sound of the m920 is also quite good, I think it is the best I've heard before. Especially, I think S/PDIF sounds different in dimension as a $ 2000 class headphone DAC/AMP.
Among the m920 digital inputs, S/PDIF is experimenting with the WASAPI(exclusive mode) driver provided by the transport motherboard manufacturer (ASUS). For USB input, i am trying WASAPI (exclusive mode) and ASIO from the latest Class 2 driver as well. Both should be bit perfect.
With the USB driver, ASIO feels slightly better than WASAPI, KernelStreaming sounds a little high, treble is too strong.
The impression that S/PDIF is good is unchanged, but the USB sound of the m920 is also quite good, I think it is the best I've heard before. Especially, I think S/PDIF sounds different in dimension as a $ 2000 class headphone DAC/AMP.
Related Products
Drop Refurbished
Like-new products you can trustDrop Rewards
Get $5 for every 500 points you earn! Learn more
Drop Keyboard Club
Become a member and expand your keycap collectionCollaborate With Us
For Brands & DesignersFollow Drop
By the way, it is a digital input of m920 in order of best sound.
S/PDIF >>>> USB >> TOSLINK (AES/EBU had no equipment to try.)
I think that the sound from S/PDIF is the best and the next point is USB, but how about everyone? I wonder why S/PDIF decoder of ES9018K2M sounds really good.