My understanding is that the Huron upsamples to DSD x20 > down coverts to DSDx4 > converts D/A. I have two questions:
Will the DSDAC support DSD 11.2MHz native file in the future?
I love DSD but the biggest drawback is the inherent click noise between tracks. Is it possible to elliminate this completely? The only software which eliminates this DSD noise is Korg’s audiogate, but it doesn’t support Gapless playback.
Tak said
1. Will the DSDAC support DSD 11.2MHz native file in the future?
I love DSD but the biggest drawback is the inherent click noise between tracks. Is it possible to elliminate this completely? The only software which eliminates this DSD noise is Korg’s audiogate, but it doesn’t support Gapless playback.
Maybe - Huron did most of the work to support quad rate DSD in the FPGA, but getting USB and I2S to support it will take some work.
I’m not sure what you are referring to. I play DSD gaplessly all of the time via USB, S/PDIF, TOSLink, AES/EBU. I2S also supports it but I don’t have an I2S source that will play DSD gaplessly. There are broken utilities that some use to split, say, .iso files into individual tracks, but there’s no reason to not do it right. There are some players that do better than others at keeping DSD gapless, it’s harder to do it with streamers over DoP, or to use DoP on individual files, but that can be supported if the splitter you are using only splits on multiples of 16 samples.
I play DSD with Jplay (sometimes with foobar for evaluation purpose, both support gapless playback) via SU-1 > I2S > DS DAC (w/o network, no streamers). The DSD click noise is present regardless of the software being gapless. For example, in DSD(SACD) files such as live album, Pink Floyd’s Dark Side of the moon etc. you can hear click noise between continuous tracks (Pretty audible and annoying with a pair of professional Headphones). There is no issue with WAV, just DSD files.
There must be some noise present in DSD tracks, usually in the beginning of each track, and it is not due to the hardware, as I heard this noise with my previous setup as well (foobar > Mytek Manhattan). I wonder, if SACD played through the new PSA Memory player solves this issue…
Playing my DSOTM .iso file with foobar2000 via USB is gapless here, also I have some albums comprising separate .dsf tracks that (like DSOTM) don’t fade out between tracks so any clicks should be obvious. They play fine too.
The thing is that the DAC doesn’t know a track from a hole in the wall so any clicks have to be caused by some discontinuity upstream. Huron got rid of some clicks on, say, PCM -> DSD or DSD -> PCM transitions in some circumstances (and unfortunately, added some in others). But DSD/DSD can be seamless if the player is applying DoP AFTER it strings the tracks together seamlessly. I changed the software in the DS to not drop out of DoP mode if few DoP flags were wrong so that file that are separately DoP’ed (and had a multiple of 16 samples) would work fine just slammed back to back.
I suspect that your source files are the source of the problem if your player is indeed playing the original DSD bits gaplessly. (I don’t have any experience with Jplay, but I don’t know why it wouldn’t do this right.)
Tak said
1. Will the DSDAC support DSD 11.2MHz native file in the future?
"
Maybe - Huron did most of the work to support quad rate DSD in the FPGA, but getting USB and I2S to support it will take some work.
Ted, can the improvements to USB and/or I2S be implemented via firmware only? Or would it require more significant changes? In other words, could this be implemented in the existing DS or would it require a MkII?
pmotz said
Ted, can the improvements to USB and/or I2S be implemented via firmware only? Or would it require more significant changes? In other words, could this be implemented in the existing DS or would it require a MkII?
Software. The HDMI I2S has the bandwidth for doubling it's frequency. For USB there are multiple possible implementations, for example there's a spare wire that could be used so that twice the I2S data comes at the same rate (not really I2S anymore, but since the source and destination are both software configured that's not an issue.) The bigger issue is that it might require new USB drivers for the PC end - we'd have to get more into the details to know for sure.
I love DSD but the biggest drawback is the inherent click noise between tracks. Is it possible to elliminate this completely? The only software which eliminates this DSD noise is Korg’s audiogate, but it doesn’t support Gapless playback.
Ted Smith said
I2S also supports it but I don’t have an I2S source that will play DSD gaplessly.
Gapless DSD-playback here (tested with Schiller's Leben and Kraftwerk) without any clicks between the tracks (.dsf files extracted from ISO) no matter if via the Bridge II (and Roon) or via my "I2S-streamer" (pls have a look at my signature) with the piCorePlayer installed (and Squeezelite). I only have slight clicks when the format is changing from PCM to DSD and back.
Btw, the Holo Audio Spring DAC does accept DSD512 (native) via its HDMI/I2S-input (PS Audio compatible). Maybe Ted could make the I2S-input DSD256-ready at first? They tell good things about the Singxer SU-1 and there is still the good old Hydra Z from Audiobyte. I have the L.K.S USB-100 but to be honest I don’t recommend this USB-I2S bridge for the DS DAC. Even my pi3-I2S-streamer (DSD128-able) does beat it (to my ears).
My understanding is that the Huron upsamples to DSD x20 > down coverts to DSDx4 > converts D/A.
Just want to clarify this.
Huron upsamples everything to a sample rate which is 20x faster than DSD, but it’s not a 1-bit sample space. It’s something like 50 bits - technically not “DSD”. People tend to get all religious about PCM vs DSD at this point… but be assured it’s such high resolution that it’s totally lossless for both DSD and PCM inputs. From there, after volume adjustment, everything gets run through a 1-bit sigma-delta modulation and noise shaper to produce a new DSD128 (2x, not 4x) output stream.
The other point is that this DSD128 stream isn’t so much “converted” as it is “output”. Yes, the binary 0/1 data representation gets translated to a +/- voltage switched signal through the video op-amp chips, but after that there’s nothing but an analog low pass filter. The switched signal is effectively digital and analog at the same time. It just stops being treated as digital and starts being treated as analog.
I guess, this noise is due to the treatment of DoP. JRiver and iFi appear to have solved this issue…
Question: Customers have asked – Why during DSD playback is there a “pop” sound?
Short (layman) answer: This is an inherent characteristic of DSD that is unavoidable.
Long (technical) answer: Please see below.
PCM can produce a true zero (silence) output in an instant. When the data stream stops, the DAC is then reset to “zero” for PCM.
As DSD only records the difference in level between each sample and during track changes (or a switch from PCM to DSD), the Player no longer sends DoP markers.
As a result, the DSD’s output levels (via DSD-DoP) of the DAC output can ‘stick’ at any possible level (almost anything but rarely zero) between the two extremes.
When the next song commences, the DAC suddenly receives a new DAC value (usually this new value is zero), which has no relevance to the previous sample- hence the ‘pop’.
The only way to reduce this ‘pop’ is to run a small period of silence during these changes. In other words, the playback software must handle this correctly and play a short silence before it stops sending DoP markers.
For example: JRiver v19 or higher has this under WASAPI hence no ‘pop’ between changes.
imagecheck001
Another example: there is no pop when using DSD (native) under JRiver.
Onkyo HF Player doesn’t have this feature and hence the pop sound.
Since the claim is that the problems are inherent in DSD I’ll describe what DSD really implies and not talk about what any given player or DAC implements correctly.
Well most PCM goes to zero slower than DSD, the speed is constrained by the output reconstruction filter on the DAC. That’s also true of DSD, but DSD’s filter is allows a faster fall than PCM sample rates up to about 100kHz to 160kHz. If a source which was playing DSD pauses it can send either DSD zeros (the best) or PCM zeros (which may cause a small tick) just like it can with PCM. Those ticks are no different with DSD or with PCM. When the track is unpaused PCM jumps immediately to the old value which would be the same kind of tick they are claiming DSD has.
Further they left out the analysis of DSD to DSD, especially gapless (where there’s no need for a problem) and they left out the other common case where tracks have usually ramped down at the ends so there’s no need for a pop. Tho DSD -> PCM may have a problem if the DSD isn’t near zero, PCM to DSD isn’t as random.
In practice the real problems come from people not implementing DoP correctly - there’s no reason for there to be any discontinuity in gapless playing even with DoP. DoP decoding requires a buffer of some unspecified size, (say, 32, 64 or 128 24-bit samples) if the DoP markers are all correct in that buffer you know that from the first correct DoP marked sample to the current sample are all DoP. If you don’t buffer the data, you will have passed the earlier DoP samples on as PCM and hence it will be decoded improperly. Tho playing DoP as PCM just sounds like low level hiss, it will be a discontinuity in the DSD and hence mess up transitions from PCM to DoP… That DoP tracking buffer need not add any latency if it can be incorporated into other buffers already in the system, e.g. the receive buffers for USB.
Another problem comes because the spec for dsf files requires “PCM” 0’s after all legitimate DSD samples, not DSD 0’s for some reason. If you get the length off just a little you may be playing PCM 0’s as DSD and hence be playing a full scale DC signal.
You needn’t run zeros between tracks, that will destroy gapless playing, most players can ramp down PCM in a straight forward manner and (now days) players that can convert PCM to DSD could ramp down the DSD to zero as well (tho I don’t know if any do this without converting all DSD to PCM and back instead of just the ramps). Some people do prefer these ramps on start and stop, but they are bad for gapless playing.
Has anybody noticed any “brightness” in the treble with Huron? I’m listening to Huron for the first time this evening, and track 7 of Sonoma One SACD “They wore blue” had me diving for the remote to turn the volume down. The energy balance seems to have been shifted making treble more pronounced, which I’m irritatingly sensitive to, and has thus required adjustment of my normal comfortable listening level.
From other postings I have the impression that the more extended treble of Huron can sound just louder for some, depending on resolution and/or quality of the tweeters. Probably also depending on certain attributes and accuracy of the individual setup.
For me personally there can’t be enough openness, even above that of Huron, but I would also not want an unnatural brightness (which I don’t hear from Huron).
few people reported aggressive highs after upgrade to huron (it was my case too) which is suspected to be improper ds firmware installation. it may happen possibly due to crossed files on SD card or other reason. Recommended solution is to format SD card (FAT), install pikes peak firmware, then repeat procedure with formatting SD and install Huron again. Also it’s recommended to do additional power cycle of DS after new OS installation before listening or continuing with another DS OS reinstallation.
few people reported aggressive highs after upgrade to huron…
Yes, with further listening of a wider range of content that’s exactly how I’d describe it, aggressive highs, un-naturally so. I installed Huron over Torrey’s and I thought I was finally set to go. I’m inclined to save myself the effort and just revert back to Yale.
Personally, I love Huron and am very glad that my wife does too. She is my “blind” listening test. Since she has no interest in how the music is produced (she just listens) therefore I never ask her about changes I make.
The test fails when:
she frowns and asks if I changed anything (this is a bad sign and she is always right when the new cable/gizmo isn't an improvement)
tells me to turn down the volume
The test passes when:
she asks if "is that is a new CD?" because it does indeed sound new [Huron passes the test]
identifies the artist with a smile [Huron passes the test]
The test passes with flying colors when:
she does near-field listening instead of from another room but turns the volume down to accommodate closer listening position [Huron passes]
We are in unchartered territory when:
she does near-field listening and does NOT change the volume [Huron the only system change that has passed this test - ever]
All correct except that tho previous releases did go to DSD128, Huron indeed does go to DSD256 (quad rate DSD) for output.
Woah, how did I miss this? Sorry Ted, and thanks for the correction.
I’m really curious about this change. I recall from the introduction videos of the DS DAC there was discussion about how DSD128 was the sweet spot in terms of jitter and power supply stability. Going higher to DSD256 introduced a risk of inaccuracy which was weighed as not being worth the gains in noise shaping IIRC.
Do I recall correctly? If so, what happened to change your mind about the trade offs?
The sweet spot for single bit is a little over double rate but way before quad rate. But that sweet spot depends on certain assumptions, in this case that the clocks are optimized for the specific rates. Indeed clocks with double the rate that the DS uses have worse low frequent phase noise specs. On the other hand clocks with lower rates just don’t exist with good jitter specs because there’s no demand.
In the case of the DS, my original design required a clock that ran 4 times as fast as the DSD output rate (e.g. at octal rate) and that clock was the only frequency that was available with the specs I needed off the shelf (otherwise it would have added significantly more to the DS’s price.) All of the power supply bypassing, etc. were designed around that clock rate.
Since then I’ve changed the code to not require the four times as fast clock and just let the clock switch more often than the data changes.
This means that running the DS at quad rate instead of double rate doesn’t increase jitter related to the output clock or the output reclocker.
Changing the internal processing in the FPGA could have a positive or negative effect: I kept all of the clocks at the same rate between Torreys and Huron (but did twice as much work with some of them) and I modified the code with jitter in mind and ended up with less jitter from the FPGA itself.
This is all independent of whether a A/D optimized for quad rate really sounds better than one for double rate. We all know that a great single rate A/D beats any less than great A/D at a higher rate. The trade off for, say, 4 to 7 bits is still between double and quad rate, tho it moves around a little depending on the number of bits.