Amiga audio filters (OKK to Sorgelig)

[olekkarlsen]

Hey Sorg! Great job with cleaning the code and making the filters come alive! :)

However, i have a few comments and adjustments to suggest.

First of all, the filters needs to run at a higher speed than 1.5MHz. Minimum is 3.5MHz due to the pwm pulsetrain at that speed. The filters need to catch every pulse in the pulse train to be able to form the audio correctly. Impulse response! That's also why it is bad to feed the second filter with only 48KHz output from the first filter. Also feeding the second filter with integer truncated values from the first is bad. The sample should not leave the float domain in the whole total filter chain before it's ready to be sampled to integer at 48 / 96 KHz.

Also... to run to separate filter modules like this, is not the best to do, reasons above and even other reasons.

You'we done a great job, you did what i thought to do (almost), but i didn't have time to complete myself. Also the menu stuff and the config switches were out of my current knowledge of the framework. So Kudos! and Thankyou Sorg!

To add to, further perfect, or fix what you have already done, i'm not going to sync to your work again yet, to fix it myself, because you are the one with knowledge of your filter modules, and it's coeff calculations.

But what is needed is...

As i understand it, your filter has 3 sepparate poles in one go, in one module, where each pole feeds to the next pole not leaving the floating point domain?

And the filter crunches data at audio_clk gated by filter_ce... So the filter input and filter math constantly runs at that frequency even if you do not the output from it with audio_clk gated by sample_ce? right?!

So.. back to the filter chain, outputting 48khz from the first filter and into the next.... BAD!

Run all poles simultainously in one filter module!! ;)

Then, how to switch on and off each filter then? .... I'we got you covered! ;) Do it the way Commodore did it! Do not cut away a filter from the chain...... by "bypass it"... What they did was to move the poles far far away from the audio band when bypassing! Not cutting the filter out of the chain.

Therefore...

Setup ONE of your filter modules!

Use pole 1 for the notch filter. Make it's coeff variable, selectable (coeff 1: A500 at 4429Hz, and coeff 2: A1200 at... say... 30KHz or so... i will get the correct value later from the schematics)

Then, the same filter module, using pole 2 and 3 for the led filter! ;) Since the led filter is the same for every Amiga model, only one coeff set is needed. But that set should also be switchable! ;)

Let coeff 2 and 3 be defined at 3200Hz or so. In reality one pole is at 3KHz or so, and the other is at 3.4KHz... I have the capacitor and resistor values here...

So, make an array for the led coeffs set as well. One with the 3KHz poles, and one with "bypassed" poles, at say... 30KHz or so..... something like a fake infinity.... maybe 1MHz cutoff??!....

This is the way it was done in real hardware! ;)

And, when you do it like this in HDL, then the whole filter chain never leaves the float domain to be truncated by int, and never gets sampled at only 48KHz by the second filter... The whole filter chain runs untruncated in float and at AUD_CLK | filter_ce, from pole to pole, max audio quality, no truncation!

And that filter module needs to run at minimum 3.5MHz... i'd say run it at 7MHz just to be sure, IF Amiga CCK is variable. Must do so, due to the PWM pulsetrain!

So... one filter module at say 7MHz filter_ce...

Pole 1.. two coeff sets selectable (A500 (4429Hz) vs A1200 (Will get back to you on the frq, for now, just set 1MHz)).

Pole 2.. two coeff sets selectable (LED_ON (3KHz) vs (cutoff near infinity or high enough, say 1MHz?!)) Pole 3.. two coeff sets selectable (LED_ON (3.4KHz) vs (cutoff near infinity or high enough, say 1MHz?!))

And then the sample_ce.. at 48KHz or 96KHz, which you didn't make selectable yet, not hard to fix..

You know the filters better than me, i could fix the code, but you'd do it faster than me. Besides i don't know how to calculate your coeffs and gain....

But this is what is needed to do now, what's left.

So that's that. Thankyou Sorg!

This way, the one and only filter module instance is always connected... no matter if you select A500 or A1200 notch filter, no matter if you select LED ON or OFF. However... the only situation to bypass all of those three poles, i.e, the to bypass the whole filter module instance, is when the FILTER_MASTER_SW from the menu is selected to OFF. If so, then feed aud_l and aud_r to the mixer, instead of the filter_out left and right...

See? ;)

[sorgelig]

I've got your idea about filters. What i don't get is why we have to have PWM output at all. Especially it's unclear if PWM is still used in A1200. It's always hard to remove pulsation, so better not to add it. Even running filter at 3.5MHz won't really eliminate PWM. It will be a way more complex than using these filters. It's not a problem to keep PWM since it's there already, but it won't have practical use as it gives whistle tone when channel uses not max volume. Even after filter.

As for A1200 no-LED mode, it's about 28KHz which is useless as MiSTer uses ~24KHz filter internally. Also i don't see any use of 96KHz on Amiga as it's incapable to generate such tones. So 48KHz is enough.

[olekkarlsen]

Also.... Are those filters butterworth? They should be! ;)

[sorgelig]

it depends on coefficients. But yes, i calculate it usually as butterworth

[olekkarlsen]

Btw... the output freq from the filter module should't be selectable in the core, but in the framework which samples the audio chain at 48 or 96 khz in the framework top anyway.. therefore... the core's filter should output at it's full input frequency, at 3.5 or 7MHz, rather 7MHz as said above, due to possibly variable CCK of the Amiga... The Amiga core should not output at 48KHz or 96KHz when filtered... it should output it's native pulsetrain filtered or not at full CCK or 7MHz freq for the framework to then sample that and downsample to selectable 48 or 96K... This is the correct way, and then, one could also use the framework custom filters in addition to internal filters without quality loss in the total audio chain... the custom filters will then have 3.5 or 7MHz input from native Amiga output freq, and then the framework custom filters can output at 48 or 96K as the last entity in the audio chain.

Right then? ;)

[sorgelig]

sample_ce can be set to the same rate as filter_ce if it matters. If you want to run filters on 3.5MHz then it means it should run on Amiga's system clock domain 28MHz then output of audio won't be perfect for CLK_AUDIO. Not a big deal, but if you a looking for better audio then better to run filters on CLK_AUDIO. But then running filters on 3.5MHz will be useless as it won't match PWM clock.

[olekkarlsen]

I Have daddy weekend now, so i can't work on it just now, anyway, you know your filter module's coeff and gain calculations the best. But this is what's needed to be done now, to correct and complete what you already started.

Great job! But needed a few pointers.. and adjustments. ;)

[olekkarlsen]

I'm also thinking about porting munt to HDL... but that's something for later if so.... and off topic here. ;)

Cheers!

[sorgelig]

MUNT in HDL would be great, yeah! not MUNT itself as it needs very fast cpu, but MT32 in HDL would be cool

[olekkarlsen]

Hey Sorg..

The original Amiga HAD that whistle noise. It's part of the authentisity of the real Amiga sound. It's nit and grit true loFI sound. Therefor the PWM is most correct, either someone likes it or not. For those not purist the UAE multiplier version can be selected, for those purist, they can use the PWM version... thats fine eh...

And it's not the goal to totally get rid of that pwm whine anyway, it was present on the real Amiga, and should be here too. Amiga didn't totally filter it away, and neither should we hope to do.

Also... noooooo, 48KHz is not enough due to the fact Amiga only had a max of 28KHz samplerate.... we're not sampling amplitudes of 28KHz or less in the framework.... we're sampling the "HIFI" (analog filter) output.. which should be as high as possible. We're sampling not paulas notes at max 28KHz... nor are we sampling paulas output pulsetrain at 3.5MHz (in the frameworks last entity).... we're sampling the reconstructed impulse responses from the FILTER module... and that reconstructed audio sounds better the higher bitwidth and frequency it is sample with... So, yes, output freq matters more than most people understand, even you, smart as you are, a genious, doesn't quite see this.... yet... but i do.

Maybe you see it clearer too, now?

It is like saying.... we don't need 16 mill colors to emulate only 32 colors.... to a layman, this makes sense, but to the coder... the coder knows better, and knows why.... why we need 16 mill colors to do only 32...

it's almost the same with audio.... for reasons i explained above.

Hope this cleared it up a little more? ;)

[olekkarlsen]

mt32 based on munt in hdl, yes..... but haven't had time yet.... too busy playing ultima underworld 2 in the ao486 core and dicking around with WB31 setup on the minimig core yet.... :D :D :D

[olekkarlsen]

Also.. your filter module can be in aud_clk domain, even if it runs at 3.5 or 7 mhz.... that's fine, if the pwm train survives the clock domain crossing...

[olekkarlsen]

The domain crossing is async anyway eh? and it works like a bat out of hell too?! I first thought it was an error in code, and exclaim WTF?! when i saw the code.. before i understood what it did..... :D

But it works.. and sounds good too... so if the "sampler" on the aud_clk domain side is high enough... it should catch all those pwm pulses with correct timing? no?..... if not... then run the filter module on the sys_clk domain instead, and have it's filter_ce AND sample_ce at 7MHz instead of 3.5MHz incase CCK is variable! ;) That would not ruin audio quality for the audio_clk domain?! What's sampled there is up to the framework.... if it wants to sample at 48 or 96khz or whatever... it samples the "simulated analouge" output from the amiga filters..... in "realworld" capacitor scope... "infinity frequency", or in our case with DSP... 3.5 or 7MHz simulated RC filter....

What matters here, is what freq the rc filter runs at... both input (due to pwm) and output (as high as possible), so we can sample the "simulated capacitor and resistor filter" sound, like we would if we sampled a real analog rc filter... those capacitors dont run at only 48Khz quanitfied realty do they? no... the run at "God" speed... but in our case... they run at 3.5MHz ;) ;),

[olekkarlsen]

Amiga CCK 3.5MHz. Paula outputs a pwm train at that frequency ---> Filter samples the pwm train at 3.5MHz or higher to be safe, IF CCK is variable, it's all on the sys_clk domain, so it's synced even if the filter runs a dbl speed at 7MHz...

Then output from the filter at 3.5 or 7MHz... output_ce matches input_ce... Then cross the clock domain to audio_clk...

Then whatever.....

This is the way it must be.

[olekkarlsen]

And those coeff sets... arrays.... index[0] the led coeff... index[1] the pole sat at something outside the audio band...

and for notch.. coeff array... i[0]=4429hz... i[1]=a1200 cutoff... which is not totally outside the audio band... i will calculate the rc from the schamatics later...

i wish i knew your filter modules as good as you know them... i could fix it myself.

But anyway. Thankyou Sorg!

[sorgelig]

Pushed commit with filter changes. LED filter is still 2nd order 3275Hz. I don't have calculator for cutoffs per tap. But i think in real HW it's not so strict either. It's like 4429 vs 4400 - no one will tell the difference.

[olekkarlsen]

Just tested the merge release...... sigh.... good intentions, and a lot of work, but sigh.... due to lack of understanding of the audio chain, as i am trying to explain to you, the sound is totally wrong, and i told you so... mine sounds way better, but i agree with you that my messy combo logic filter implementation is not the best thing for the core stability...

But, your work is not in vain. Far from it, you have made a platform for me to build on, to fix and rearrange. No offence, but i understand the audio chain better than you, even if you may be a better coder than me.

So, we all have our gifts and special fields...

If you could please tell me how to calculate the coeffs and gains for your filter module, i will set this straight my self. Even better, if you could calculate one pole at 4429Hz running at filter clock 7MHz... and a 3250Hz pole and a 3500Hz pole, and a 1MHz pole all running at filter freq of 7MHz, then i will do the rest.

Then the notch will have A500 cutoff @ 4429Hz and the A1200 cutoff can be switched in at 1MHz.... for pole 1 on the filter module.

And the led, will run it's pole on pole2 and pole 3 on the filter module, having switchable coeff sets.. set.1 led on at 3.25 and 3.5KHz, and set two at 1Mhz and 1Mhz... the poles...

Then run the filter in amiga sys_clk domain at 7MHz.... and output from that filter at 7MHz too... Then what gets sendt over to the AUDIO_CLK domain is a 7MHz reconstructed HIFI audio waveform!

How you sample that simulated "analogue" audio stream on the other side, audio_clk domain, is up to you, 48K, 96K, or whatever. But keep in mind, that it's not Paula's 28KHz limit you are sampling then... you are sampling a simulated real world capacitor and resistor filter output... a reconstructed wave... and that wave HAS higher sound quality than raw paula playing only 28KHz! it has even higher output quality than a raw pwm stream at 3.5MHz! no matter what frequency you are sampling it at....

i'm pulling my hairs out here... trying again to explain audio to people that only think they understand that 48KHz is enough... yeah, at output maybe.... for some, but at internal workings things has to go as high as possible! Then downsample to 48 or whatever.

To be polite, your first fix sounded wrong, and i know why, as im trying to explain... mine has more omph and sounds right. But that may be because i do real float math.. and i dont know, maybe your filter does fixed point math? iwe only barely looked at your code... also. that you only sample the 3.5mhz pwm pulsetrain at 1.5mhz? AND on the audio_clk domain... and that you output at 48khz too early!

But you have laid a fundament for me to work further on, and to fix, implement, the right way, i only need the coeffs and gains for the filter poles... and the menu stuff was nice too... albeit, multiplier volume is not "normal", it is the pwm volume which is normal.... non pwm volume is to be considered UAE mode... and pwm, the normal! ;)

Great work! Good intentions mate! You'we made it easier for me to fix (menu signals) and using your filter module, BUT using it the correct way in the audio chain, which is important. Official core now has f***ed up sound compared to my work, but... when we team up... your work, adjusted by me, we will get there! ;) I understand audio on an astronomical level, hard to explain.

Cheers mate!

The coeffs i asked for please? I will look into it. Great work anyway, no one is perfect, neither you or i. :)

[olekkarlsen]

i know, and i agree... about the 2nd order filter....

[sorgelig]

the changes i've just submitted is what you need.

[sorgelig]

coefficients are standard 1-3 order IIR filter coefficients. You may check some pre-made audio filters for MiSTer. floating point numbers are converted to fixed point numbers - you may find conversion in IIR_filter module. parameters are get converted to port values there.

[sorgelig]

btw, LPF 1MHz is meaningless. I use overpass for A1200.

[olekkarlsen]

So i am very grateful for your work, but im also frustrated... trying to explain why things has to be done this and that way. ;) Im sure you can relate when people dont follow you on your level at your speciality fileds.. ;)

We will ofcourse get this right, together! ;) Eventually..

Cheers!

[sorgelig]

As i've told above i don't know how to calculate 2-3 order filter with different cutoffs per tap. And it doesn't really need. You need 2 chained filters like in real HW. In new version samples are passed on filter frequencies. So please look at new code before commenting. It was changes already.

[olekkarlsen]

1mhz meaningless? no... no calcwise... to the ear yes, but not to the chain... btw, what is overpass?

The orig audio circuits moved the poles way out of the audio spectrum, but they didnt cut them totally out. So not meaningless, the filter module does its work eitherway at the set working freq... no matter what cutoff coeffs you feed it... so nothing to loose in performance there when running 1mhz poles.. for bypass.

How do you calculate those coeffs anyway? in matlab? what format are those numbers in?

[olekkarlsen]

you fixed it right now?....

Ok... i get what you are saying about 2nd order calcs.... but as you say... cant we just use two 1st order poles as a 2nd order filter?

then run all three poles in one filter mod instance?

However... the filter needs to run at 7MHz in amiga clock domain.. both in and output.

[sorgelig]

you can use mathlab or some online calculators or special apps - all basically the same. iir_filter module has comments and formula how to convert the numbers.

However... the filter needs to run at 7MHz in amiga clock domain.. both in and output.

that's why i've said you need to read new code first before commenting...

[olekkarlsen]

I will have a look... thankyou! :)

[olekkarlsen]

Btw.. Sorg.... i tested both float27 AND fixed point math with my own filters.... and fixed point sounds dead, flat, and metallic, in comparison..... even when using N64Qsomething..... i dont remember what format i used, but even as high as 64bit fixed point didnt impress my ears compared to the float filters... i have 3 models.... combo mess one clock... 8 cycle multicycle version.. and a 8 stage pipeline version just recently coded, but iam having trouble with the recursives of the Y calculation in the pipe... stage 3 needs and Y from stage 6....., other than that, it works...

[olekkarlsen]

Better, Sorg! Much better too! :) have you compiled yet? tested it? maybe it all can be done with only one filter instance using all 3 poles and only switching coeffs.... either way... now filter two gets its input from filter one at 7MHz, which is more correct than feeding it only 48KHz of the reconstructed waveform. THANKYOU Sorg! :)

[olekkarlsen]

Now also the master output on the framework gets a 7MHz reconstructed waveform input to sample from... and NOW, the output frequency of the whole system matters! ;) there will be a difference from 48 to 96 now! Because what you are sampling is a reconstructed wave, not those low freq impulses on it's own. ;)

Great work so far! Am anxious to see how it sounds now. :)

[olekkarlsen]

Think of it as sampling (for output) an oversampled input, which is also reconstructed. ;)

[olekkarlsen]

I almost feel guilty for not doing the work my self, making you do the work by my explainations... but hey, i have daddy weekend now, and you are experienced with those coeff calcs for that filter anyway... i have yet to experiment with it to see if i can feed it in the right number format.

It should work much better now, after your fix. our fix. Thankyou again for your hard work and dedication! I love what you have done and are doing daily with this "beast" of a platform. Just the HPS bridge in itself is incredible work!

Cheers to you bro!

[olekkarlsen]

Sorg, only one more request, and maybe i can pull it off myself too...

About the framework filter module... make a switch to let it input and output using the raw fixedpoint float format, input and output in the linear sample range [+1.0f to -1.0f] filter native fixed point format ofcourse. This would let us chain filter modules together without leaving the fixedpoint float domain, and withhout leaving the linear range +-1f domain. This to avoid truncation by scaling and int conversion, between filter modules. ;)

Just a suggestion, as it would up the audio quality of all cores which uses chained filters from the framework. ;)

Then filter one would input an integer, output a fpm number (by switch), and filter two would input the fpm number directly and use it (by switch) bypassing the int conversion and downscaler to linear... and then let filter two output a scaled int which then goes through the clock domain crosser...

Ok.... and can propably do that myself later when i got the time.. if i understand the code that is..

[sorgelig]

i've modified LED filter to use 3000+3400

[sorgelig]

there is intrinsic module iir_filter_tap, so you can use it in higher order filter. No need to modify existing 3tap filter which does its job.

[olekkarlsen]

I will not pretent to understand what you meant in the most recent post there... hmm... you mean the filter is built using tap sub module? which can be included in a wrapper as many poles as you need?

Anyway... i just looked closer at your code now... cloned it.... Looks great! except we need to avoid integer truncation between filters... but that can come later... great work! :) and if i understand you correctly, a custom filter module can be built which handles everything internal with all poles needed AND never to leave the float domain? using pole sub modules chained together internally in the custom filter? using framework submodule parts?

This is great!!! :)

Also.. the led filter cutoff mod you just made... i remember it was something like that... I could go and look at the color codes of the resistors on my dac pcb now... but... later... it's close enough from what i remember.. for now..

Buy you a beer man!

[sorgelig]

Actually, existing 3tap filter is enough. It can be calculated as 4400+3000+3400 for A500. It just needs some mathlab skills to combine 3 1st order filters into a single 3tap filter.

[olekkarlsen]

I would still wish to have the filters run a fake infinity cutoff value at, say 1MHz or something when "disabled", as the real hardware did so... but that can also come later. instead of just skipping over and physicly bypassing a filter stage. It would also make for a more soft transition between a filter on and filter off switch. Remember... they are IIR filters.... it would make the impulse response, on the second filter more precise; or... rather, it would make the internal recursive math of the led filter produce a better impulse response when switching led on and off. Not that anyone care, but.... well.. on the original hardware there is infact a small capacitor on the PNP transistor circuit which switches the J113 jfets on and off.. to make on off transition on the led filter smoother... the J113 jfets is what pulls the 2 poles to ~infinity..... bypassing the resistors of the rc filter... just a detail there. ;)

My board is an exact replica of the original circuits, only difference is that im feeding the dacs a -5v vref instead og a +2.5v... and i run my opamp at vref 0v, instead of +2.5v... this to avoid flipping the wave upside down, as the original amiga did o so wrongly.... that is the only change i made to the circuit. that and the fact i made a much nicer looking board than commodore's ugly footprint and layout. My pcb is perfection in comparison. but all parts are the same... even the obsolete J113 jfets which controls the led filter switch...

It's to bad we can't model the characteristics of the LF347 opamp.... i dont know how to do convolution...... to simulate it.. it's also a very importan part of the amiga sound personality........... yeah well..

btw.... offtopic.... is there a switch on the de10 nano, those 4 large dips... do the framework respond to those in a binary manner? 1 for digital board, 2 for analog board... io that is.... 3 for custom board... ect... or are they not binary coded... i want to hook up my real amiga dac board, but dont dare yet... i want to avoid breaking compatibility too... it would be so cool to test my board directly hooked up to a "real" paula for the first time.... running at its full potential. So far i only fed it from uade linux over usb... 16bit pre mixed data... but it sounds REAL good! even if it truncated at 10bits.

Jaja... Great work Sorg! Now it's time to build, and test your fix... Hope it lives up! it should! :) in theory.

[olekkarlsen]

Actually, existing 3tap filter is enough. It can be calculated as 4400+3000+3400 for A500. It just needs some mathlab skills to combine 3 1st order filters into a single 3tap filter.

thumbs up 1

That was what i was thinking too...

[olekkarlsen]

Offtopic again.... but while i have you here.... sorry.... but... the RTG... it doesnt respond to interlace configuration... i run my screen at 640x360 to get a perfect widescreen fit... even i know the aspect gets f***ed... however,, looking at workbench.. to match an par or ntsc, whatever.. screen... rtg should be run at 640x200, if i run rtg at 640x400 then workbench will no scale its y output... workbench outputs at 640x200... and rtg operates at 640x400.... but if rtg is set to 640x200, then even workbench output at 640x200 too, it will not Y fill the whole screen... this is due interlacing lack on the rtg module i guess.... workbench only drawes for interlaced screen modes even if interlace is not chosen.... it looks... i was thinking that maybe to implement interlace in rtg, that this could fix the issue...

[sorgelig]

While some sort of obsession is good for motivation, in general it should be cut at reasonable point. Original analog HW can be affected by many factors through the life making specific Amiga unique. Thus even other real Amiga may sound differently. You can't emulate this. So it's better to cut the ambition at some reasonable point where you don't have to catch the ghosts.

[olekkarlsen]

Ofcourse there is the 7Hz or 14Hz highpass filter on the output stage of the amiga... but hey!! who cares! :D i have that in hardware... but wtf! no need to do that with dsp eh? thats only a fart in the night... :D

[sorgelig]

RTG doesn't support interlace. I use 1024x768 and 1920x1080 RTG resolutions. No problem with workbench.

[olekkarlsen]

While some sort of obsession is good for motivation, in general it should be cut at reasonable point. Original analog HW can be affected by many factors through the life making specific Amiga unique. Thus even other real Amiga may sound differently. You can't emulate this. So it's better to cut the ambition at some reasonable point where you don't have to catch the ghosts.

True... true... BUT.... i still like the float filters better than fixedpoint.... i really CAN hear the difference... but yes, i know... we need a master at time constraining... and i barely understand it.... i cant get it to do what i want..

but yes.. to be pragmatic.... yes... however... yes, i am obsessed with my childhood love, the flakey sound of the real A500... im also pasionate about avoiding signal integrity loss between stages... int conversion... too low sample rates between stages and all that.... you know.. it accumulates from stage to stage.... but now it is fixed! :)

So thankyou so very much so far bud! :)

[olekkarlsen]

RTG doesn't support interlace. I use 1024x768 and 1920x1080 RTG resolutions. No problem with workbench.

but too small to read man...... too damn small....

[sorgelig]

RTG resolution is variable. You can create (almost) any resolution in picasso96 settings utility.

[olekkarlsen]

the thing is.. workbench seems to output at a height of 200pixels no matter how high y resolution you use... if you set 400 px y res out.. workbench should draw and stretch to 400, but it doesnt... it only draws for interlace modes no matter what... it wb could draw progressive it would draw 400 height.. and then no problem... but it cant... therefor... i long for interlace supp in the rtg... but this is off topic here... yes... the icons doesnt look right.. even if i dont x stretch...

[sorgelig]

I suggest to discuss about RTG on forum. It's most likely setup problem in your particular case. WB has no limit of 200 lines.

[ghogan42]

Hello All. We are discussing Amiga in Artemio's discord for MDFouier -- a software tool for measuring a lot of details of computer and console audio. Link here: MDFourier Site

There is no full Amiga support right now but someone has measured the following curve for the A500 LED filter. Also they measured an a2000 LED Filter curve that was nearly identical to this one.

This is matched by a 3040hz 1st order butterworth filter so I think that the LED filter should probably be that. EDIT: I accidentally left the filter as 2nd order and not first but that seems to math the measurement(?) EDIT2: It was supposed to be 2nd order and I just misremembered that it was 1st. So I made 2nd order and 2nd order should be correct Proposed filter below:

For the other a500 filter, there is conflicting information and we don't have a good measurement yet. All I can see in this measurement (below) is that it's around 4khz or a little higher. We just need a better/cleaner plot. Btw, am I correct in assuming that the a2000 is missing the ~4500hz filter that the a500 has? If not we need to get that data some other way because this plot is the difference between an a500 and a2000.

So I think what we should do is something like this. LED filter at 3khz Separate filter at higher frequency.

Both can be combined. Maybe... The IIR filter code may fail with a 3rd order filter at low frequencies and too high of a clock rate (7mhz may fail when 3.5mhz works).

But I know that 3000hz and 3400hz butterworth filters won't match the measured curve we have of the a500 LED filter.

[sorgelig]

these is another discussion about filters: https://forum.audacityteam.org/viewtopic.php?t=70941

[olekkarlsen]

Great work Ghogan!

The A2000 and the A500 should have exactly identical filters! But, while looking at the different schematics available online, commodore appearantly liked to juggle around with the resistor values from revision to revision and machine to machine... not much, but a little here and there, but they also changed the caps too if i remember correctly, so to have almost the same cutoff values, but with different cap vs resistor ratios.... so yes, even the filters are supposed to be the same for a500 and a2000, there might be some minor differences due to other cap and resistor values used.

But to the ear... a500 and a2000 sound is near enough, and is supposed to be ~the same.

I have the resistor values and cap values for A500 filters on my amiga dac pcb...

a2000 has the notch 4k filter... it's infact 4420 or 4429hz if i remember exactly.. calculated from resistors and caps....

the led filter... the same on every amiga model has two poles yes... if i do the resistor and caps math correctly from the rc arrangement on the pcb... then it seems that one pole is at about 3khz and the other at ca 3.4khz..

its to understand the topology of the filter components, resistors and caps, versus how to calculate it.. im not quite sure of.. if i calculated it correctly... it has two 10k resistors in series... in the middle of those two resistors is a cap with its uniq value which goes to the output of the opamp... like a feedback... the other cap sits right after those two 10k resistors and goes to ground, right before the negativ input on the opamp... and has its own uniq cap value.. not the same as the middle cap... so.... two different poles... two different cutofs? i dont know if i calulated it correctly.. but i got about 3k and 3.4k,,,, or 3,2k and 3.4k.... i dont quite remember... maybe the poles are alike, but i didnt understand do calulate the topology.. idk...

but the notch filter... the 1 pole which is always on for pre 1200 amigas... it is 4420 or 4429hz.. im certain!

And... why me and Sorg landed on 7MHz filter clock instead of 3.5MHz, is because i dont know if CCK is variable and changes when you change screen resolution. you know... amiga dma can play at higher sample rates than 28khz when using a higher screen clock than pal and ntsc.... you know... 50khz amiga sound....

im not sure if cck is static or variable for that reason.... so i suggested to run the filters at 7mhz just to be sure... to infact catch all the pulses from the pwm train, very important.

if cck is not variable, but static at 3.5mhz, then the filters can run at 3.5mhz too... that is why.

also.... its fun to see such interest in this topic.... from others too.

.... Sorg... leave the filter clock at 7mhz for now, until we are sure that CCK never changes from 3.5mhz to higher... besides, the high rate the filter runs, the better reconstructed wave anyway.... better "upsampling" reconstruction.. so no harm..... and a little 7mhz fixed point fart isnt going to destabilize the core anyway... the more the merrier...

BUT... as i just looked through the framework just now... i saw that 48khz output was hardcoded and not selected by the config.ini as supposed to? is that right? that hdmi_96K in the ini file does nothing?

it was parameter hardcoded..... from what i could tell...

anyway... the filters must run at minimum 3.5mhz... but 7mhz is better anycase.... even if cck only stays at 3.5mhz...