Watts Up...?
Jan 26, 2019 at 4:23 PM Post #1,276 of 4,536
I'm not Rob. But, I'd bet the MScaler would still matter, as the DAVE only uses about 164,000 taps and the MScaler uses 1,000,000 more or less.

Yes, but isn't the whole point of 1Million WTA taps to reduce timing errors present in the original recording? Rob's ADC presumably won't have these timing errors. Which is why I'm curious..
 
Jan 27, 2019 at 3:55 AM Post #1,277 of 4,536
I'm not Rob. But, I'd bet the MScaler would still matter, as the DAVE only uses about 164,000 taps and the MScaler uses 1,000,000 more or less.

My best guess is MScaler will not server much purpose in this context. However, where to store and how to play all these 768khz files? My another guess is for the recording company to down scale the 768khz to 44.1khz in a form of CD, and we need a MScaler for such purpose. And even without a MScaler, the CD still sounds very much better.
 
Jan 27, 2019 at 6:10 AM Post #1,278 of 4,536
Question for you Rob:

If you record a musical piece at 768khz using your ADC and play it back on a Dave, would that make an M Scaler in the chain largely redundant or would there still be any benefit?

So the whole purpose of the M scaler is to convert your CD into a format that was identical to an original 705 kHz recording - and it will do this to better than 16 bits - the only difference to a true 705kHz is the bandwidth limiting, which I do not think makes any real difference to SQ - it's the reduction on transient timing errors that is key to better SQ. The M scaler will simply pass the signal through, and so will Dave's WTA 1, the 164,000 taps, as both WTA 1 filters only go to 705/768 kHz. I suppose the extra isolation that the M scaler provides may be a residual benefit if the source is noisy.
 
Feb 5, 2019 at 10:01 PM Post #1,283 of 4,536
I have had the prototype for some time, and have been busy coding for the decimation filters. I had planned to test in September, but the decimation filter from 104MHz down to 768kHz failed big time on simulation. I concluded that the way I was doing it was incorrect, so now have to re-design this decimation filter from scratch. I have worked out a strategy to enable this, but my time has been very limited recently with other projects pressing.
 
Feb 6, 2019 at 2:00 AM Post #1,284 of 4,536
Thanks Rob!

Making misstakes is the best way to learn.

Is there some fundamental difference doing a pulse array decimation filter compared to DSD? Or would these new insights translate to better DSD decimation filters also?
 
Feb 6, 2019 at 2:16 AM Post #1,285 of 4,536
I am not sure what you mean - true DSD does not have a decimation filter. Although most actual implementations of DSD is via PCM with DXD as the master file - the DXD running at 352.8 kHz. Perhaps you mean that process? The decimation used in conventional filters are poor, with lots of aliasing (20 dB or so rejection...). My approach was to not use moving average decimation, but proper FIR decimation with aliasing in practice being well below -300dB. The problem wasn't the decimation filters, but the fractional decimation required as I need to handle 705 and 768 kHz.
 
Feb 6, 2019 at 2:57 AM Post #1,286 of 4,536
I am not sure what you mean - true DSD does not have a decimation filter. Although most actual implementations of DSD is via PCM with DXD as the master file - the DXD running at 352.8 kHz. Perhaps you mean that process? The decimation used in conventional filters are poor, with lots of aliasing (20 dB or so rejection...). My approach was to not use moving average decimation, but proper FIR decimation with aliasing in practice being well below -300dB. The problem wasn't the decimation filters, but the fractional decimation required as I need to handle 705 and 768 kHz.

Yes conversion to low rate PCM e.g. DXD was what I was asking about.

But if the non integer conversion is the problem, wouldn’t it be easier to run the pulse array at 112.896 MHz so that 768 kHz is 1/147 and 705.6 kHz is 1/160?
 
Last edited:
Feb 6, 2019 at 5:14 AM Post #1,287 of 4,536
Yes good point - actually that used to be the frequency used on the QBD76. But timing closure was a real thorn in my side, and the M scaler (a mode for Davina) would certainly not be able to meet timing closure with 8.858 nS (112.896 MHz) rather than the 9.592 nS currently used. Also, I had an eye to the pro design in the future, where word clock sync is essential; then it's non-integer and non-fractional rates too! The scheme I have in mind for that works for asynchronous operation as well as the fractional too. Actually, it was the future asynchronous mode that was giving me my concerns.
 
Feb 6, 2019 at 6:51 AM Post #1,288 of 4,536
Yes good point - actually that used to be the frequency used on the QBD76. But timing closure was a real thorn in my side, and the M scaler (a mode for Davina) would certainly not be able to meet timing closure with 8.858 nS (112.896 MHz) rather than the 9.592 nS currently used. Also, I had an eye to the pro design in the future, where word clock sync is essential; then it's non-integer and non-fractional rates too! The scheme I have in mind for that works for asynchronous operation as well as the fractional too. Actually, it was the future asynchronous mode that was giving me my concerns.
Thanks! I was under the wrong assumption you could sync the clock using a VCO/PLL and clock multiplier.

I don’t understand what is the closure problem? I thought M-scaler is DDC for rates below 768/704 and wouldn’t run when the ADC is running due to the current demands of the FPGA when doing M-scaling?
 
Feb 6, 2019 at 10:13 AM Post #1,289 of 4,536
No a PLL would add unacceptable low frequency jitter, and this would be seen as skirts in the fundamental - oddly, it sounds the same as noise floor modulation, but is 1/f around the fundamentals, rather than the whole audio bandwidth.

Timing closure is a process one goes through with digital design - it must meet the timing constraints, otherwise it simply won't work correctly. The M scaler mode is when it's processing files that have already been recorded....
 
Feb 12, 2019 at 8:25 AM Post #1,290 of 4,536
Hi @Rob Watts

I know you've said in an interview that one day you want to do/collaborate on a speaker - when are we going to see your digital crossover and pulsed array powering drivers inside a pair of speakers!

A Rob Watts collaboration KEF LS50W would be sweet! All DSP done by you and amplification of the drivers done by you also.

Hurry up ! :)
 
Last edited:

Users who are viewing this thread

Back
Top