Actually, as you suspected, there was something which was not properly setted in foobar, or better in the DSD Transcoder module. Now, playing DSD64, Xmos asio driver shows a bitrate of 2.822.400 Hz (while it before showed 176400 Hz) and upsampling by DSD Processor to DSD128, it correctly shows 5.644.800 Hz (before 352800). And now the weird thing: when I upsample to DSD256 or more simply play a DSD256 test file, I clearly hear a noise, something between a whistle and a buzz, which is completely absent on DSD64 or 128 playing. For first I thought it could be an issue somehow related to the Transcoder work. So I tried Jriver, but I get exactly the same result: I heard the music plus the noise. Has someone of you an idea of the reason to this? Obviously it's not that important, because I will not use this playing mode, but it's only for curiosity, because I can't give an explanation.
Thank you,
Gaetano.
I've aquired an old SAR ADC evaluation board to try out.
It uses a 16.9344 MHz crystal oscilllator. Can you recommend a low jitter/low phase noise (ideally drop in) replacement? Thanks!
There is someone who has bought a bunch of SC-Cut 3rd overtone crystals at 16.9344 MHz but I don't remember precisely.
Please, post an inquiry on the dedicated thread
The Well Tempered Master Clock - Building a low phase noise/jitter crystal oscillator
Please, post an inquiry on the dedicated thread
The Well Tempered Master Clock - Building a low phase noise/jitter crystal oscillator
Soeren, is there a way (or would it be possible to impliment this) to use the S/PDIF TTL input of the DAM1021 to receive signal while providing (externally synchronized) clocking via an I2S bitclock signal?
The reason for this is that I can provide much better quality clocking locally, whereas the clock imbedded in the AES/EBU signal going into the DAM1021 has made a round trip and been reclocked by an inferior PLL.
I know clocking is not supposed to make a difference in the DAM1021, but my experiments (and many others) have shown it actually does.
The reason for this is that I can provide much better quality clocking locally, whereas the clock imbedded in the AES/EBU signal going into the DAM1021 has made a round trip and been reclocked by an inferior PLL.
I know clocking is not supposed to make a difference in the DAM1021, but my experiments (and many others) have shown it actually does.
So you have feed the shift registers a clock directly and compared in a ABX test ??
In theory, anything is possible with the FPGA controling things. But in practice, NO, I don't want to write the code for a special case that I don't see any need for, can't test it, and I don't want to maintain it, already have too many pieces of code to maintain.
And anyway, the clock on the dam1021 also goes though the FPGA.... When I update the dam1021, it will use the same clocking as all the other dams and dacs....
I went through a variety of clocking scenarios and hardware input circuitry changes and they all resulted in audible differences. I also own pro audio ADC converters I use as a master clock (to also clock the DAM1021), which allow me to make minute changes to the clock frequency. From my tests I don't think it's the frequency so much as it is the jitter (spectrum) of the signal.
For instance, adding RF filtering caps to the AES/EBU lines preceding the RS-422 receiver results in reproducible, clearly audible changes. The green LED never waivers and there are no dropouts, so the signal arriving at the DAM1021 can be assumed to be bit perfect. The caps don't affect the overall clock frequency. Yet the differences introduced by the caps to the digital signal are present after ther FPGA (since they are audible), it doesn't (fully) eliminate them.
Just in one of my tests I've added and remobed the caps serveral times while the devices were running, the differences are clearly audible and predictable.
I understand you not wanting to add functunality for special cases like mine.
I'm looking forward to the update you pronounced.
Last edited:
I've made some tests with different power supply voltages.
I use a heavily filtered and regulated PSU. I had it working at +/-7 V DC before to minimally task the DAM1021's on-board regulators. However, increasing the voltage actually resulted in better sound.
The OPA1602 on the balanced outputs' supply voltages scale wrt to the board's supply voltage, so they don't seem to be behind on-board linear regulators. What is going on here?
Anyway, I've looked for a voltage that results in the on-board regulators not markedly heating up and settled on a little under +/-10V DC. According to the OPA1602's datasheet performance ist not supposed to be affected by differences in supply voltage (within the specs and the needed output voltage). Maybe the output regulators that feed the actual DAC circuit can react a little better to load changes? It does sound better, more dynamic, a little more eaven, better details.
I use a heavily filtered and regulated PSU. I had it working at +/-7 V DC before to minimally task the DAM1021's on-board regulators. However, increasing the voltage actually resulted in better sound.
The OPA1602 on the balanced outputs' supply voltages scale wrt to the board's supply voltage, so they don't seem to be behind on-board linear regulators. What is going on here?
Anyway, I've looked for a voltage that results in the on-board regulators not markedly heating up and settled on a little under +/-10V DC. According to the OPA1602's datasheet performance ist not supposed to be affected by differences in supply voltage (within the specs and the needed output voltage). Maybe the output regulators that feed the actual DAC circuit can react a little better to load changes? It does sound better, more dynamic, a little more eaven, better details.
Last edited:
And why shouldn't they be? Similarly, if you feed the dac from a galvanically isolated and reclocked usb source, all upstream components are plainly audible: usb cables, ports, OS, etc. It is not the dac or fifo's fault, we just lack some basic understanding of what exactly is going on.