Regarding the new Sharc processors, the chips themselves are reasonably priced. However any of the software for programming it, and any add-on software (RT kernal, USB support, etc.) all cost a lot of money if used for a commercial product. The basic CrossCore Embedded software that is a must-have costs $995 for the first year for a single node-locked license. Maintenance licenses appear to for around $500. Also, development boards are $500.
That's getting a lot more expensive than using the Vivado Webpack, or the next version up from that (without a licence, so limited functionality) that are used with Spartan 7 (or better) FPGAs. Of course, licenses for all the good things that would be nice are up in the tens of thousands of dollars, commercial use or not. But at least entry level Vivado for commercial use is free.
That's getting a lot more expensive than using the Vivado Webpack, or the next version up from that (without a licence, so limited functionality) that are used with Spartan 7 (or better) FPGAs. Of course, licenses for all the good things that would be nice are up in the tens of thousands of dollars, commercial use or not. But at least entry level Vivado for commercial use is free.
Last edited:
Hi Kay,
I haven't tried what you suggest, but I doubt it would work just as well. What might work pretty well could be to leave out some of the caps. Some people have reported audible improvement with as little as 15uf per rail. That doesn't mean all the benefits would be obtained with only 15uf, but probably a better bet to reduce total capacitance rather than put one full set across the rails. The smaller 10uf caps are probably important for higher frequencies, but maybe one or both 33uf caps could be left out for each rail, just to try it and see how you like it. Or maybe leave out the one 22uf and one of the two 33uf for each rail. Something like that. So, you might try 10+10+22, or 10+10+33, or 10+10+22+33 for each of the +-15v rails
Cheers,
Mark
I haven't tried what you suggest, but I doubt it would work just as well. What might work pretty well could be to leave out some of the caps. Some people have reported audible improvement with as little as 15uf per rail. That doesn't mean all the benefits would be obtained with only 15uf, but probably a better bet to reduce total capacitance rather than put one full set across the rails. The smaller 10uf caps are probably important for higher frequencies, but maybe one or both 33uf caps could be left out for each rail, just to try it and see how you like it. Or maybe leave out the one 22uf and one of the two 33uf for each rail. Something like that. So, you might try 10+10+22, or 10+10+33, or 10+10+22+33 for each of the +-15v rails
Cheers,
Mark
Thus, me mentioning the Sharc audio module. Comes with the most powerful chip, 2x2GB memory, CrossCore license and debugger for $195. Obviously, doesn't work for commercial use but for DIY at home it's cheap compared to actual cost.
Also, the chips implement circular data buffers in hardware, not sure if something like that that would help with the needed buffering you described.
Point taken, thank you.
All this talk makes me think maybe the thing to do at this point would be to pause looking at hardware and start looking a the number of necessary taps to reach a particular level of filter performance. To really get the best out of an external interpolation filter, one should upsample to create unused frequency space for a filter transition band. Also, an estimate should be made for stopband attenuation, and passband ripple. I am pretty sure 100dB of stopband attenuation is not enough (doesn't AKM use more?). Maybe 120dB or a bit more would be okay. A further guess would be that 130dB of attenuation might getting close to overkill, but may depend on dac distortion and noise performance. Regarding passband ripple, I think we would probably want to keep it very small, maybe .01dB at the maximum.
Then there is a question of whether to interpolate (say, by a factor of 8x) all at once or in steps. Steps may be best and there is literature to take a look at on the subject.
Once a reasonable estimate of filter requirements is available, that might help clarify how much hardware would be needed.
Last edited:
@hellokitty123,
Looks like there are a number of formulas and procedures to estimate taps. Alternatively, perhaps specific filter requirements could be entered to to matlab, then one could simply see how many taps it solves for. Or, use whatever tools one may prefer, but if matlab is what will be used then probably no need to look further. After that, latency could be taken into consideration, if of interest.
Looks like there are a number of formulas and procedures to estimate taps. Alternatively, perhaps specific filter requirements could be entered to to matlab, then one could simply see how many taps it solves for. Or, use whatever tools one may prefer, but if matlab is what will be used then probably no need to look further. After that, latency could be taken into consideration, if of interest.
Last edited:
Would it make sense to start with an existing implementation like SoX?
DSD encoding with SoX - Software - Audiophile Style shows some information on the initial implementation (I believe there have been a number of other settings added since).
Maybe you could upsample a track using sox and run it through your DAC without the ASRC and see which one you like best. Then we can look at the implementation (GitHub - mansr/sox: SoX, Swiss Army knife of sound processing) and see what it takes?
I've read some positive reviews on the Volumio resampling engine which uses SoX. Not sure if they modified it in some way, though.
DSD encoding with SoX - Software - Audiophile Style shows some information on the initial implementation (I believe there have been a number of other settings added since).
Maybe you could upsample a track using sox and run it through your DAC without the ASRC and see which one you like best. Then we can look at the implementation (GitHub - mansr/sox: SoX, Swiss Army knife of sound processing) and see what it takes?
I've read some positive reviews on the Volumio resampling engine which uses SoX. Not sure if they modified it in some way, though.
The best architecture for using an external interpolation filter involves doing some upsampling after the XMOS or Amanero board. Typical upsamplers used may include SRC4392 or AK4137. The upsampler at that stage creates frequency space for a later transition band. The next stage would be the interpolation filter. The dac then comes right after the interpolation filer. For best sound quality, probably the post-USB board upsampler output clock, the interpolation filter clock, and dac chip clock should all be run in synchronous mode together (one master clock for all). Then ASRC and DPLL could be disabled, if desired.
Besides creating transition band space, the pre-interpolation upsampler also reduces jitter, especially if it's clock phased locked in the right phase with the dac MCLK (at least for Sabre).
Perhaps one could prepare a file with close to the same processing sequence, then send the file contents over USB to the dac. For Sabre, the sample rate would have to meet the external interpolation filter mode frame clock (LRCK) specification relative to the dac clock frequency (MCLK). Also, a Sabre dac chip would probably require 32-bit word sizes sent to it, as that is native for Sabre.
Besides creating transition band space, the pre-interpolation upsampler also reduces jitter, especially if it's clock phased locked in the right phase with the dac MCLK (at least for Sabre).
Perhaps one could prepare a file with close to the same processing sequence, then send the file contents over USB to the dac. For Sabre, the sample rate would have to meet the external interpolation filter mode frame clock (LRCK) specification relative to the dac clock frequency (MCLK). Also, a Sabre dac chip would probably require 32-bit word sizes sent to it, as that is native for Sabre.
Last edited:
Right, I wasn't suggesting to use SoX as the final solution, just do a somewhat easy test to see if any of the filters in SoX make any difference in a listening test and maybe start with one of those filters as a base for the taps vs. quality/performance investigation.
Of course, running that filter in a SRC between the USB interface and DAC will sound somewhat different (hopefully better) because of the clock sync and reduced jitter but there should still be some effect when applied before the USB interface, right?
Of course, running that filter in a SRC between the USB interface and DAC will sound somewhat different (hopefully better) because of the clock sync and reduced jitter but there should still be some effect when applied before the USB interface, right?
I would expect so. Be interesting if someone wanted to try it, and then post a write up about what was done and any listening impressions.
Myself, I already have DAC-3 here that does all the processing in hardware, and i know how much better it sounds vs DACs that don't do all that same processing. So, I'm already convinced of the audible benefits of external filtering.
You can use powerful hardware. Hqplayer has a filter with 16 million taps and can use GPU resources for part of the calculations.
You could also simplify your end devices (transport + dac) to only support one rate.
You can get an easier to use/nicer interface to change filters and settings.
You could also simplify your end devices (transport + dac) to only support one rate.
You can get an easier to use/nicer interface to change filters and settings.
True about HQplayer, but it takes some time to run a filter that long, and doing it in software doesn't help reduce jitter just before the dac for SPDIF input instead of USB, or reduce any jitter from USB. You would need to upsample your whole music collection and couldn't just pop a CD in a player and instantly get the same sound quality . Also, what if you wanted to bi-amp. You going to DSP crossover filter each music file into two files, the upsample them with HQplayer, then try to play them back exactly in sync with each other through 2 different stereo dacs using USB? Not so friendly in that case, it might seem.
Seems likely a lot of people would like to see a new low cost dac that would be a good step up in sound quality from what is commonly available now. We will have to wait and see how things turn out, of course. At a minimum, thinking though some possible further improvements in overall dac hardware design is probably useful no matter what.
Interpolation Filter Subject Matter
On the subject of interpolation filter design, there is a very good book with a very interesting chapter on S-D dac interpolation filtering. The book is called, Understanding Delta-Sigma Data Converters (IEEE Press Series on Microelectronic Systems) 2nd Edition. Understanding Delta-Sigma Data Converters (IEEE Press Series on Microelectronic Systems): Shanthi Pavan, Richard Schreier, Gabor C. Temes: 9781119258278: Amazon.com: Books
One thing in particular, and in reference to the interpolation filter we saw for Sharc, it turns out that there are good reasons for not doing the 8x interpolation that we need for Sabre all at once.
On the subject of interpolation filter design, there is a very good book with a very interesting chapter on S-D dac interpolation filtering. The book is called, Understanding Delta-Sigma Data Converters (IEEE Press Series on Microelectronic Systems) 2nd Edition. Understanding Delta-Sigma Data Converters (IEEE Press Series on Microelectronic Systems): Shanthi Pavan, Richard Schreier, Gabor C. Temes: 9781119258278: Amazon.com: Books
One thing in particular, and in reference to the interpolation filter we saw for Sharc, it turns out that there are good reasons for not doing the 8x interpolation that we need for Sabre all at once.
Also, to follow up a little more on the subject of Polyphase Interpolation filtering, although such filters tend to be computationally efficient, the are only semi-linear phase. Of course, there is a question as to exactly how much phase non-linearity can be expected? Turns out, it depends. There are some published papers on the subject. Bottom line though, it looks like they may not be the first choice for high performance dac interpolation filtering.
Some comments I posted in another thread about interpolation filtering: https://www.diyaudio.com/forums/dig...dac-digital-filter-vs-nos-15.html#post5724666