Closed jotego closed 4 years ago
Hi,
You can try an advanced version of PWM... using two clocks (ref and a upper one), like this one : http://github.com/renaudhelias/CoreAmstrad/blob/master/BuildYourOwnZ80Computer/pwm.vhd
PWM (http://www.cpcwiki.eu/index.php/FPGAmstrad#PWM) Using a simple PWM, data is entered at a certain speed, the PWM clock speed. If you simulate a constant PWM output signal at middle range of voltage (state just between 0V and 5V : 2.5V), it results an alternance of 0V and 5V, that result in a noise sound. In Arkanoid, this defect make some continues sounds instead of silents... My idea is generating a sound having a frequency upper than dog ultra sound, while I want to simulate a constant 2.5V. For this I do use two clocks entries in my PWM : one about data entry, and another about algorithm execution. This result a high quality sound output
I found this issue again, with a different DAC version on the FPGAgen project. This time the DAC was a mixed PWM+sigma delta. The DAC was producing pure tones at random points in Sonic 1 and in some basic sound tests that I had compiled for the Megadrive.
I pulled out the IEEE Xplore to search how sigma delta DACs are being done in real life products, and then I read some notes from a course a colleague had lent to me. Well... We are all missing an important piece of the sigma delta DAC structure: the interpolator.
Notice how the audio signal is originally sampled in a certain medium frequency clock, say 50kHz. Then you put it through a VHF clock, like 100MHz when you are effectively re-sampling it at the input of the sigma delta. That has the effect of increase the frequency content (particularly high frequencies) of the original signal.
Here is how it works: suppose you had these two samples: time 0 --> value 10 time 1 --> value 5 With your original clock of 50kHz, the meaning is that the signal has gone from 10 to 5 in 1/50kHz=20us. Now, when you use say 100MHz in the DAC and just connect directly the LF sampling signal to it, the DAC sees this:
time 0 --> value 10 time 1 --> value 10 ... time 1999 --> value 10 time 2000 --> value 5
Now the signal has changed from 10 to 5 in 1/100MHz=0.01us. We have increased absurdly the HF content of the signal! Commercial DACs fix this by using an interpolation filter between the LF signal and the DAC input, producing this kind of input:
time 0 --> value 10 ... time 1000 --> value 7.5 time 1999 --> value 5.1 time 2000 --> value 5
The interpolator keeps the frequency content of the 100MHz signal the same as the original. But are we listening to these HF artifacts?
The answer is yes, we are. We are not noticing it much because of the relatively low quality of the sound systems implemented in MiST so far: PSG chips and poor 8-bit PCM sounds. But the real danger comes when more complex music goes through this kind of system and the high frequency content now triggers oscillations in the feedback of the sigma delta. That is sadly what happens too often with FM sounds, like the YM2151, where I found the issue, or the work I am doing now for the Megadrive core and the YM2612.
The solution to this is to add an interpolator. But the interpolator is a nasty block. We are talking of a FIR filter of +200 stages running at the same speed as the sigma delta. By the way, the sigma delta does not need to run to 100MHz to produce nice sound. But it does need an interpolator in front of it!
So I am looking at adding a FIR to the FPGAgen project and see if that fixes the issues I am hearing. I am worried about not having enough FPGA resources to do this. On top of that, I need two interpolators as the chip is stereo...
I really think we need an extension to MiST with a real audio DAC.
Thanks for for interesting explanation. Do you think that HF noise at around 100MHz even passed through audio route? Shouldn't it filtered out by itself due to low pass nature of audio circuit?
About interpolator: If we know original sampling clock, then we can add delay for one step to get sample 1 and sample 2. And then it's not a problem to interpolate it to 100MHz DAC by very simple "line drawing" function. This should be easy for sound from Minimig as it's known sampled music output at 44.1KHz(IIRC).
For beeper sound it may be more tricky, but some other tricks can be used there since sound quality there is originally low. Some quantization with splines can be added.
Do you think that HF noise at around 100MHz even passed through audio route? Shouldn't it filtered out by itself due to low pass nature of audio circuit?
I knew this question would come :) My description above was an intuite explanation of what happens. I have made a frequency analysis of the signal on my first post (the one that causes an issue when going through the sigma delta). The following graph is the frequency plot of that signal as seen if we just sample it with a 10x clock. The blue curve is the unfiltered signal. The red one is filtered with a ~15kHz low pass filter. You can see how the blue signal has a lot of high frequency content.
X axis: Hz Y axis: dB
I agree that this is basically out of band, because people cannot hear to 30kHz sounds. I think the problem comes with the frequency response of the sigma delta and particularly to its instability. Some of this high frequency content is what triggers the self-sustaining noise through the feedback of the sigma delta.
Your solution using a line drawing algorithm is not the orthodox way of doing this but may be good enough and save FPGA resources. I am going to try implementing the FIR filter I have used to make this graph first. If I run into space issues I will explore other solutions like the line method you propose.
Hi,
The 2nd-order Sigma Delta from the Minimig does have some instabilities. The hybrid Sigma Delta / PWM we're currently using isn't unstable as such, but because it's so simple it does develop standing tones when the signal level is very low - the easiest way to provoke these is to feed it a low amplitude DC signal. DC signals are mapped to a fixed-frequency pulse train, and the higher the amplitude the higher the frequency.
When I used this converter on the Minimig project I ended up solving the standing tone problem by clearing the SD accumulator at a frequency of about 28KHz. It was an ugly fix, but in actual listening / recording tests the hybrid SD/PWM it worked surprisingly well - only Chaos's 2nd order SD fractionally outperforms it, but that has stability problems. There's a thread about this on minimig.net, including some recordings: http://minimig.net/viewtopic.php?f=7&t=516&hilit=sigma&start=50 I want to try both dithering and clearing the accumulator on a random rather than fixed schedule and see what difference if any that makes.
There's also a third-order SD as part of the Atari800 core: http://www.scrameta.net/atarixlfpga_svn/trunk/atari_800xl/common/components/hq_dac.v but I tried it last night and once again had stability problems.
Alastair M. Robinson
On Tue, Mar 7, 2017 at 5:35 AM, Jose Tejada notifications@github.com wrote:
Do you think that HF noise at around 100MHz even passed through audio route? Shouldn't it filtered out by itself due to low pass nature of audio circuit?
I knew this question would come :) My description above was an intuite explanation of what happens. I have made a frequency analysis of the signal on my first post (the one that causes an issue when going through the sigma delta). The following graph is the frequency plot of that signal as seen if we just sample it with a 10x clock. The blue curve is the unfiltered signal. The red one is filtered with a ~15kHz low pass filter. You can see how the blue signal has a lot of high frequency content.
[image: comparacion] https://cloud.githubusercontent.com/assets/1863036/23642817/01f4c870-02fe-11e7-938f-b259a7024871.png X axis: Hz Y axis: dB
I agree that this is basically out of band, because people cannot hear to 30kHz sounds. I think the problem comes with the frequency response of the sigma delta and particularly to its instability. Some of this high frequency content is what triggers the self-sustaining noise through the feedback of the sigma delta.
Your solution using a line drawing algorithm is not the orthodox way of doing this but may be good enough and save FPGA resources. I am going to try implementing the FIR filter I have used to make this graph first. If I run into space issues I will explore other solutions like the line method you propose.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mist-devel/mist-board/issues/39#issuecomment-284626668, or mute the thread https://github.com/notifications/unsubscribe-auth/ABLs6MYLCOHqmIAZBiuac7d1L-4C4izQks5rjOyPgaJpZM4KR-Ak .
Hi Alastair,
You are right. I think the uses with the hybrid are what you described.
FPGAgen specific I have just finished with the interpolation filters for JT12. Now I get the FM and PSG outputs mixed at the DAC sampling frequency and low pass filtered. I have not changed the DAC itself yet. I have synthesized it and it works. The sound artifact that prevented my SSG test to run is gone. In general, I would say that it sounds nicer now but it is too late to load the older core and make comparisons. You can check it yourself with the compiled core here. Note that the new one is v0.3 and the old one v0.2
I had only studied FIR filters during my degree. This has been the first time I actually apply that knowledge. I am happy I could put it together in a day.
Having said that, the issue is still open. I'll continue and try to fix the rest of the DAC.
I'm closing this as I think this is just a design limitation on the board we cannot address.
I left my sigma delta book at work and I cannot check whether stray is the right word. The effect is well known for sigma delta DACs: some input signals may cause the output to become unstable for a while, until it eventually fades away.
Here is an example of that situation with the MIST/Minimig DAC. In the image you can see the audio capture from the DAC at the top, and at the bottom the same audio captured digitally. You can see how the digital version is stable in the middle, while the other starts to stray away only to stop when the input signal changes totally.
You can also hear to the right sound here. And the DAC sound is here.
If you listen to the full song you can catch this issue more times, but it requires paying more attention to it. I leave the files in case someone is curious:
Full song Correct sound MIST DAC sound