TAG

How does the RetroCade synth handle aliasing?

Recommended Posts

From what I have been reading the original chips like the SID and NES APU had very high sampling rates so aliasing was not an issue, what is done in the Retrocade Synth to avoid aliasing artifacts?

Share this post


Link to post
Share on other sites

The quick answer, without reviewing the source code to verify. Since this is an FPGA we have plenty of resources, all operations on the audio data inside the FPGA are not using 8-bits, I think we are using 11-13 bits for all operations. The Delta-Sigma DAC is also 13 bits I think. Don't hold me to that, I didn't actually check, but from what I remember we are generating 8 bit audio but feeding all operations into 11-13 bit buses.

Share this post


Link to post
Share on other sites

I'm no expert but my understanding is that it is more about the sample rate than the bit depth.  Do you know the sample rate of the DAC?  Here are some of the links I am reading to understand where I am coming from:

 

http://forums.nesdev.com/viewtopic.php?f=3&t=8602

 

 

And from Ludde's FPGA NES:

 

"Because the sample frequency of the APU is 1.79MHz, and the output frequency of my DAC is much much lower, I need to implement a digital low pass filter to remove the very high frequency components, to avoid aliasing artifacts. I implemented a 767 order FIR filter using one of the FPGA's DSP Multiply and Accumulate units and some block ram. The DSP unit can compute expressions on the form P = P + A * (B + C) in a single clock cycle. The FIR filter runs at 21.4773 MHz, and generates an output sample rate of 1/384th of that (55.9 kHz). Thanks to FIR filters being symmetrical, I only need to perform 768/2 = 384 multiplications per output sample, i.e. exactly one multiplication per clock cycle."

 

Both refer to the NES but applies to any pulse or saw wave that is sampled with a standard audio sample rate 

Share this post


Link to post
Share on other sites

Our DAC is running at 96Mhz and we can run it faster if we need to, but I think that's fast enough for our application. The more bits you use the higher speed you are supposed to run at. Here is an app note about the Delta-Sigma DAC.

 

Are you hearing something on the output that concerns you? Or just looking into potential problem areas?

 

I'm not putting a lot of time into looking into this, but I took a quick look at the definition of Audio Aliasing at a couple of sites and I took it to mean the troubles you run into if you are violating the Nyquist theorem. I don't see anywhere in our system that we do not have enough samples to correctly create the waveforms that we want to. First of all, we are generating the waveforms instead of sampling them so there is no problem with the creation of the waveforms. We are generating the waveforms at the same speed as the original chips did and the FPGA is plenty fast enough to handle mixing/modifying those waveforms. (SID is 1Mhz and the FPGA system clock is 96Mhz) Then when we do things to modify those waveforms, such as mixing voices, we use buses that are larger then 8-bits so there are no overflows or anything like that. Then when we convert from digital to analog we are using a high quality Delta-Sigma DAC running at 96Mhz, so I can't think of any location we would be introducing Aliasing... Maybe I'm missing something, I only did a quick read on the topic, or maybe I'm not remembering the source code correctly.

 

UPDATE: I just read through the FPGA NES forum article you posted and I need to read it more closely and think about it more. But, I think it does not apply to us, in the situation he is generating NES waveforms at 1Mhz and then the bottleneck comes when he wants to feed those waveforms into a soundcard. The sound card only handles 44Khz and that is what violates the Nyquist Theorem and introduces the aliasing. In our situation we are generating waveforms at 1Mhz, mixing/modifying them at 96Mhz, and feeding them into a DAC running at 96Mhz. We should never violate the Nyquist Theorem in that scenario. Take that with a grain of salt though, I really only put about 10 minutes into thinking about it... The one potential problem area comes from whether we are running our DAC fast enough to support the bit width that we are using, there is a formula in the xapp that we should be using to determine that.

 

Jack.

Share this post


Link to post
Share on other sites

I am not sure about this case, but a single bit DAC acts as a low pass filter, as the slew rate of the output is limited by time constant of the output filter (usually a simple single pole RC design).

 

The high frequency accuracy is somewhat limited (e.g. at 20kHz you may only have 10 bits of resolution for a 20MHz DAC), but it works well.

Share this post


Link to post
Share on other sites

I just looked at the FPGA NES project and he is using a AD1866 DAC which is fixed at 16 bits and 16Mhz. The combination of 16 bits and 16Mhz is probably why that system has issues, you need to be much faster then 16Mhz for 16 bit output from what I recall from experiments with Delta-Sigma DACs a couple years ago. When I started increasing the bits it started to sound bad, I was never able to get good output with more bits then 18 or something like that, even with ratcheting the speed way up.

 

We can adjust our bit width, I think we are doing 11 or 13 bits or something, and we can increase our speed up to 250Mhz to make sure we can achieve our desired DAC output of 44Khz.

 

I really should read over everything again and make sure this makes sense and I'm not pulling things out of thin air. :)

 

Jack.

Share this post


Link to post
Share on other sites

Jack, don't confuse parallel DACs with Sigma Delta DACs. The AD1866 is a proper parallel DAC, but the internal parallel portion of the DAC is loaded serially. Because of that you need to shift in 16 bits before the value is converted "at once" to analog. With a 16MHZ clock you can shift in 16 bit values at a rate of 1MHz. This would in principle give you an audio signal of 1Mhz, far above the hearing threshold of any human being. EDIT: datasheet suggests a clock of 16xfs with max clock 13.5MHz, not sure what FPGA NES is doing.

 

With the Sigma Delta DAC, the value loaded into it is not converted "at once" (ie in a single clock cycle) but over a number of clock cycles, hence if your values have too many bits and the clock is too slow you run into problems. The rule of thumb, from memory, is

sigma_delta_clock >= output_frequency * 2^sample_size

So for example if sample_size = 12 bits and you want to produce sounds with output_frequency of up to (but no more than) 22Khz then you need a sigma_delta_clock of at least 22000*4096 = 90.112Mhz

 

As you can see the clock increases exponentially with bit size so for 18 bits like you mentioned above and 22KHz you'd need a clock of well over 5GHz

Share this post


Link to post
Share on other sites

I have not heard any problems on the output of the RetroCade synth.  I mentioned that I had implemented the NES APU in a Cypress chip, in that implementation I feed the 4 bit output into a parallel DAC clocked at 250k Hz and I could see aliasing artifacts on the scope when I looked at a pulse output.  Then I started reading up a bit and found that the issue is a common one in software and DSP implementations of square and saw audio oscillators.  Since I ultimately plan to migrate to the RetroCade synth I thought I would ask how this issue was currently being addressed.

 

I understand that the generation of the waveforms is not a problem, but ultimately those generated waveforms are sampled by the DAC, and if a pure generated pulse wave is not bandwidth limited it will have high frequency content well above the nyquist frequency of a typical audio DAC and that content will be mirrored back into the lower frequency audio range.

 

I will have to read up on how the Sigma Delta DAC works, but it sounds like it might be clocked fast enough to avoid any issues.

Share this post


Link to post
Share on other sites

The sigma delta DAC basically turns the PCM (pulse code modulation) signal into a PDM (pulse density modulation) signal where the average value of the pulse train is equal to the input to the DAC, this is then filtered by a single pole passive RC low pass filter to remove all the high frequency components that result from the signal being a pulse train.  This is why these DACs require such a high level of oversampling to achieve good SNR, putting the sample rate of the PDM signal up so high pushes the noise introduced by the conversion to PDM way up away from the signal content you want, the low pass filter then removes this noise leaving the desired signal.

 

In short the DAC used in the retrocade basically contains an anti-alias filter as a vital part of the DAC already so this is not a significant issue, the only issue you will have is if your PCM sample rate is only just at nyquist rate and the RC filter doesn't have a fast enough roll off to attenuate the first alias, which it likely will not, however this is easily avoided by using a higher sample rate.

Share this post


Link to post
Share on other sites

Thank you everyone for sharing your knowledge and insights into this issue. It sounds like we should be ok, I guess the real test will be to look at the output on a scope to see if there is aliasing.

 

Jack.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now