The good candidate for an stable freq for ddpd without need for an oven is https://www.digikey.com/en/product-highlight/s/sitime/sit5156-series-super-tcxo . Now only reclocker with precise 50:50 symetry and possibilty to adjust dutty cycle without affecting symetry is need, similar to circuit above. : ) Maybe an stm32 whcih have HRTIMER is possible to achieve this simetry?
Last edited:
Hi Marcel,
Looks like the DSD resampling isn't working at all. I tried with a commercial DSD64 recording. The left channel was just noise, the right channel was noise mixed in with a little repeating audio, this despite the song playback continuing in HQ Player, When I stopped HQ player, the noise continued until I started playback of a PCM file. At that point it started working correctly again.
Kind of sounds like a buffer may be getting caught in a loop, at least based on the repeating audio in the right channel.
Next I will see if I can get DSD passthrough working.
In other news, I have some of the new PCM2DSD v2 boards in production at JLCPCB. When I get them here then I can start assembling a new PCM2DSD which should make it easier to run tests without having to fiddle around as much with the somewhat delicate micro-clips.
Best Regards,
Mark
Last edited:
This is really weird, because there is no FIFO in the path when it processes DSD. Even when it processes PCM, the FIFO is way too short to produce repeating audio.
Is the DSD signal that goes in OK? You could check it with a makeshift low-pass filter.
Is the DSD signal that goes in OK? You could check it with a makeshift low-pass filter.
DSD64 passthrough seems to be having a similar problem. There is looping of "audio followed by a short period of silence." The looping music is of the beginning of the song and is playing in both channels, but no noise in this case. HQ Player continues to advance through the song. Still no noise when I stop HQ Player.
I could try with a different player (up to DSD256). I know that works with PJotr25 FPGA code.
I could try with a different player (up to DSD256). I know that works with PJotr25 FPGA code.
Well, DSD passthrough seems to work okay with PlayPCMWIN. However it only uses WASAPI instead of the ASIO I have HQ player set to use. I need ASIO to get up to DSD512.
Using PlayPCMWIN and WASAPI, DSD remodulation is still noisy with a little distorted audio mixed in. The noise continues after HQ Player is stopped.
While I'm at it, will check to see if the latest I2SoverUSB drive is installed.
While I'm at it, will check to see if the latest I2SoverUSB drive is installed.
I have Marcel's 1p4, there is no problem with playback on HQPlayer DSD64, DSD128 and DSD256 (DSD512 no tested).
Tested in two modes "dsdviasd" (high and low).
When "dsdviasd" was high, sometimes the "iclip" LED lights up, but low level on "scale[0]" work ok 🙂
My MasterClock 22/24MHz goes to I2SoverUSB, pcm2dsd, reclock and as DSD Clock to Marcel's RTZ.
Tested in two modes "dsdviasd" (high and low).
When "dsdviasd" was high, sometimes the "iclip" LED lights up, but low level on "scale[0]" work ok 🙂
My MasterClock 22/24MHz goes to I2SoverUSB, pcm2dsd, reclock and as DSD Clock to Marcel's RTZ.
Can you tell any difference in the sound between Marcel's code and yours?
Also, which I2SoverUSB driver is being used with HQ Player (ASIO or WASAPI)?
@MarcelvdG
So long as PJotr25 finds your FPGA code to work correctly for him, then I will keep working to see what is going on here. In the meantime, it might be worth trying a different upsampling filter. Right now your DSD512 still sounds "soft" which is something people sometimes complain about when it comes to the sound of DSD. OTOH, we think PJotr25 firmware is more realistically dynamic with better separation between instruments. Better sense of depth and soundstage too. Maybe its some simple thing?
Last edited:
In HQPlayer I used ASIO driver.
I have a firmware in I2SoverUSB to support external clocks 22/24.
I have a firmware in I2SoverUSB to support external clocks 22/24.
OK, that sounds like I need to build in some attenuation in the DSD path. With what kind of signal did the "iclip" LED light up? Was it mostly with DSD64? Music or a big sine wave? Default value for "notSevenofNine"?
Last edited:
Yes, it was mostly with DSD64, it was music, but I did not use the recommended attenuation in HQPlayer 3dB then.
With the recommended attenuation it is ok. So for me it's no problem...
"notSevenofNine" default value.
Last edited:
Is it possible to make DCLK x2 of PCM2DSD using NB3N502 as MCLK, then buffer with 74LVG1G14 (Schmitt Trigger) to eliminate jitter!? I saw this application of Schmitt Trigger but not sure the quality it.
@chientechnical ... Hi, if you are talking about first doubling the frequency and then buffering the doubled clock I would use Marcel's NC7*Z86 clock doubler (as shown in the schematic) and then one of the NC7 (tinylogic) buffer ICs. It is not my impression that schmitt triggering - as such - alters the phase noise/jitter figures for worse or for better (others may know more about this than I do, though).
Cheers, Jesper
I started working on trying to see what's making DSD resampling noisy. Decided I could use the Amanero pin header on the dac board for scope test points. Soldered in R1, R2, and R3. Hooked it back up and now DSD resampling is working properly for DSD64. Haven't tried other sample rates yet.
Presumably the added capacitance of the extra dac board traces and pin header socket plugged into the Amanero pin header connector (to access the MUTE and DSD_ON signals), and or the reflections from those traces, changed the timing just enough to get resampled DSD working. Don't know offhand what else it might be. Will have to do some more checking and measuring later.
Presumably the added capacitance of the extra dac board traces and pin header socket plugged into the Amanero pin header connector (to access the MUTE and DSD_ON signals), and or the reflections from those traces, changed the timing just enough to get resampled DSD working. Don't know offhand what else it might be. Will have to do some more checking and measuring later.
On what bit clock edge do the data change and what is the hold time? My FPGA code unfortunately requires 0.8 ns of hold time after the rising bit clock edge, violating the I2S spec by 0.8 ns.
Think I found the problem, or at least the first problem. The reclocker MCLK signal is buffered through a second buffer because I didn't have enough outputs on the Squarer board. That adds enough additional delay when also considering the PLL quadrature tracking delay such that the left channel is just marginal in terms of meeting my reclocker setup and hold times. Could be the left channel is also a little more sensitive on the dac board or something like that, but first thing is to fix the reclocker MCLK extra delay. I have new squaring boards ready to send out to JLCPCB. Will do another iteration later for the squarer to help with Acko oscillator load requirements for better reliability. Up until recently there was not a clear spec on that.
Will check dac input timing again when new squaring board is ready. Reason why is because something still seems a little quirky in that there was only an audible problem when doing DSD resampling. For playing PCM or DSD bypass mode (using WASAPI and a reliable player app), there was no audible timing problem. Only problem (once the player app and possible software driver problems were cleared up) has been with audible noise in DSD resampling mode. Both channels have been affected at times (including with thermal warmup), but the left channel seems more sensitive to timing-problem-related audible noise (what I am calling the left channel, that is; there are two standards for DSD channel mapping as you know; in this case it can be swapped in the USB board with a jumper).
Will check dac input timing again when new squaring board is ready. Reason why is because something still seems a little quirky in that there was only an audible problem when doing DSD resampling. For playing PCM or DSD bypass mode (using WASAPI and a reliable player app), there was no audible timing problem. Only problem (once the player app and possible software driver problems were cleared up) has been with audible noise in DSD resampling mode. Both channels have been affected at times (including with thermal warmup), but the left channel seems more sensitive to timing-problem-related audible noise (what I am calling the left channel, that is; there are two standards for DSD channel mapping as you know; in this case it can be swapped in the USB board with a jumper).
Last edited:
Interesting. If occasionally, and possibly depending on the surrounding bits, PCM bits were not transferred properly, that could be a reason why you didn't like the sound.
@chientechnical: As far as I can see Marcel has attached his latest schematic to post #241. The clock doubler is U28A on p.5 in this schematic.
Regards, Jesper
Regards, Jesper