AUDIO Implementation (Amiga AND Framework)

[olekk77]

From the Amiga core, emu top module...

reg [15:0] aud_l, aud_r;
always @(posedge CLK_AUDIO) begin
reg [15:0] old_l0, old_l1, old_r0, old_r1;

old_l0 <= {ldata[14],ldata};
old_l1 <= old_l0;
if(old_l0 == old_l1) aud_l <= old_l1;

old_r0 <= {rdata[14],rdata};
old_r1 <= old_r0;
if(old_r0 == old_r1) aud_r <= old_r1;
end

Whatta F..... IS this?!

What are you doing? Delaying the audio signal like a pipe, and then cancel out amplitude climbs and falls, so to only update output audio when the amplitude settles for a couple of clocks (is the same)... if i understand the code correctly?

WHY?! I see the same error (or feature) in the main SYS framework too...

Also, it is not correct to take a 15 bit input signal and just sign extend it to 16 bits! Then you get half the volume out you are supposed to have, also, if the minimig core makes 16 bits sound output (which is also wrong btw, should be 9bits PWMd volume), then why at the current 16 bit version does it only output 15 of those bits?? you loose the LSB in the precission too, that way.

I see, i must fix both the minimig core AND the sys framework, the audio parts...
Question is... what kind of reception will it get. Will it get merged? Will it be understood? Do you see that the audio implmentation systemwide is wrong?

Not to be ungreatful, Mr. Sorgerlig, you are a genious, and you have done a remarkable superb job, beyond words, i admire your genious, i am very greatful to you too, BUT... you appearantly are no audio man. Try is you might.

I will look in to the audio code and overhaul what i can, as good as i can understand the current code in it's depths, what it's really doing... or atleast is trying to do, incorrectly.

Also another issue... you can't mix two or three 16 bits streams and truncate the result to 16 bits... you loose bit precission! You get a quarter output volume from all sources... as 3 x 16bits mixed is 18bits with one 16bit channel to spare for mixing.

What we need, is 20bit HDMI audio output, but i don't know how to do that. The hdmi clock and all that...
20 bits is needed in the sys framework for headroom for mixing from all cores! Really!

I am working on a new amiga iir filter module btw... this time pipelined, but im having some trouble with the recursives in the pipeline yet... it works... but output one interleaved sample too much inbetween...
This pipeline version to be able to up the clock... have had constraining trouble with my past implementations.. both monolith and multicycle...

So anyway.... i am now going to overhaul paula for pwm volume and 9 bit output, connect it to my filter in the minimig_top, shift the 9bit output up to 16 (which is the correct thing to do) the into the filter, and 16bit out from the filter, unfucked by the code above (DELETE) and rewrite, and feed the 16 bits filtered audio directly once per audio clock, untouched!

Then i will gut the framework for the same strange behaviour, and also look into the mixing and stuff..

To calm myself a little... why was it done this way? the delay with update on only alike samples?
Is it because of the frame delay in the video? 2 frames delay? is it out of a wrong understanding of audio

Why?

Also the strange only let through alike samples behaviour....

Iam pulling my hears out here, reading the code.... Iwe done audio for years!

Anyway.... what is this.. can you explain your thoughts on the code... why it is so, what you were trying to do?

You, get my 20bits hdmi audio out... and i will do the rest....
All cores should be updated after this fix.

Kindly...
Ole.

[olekk77]

Cores should output at 16bits.. but the framework should mix and work and output at 20bits.. for headroom!
Really!

Also... what if a core output 8 bits...... AND you just sign extend that up to 16bits..... what happens then? eh.... you get very low sound output! And have to mick around with 2x 4x 8x output fixes (wrong!), as is currently done in many cores.

No.... sign extending this way is not the right way to do it! Shifting on the otherhand is the correct way, but then you may have to convert to unsigned before the shift if i remember correctly (been a long time since i last coded such stuff)... and then convert it back to signed afterwards.. i think... been a while...

ahh sigh...

[olekk77]

Am compiling a first mister port of my mist paula now... but without filters, first run. Will you the framework filter at 4khz for that to begin with, due to long compile time... and possible constraint errors with the float maths....

Have sat up the core such that the LED controls a switch between the old behavour and my new implementation of the audio chain... Exited to compare in realtime!!

Have not touch the framework yet, only studied it.... but im sure it destroys the audio somewhat anyway, only i cant put my fingers on it... by listening yet.... infact the amiga sound on mister sounds quite good in comparison to original mist audio, but that may be because its digital out....

will test now first.. only amiga modified.. then test with framework modified also...
cleaner mixing and cleaner signal i hope.

[robinsonb5]

From the Amiga core, emu top module...

Whatta F..... IS this?!

Without investigating too closely, I'd guess that it's for clock domain crossing. Necessary if the core's generating the audio on a clock that isn't a simple multiple of the output audio clock. Without it, there will be occasions when the clocks fall close enough together that setup/hold time is violated, and only some of the bits of the new value make it into the output registers, causing awful glitches.

[olekk77]

Aha, Robinson... that would explain a couple of thing during my test runs. The first build had a smaller rbf, and had no hdmi picture sync, but audio fell through occasionally, the second build worked fine, but the sound was metallic and awful, as if the framework filters didn't operate at the correct frequency, too little cutoff.... BUT the boom from the bass, and the clarity of the sound in general was greatly improved by the pwm volume and the MSB adjusted sample amplitude! Third build with my old and first filter implementation from mist, glitched bigtime. It may have been a random build glitch due to the unstable constraints in the core in general... and it may have been due to the clock domain crossing lack, and also could be that my float math didn't like to run at 24MHz... in this environment... I'we had it up to 28MHz in the past, on the Mist.... But i have not constrained it, i don't f...ing know quite how. Timequest is HARD to understand!

Anyway.... time domain crossing shouldn't be done this way... i think... the proper way, and the only proper way, i think, is to use a FIFO... even a small one! Hmm.... f***.... If using a fifo.. then the framework which is pulling on the fifo would need to know what rate the source puts samples into the fifo at... so the framework can resample it's input from the fifo to the correct output samplerate for mixing.... then each core would have to tell the framework which frequency it outputs sample to the fifo at.... a minor update to the cores and the framework.... but it will be totally glitch free then. Would ofcourse need an async fifo for that. It's the proper way anyway.

But then, all the core makers or maintainers would start defining their cores' sound output at 44.1K 48K 96K, etc.... and remake their cores so they output at those low and lame frequencies.... because of a lack of understanding of audio in hardware.... maybe... but in hardware... those cores should output at their respective clock frequencies.... i.e.. the amiga should dump it's paula audio stream to the fifo at 3.5MHz CCK.... and the framework which pulls the fifo should resample that to 24MHz and do it's filters, and then down to 96KHz or whatever! by resampling, i really mean, sampling.... i guess... but in a synced manner.

So... Take Paula...

Paula runs at variable color clock, i guess... mostly at 3.5MHz.

Whenever paula changes it's color clock, it should tell the framework. The fifo would have extra tags for each sample containing a frequency word.

So at a paula clock, paula writes it's sample amplitude and current frequency as a tag to the fifo.
So it goes, round and round, doing it's thing...

Then at the framework end, running at 24MHz, it pulls on the fifo, reading both the sample, and the frequency it is supposed to run at, the framework sets up it's counters to use that sample at the correct time... simple linear resampling as in software... (doesn't sound good, but hey (amiga non linear is better, but ok..., doesn't apply practical here))... anyway, the framework does it's thing so that it resamples the fifo input to 24MHz... then passes it along to it's filters, and then resamples that down to 96Khz or whatever...

The cores could do it's filters internally in whatever MHz range they'd wish, and then output at 96KHz, for instance.... BUT if the core dumped it's audio at 96KHz without internal filtering, then the framework filters would only have 96KHz to work with... and the best would have been for the framework to apply it's filters to the core audio at the core audio's real clock cycle frequency.. often in the mhz range... then the framework filters can do it's thing on the whole chip output frequency! Why? because some core do pwm volume and stuff like that, and they need to output their pwm "blips" in the mhz range, for the framework filter to be able to catch, and smooth out (reconstruct)...

So it's real important, that the cores be allowed to output in the mhz range, samplerate, sound.
Then the framework filter which runs at 24MHz, can catch it all (each pwm blip, etc, whatever), before downsampling to 96KHz after the filter output. Then, there would be NO LOSS of pwm "information" in the sound before the filters.

But that is the way it is now, i suppose, only with the loose clock domain crossing....
Hmm...

[olekk77]

Hey Robinson, you were right! It looks like the weird stuff being talked about here indeed is a clock domain crossover, i re enabled it, and now both the old multiplier volume paula, and the new pwm volumed paula works perfectly fine!

I am having some trouble with my filter now on the mister, i am currently testing the filter on both sample stream versions... both multiplier and pwm volume... The first build was f***ed because of time glitches, had distorted sound... the next build was fine, BUT... the filter seams to have problems anyway.. it clips at loud inputs, for both stream versions, worse for the multiply volume, and better for the pwm... IDK...

Look away from the clipping fact (input gain)... my filter has better impulse response than the framework filter. It has clearer sound, both at bass and treble bands!

I'm thinking of moving the filter from the AUDIO_CLK domain at 24MHz down to the CCK domain at 3.5MHz right after paula output instead, to see if that relaxes the possible timing glitches from the heavy floating point maths.... i need more slack.. HAHAH!

I could try to use the fixed point versions of the filter though, but i hate the sound it produces. Naked steel cold sound with no omph! I have several versions lying around which i tested on the old Mist last year.

The thing is, the floating point version is unstable, both in regards to timing slack (not constrained), and it is unstable in regards to it's gain float resolution and it's coefficients float resolution, also possibly this gives a wrong calculation result which accumulates through the IIR and makes it unstable from time to time... No such unstability with the fixed point math filter. I use the same algorithms only with different math modules hooked up... i coded it interchangeable.

So.... idk.... Settle for the fp math?! I'd hate to do that.
The float modules i'm using is float27.... would be nice to have float32.... maybe that would make it more stable... i tried a f32 module on the mist, but i couldnt get it to build... black screen.... constaints again...

And even the fixed point maths had less gain and coeff resolution, it didnt get unstable. Maybe because of "rounding" between each accumulation cycle...

I also tried the fixed point version at different bit widths.. even at N64Qwhatever (dont remember), but it sounded just as cold as the lesser bitwidth version, but just as stable though...

Fixed p math... more stable... colder sound.
Float p math... more unstability, but warm and omphy sound!

Heck... maybe a float rounding module at the filter output would do the trick?! i don't have one.. couldnt find one for the f27 modules i have. But that wouldnt stop the accumulation errors in the recursives in the filter from building up though..... IIR filters are touchy!

Nah... will make a test run at 3.5MHz filter clock, cck domain... with the float filter... see if that fixes things... Last time i did that on Mist that too worked, but gave a less omphy sound than at 28MHz....

I really hate timing constraints! But that has nothing to do with the float27 filter unstabilities anyway... i guess it's due to too low float resolution and accumulation errors thereof.

There is not much difference between pwm volume and multiply volume.. BUT the pwm paula produces more fidelity, clearer sound... not much to the untrained ear, but just enough to make the difference, to feel the real Amiga, in comparison, treble is more present at both treble and bass band. And the audio whine sounds more correct, that little whine that the Amiga had, that is different from the PC softmixing whine... That is the difference... that and more omph! And it makes all the difference too.

The old one sounds plastic, and the new one sounds Amiga, not much diff... but enough to notice.

Anyway... the pwm part is done, and switchable between the old multiply volume and pwm volume in the sources.

Now, it's the filters that needs some more love...

I fixed a bug in the top level module where mixing between paula and mt32 is done... old paula had 15bit output and upscaled that to 16bit using sign extension (wrong) and did not MSB allign the sample which it should have done instead. I removed the erronous sign extentsion and msb aligned it instead!

But, further down in the code... where it mixes at 17bits... it's correct to use sign extension, but not in the block above... the crossover block... it should have msb aligning instead of sign extension! I fixed that.

The rest looks ok... I dont quite understand the clipping code below though... maybe its sort of a cheap compressor? it looks that way... idk.. to avoid having to halve both mt32 and paula before mixing to 16bits... i will look into it further later...

But now... less typing here, and off to quartus to move the filter to cck domain and test...

[olekk77]

But we really need 20bits hdmi audio output in the framework! For headroom in regards to mixing many 16 bits streams together without having to halve the volumes before mixing, of having to clamp and hardclip the mix. 20bit 192Khz HDMI audio would be nice!

Now... who knows hdmi enough to fix that?

[robinsonb5]

I'm thinking of moving the filter from the AUDIO_CLK domain at 24MHz down to the CCK domain at 3.5MHz right after paula output instead, to see if that relaxes the possible timing glitches from the heavy floating point maths.... i need more slack.. HAHAH!

That would be a good idea - you *really* don't want to move an unfiltered 3.5MHz PWM pulse train across clock domains because you'll distort the pulse widths.
Far better to filter it at source - or on a clock that's a multiple of CCLK.

I have several versions lying around which i tested on the old Mist last year.

The floating point filter you created last year did sound very good. (It was just too large for that particular platform; no such limitation on MiSTer.)

The thing is, the floating point version is unstable, both in regards to timing slack (not constrained), and it is unstable in regards to it's gain float resolution and it's coefficients float resolution, also possibly this gives a wrong calculation result which accumulates through the IIR and makes it unstable from time to time...

Is it possible that some stage of the filter is using an incomplete result from a previous stage?
(If it takes 2 cycles for a value to propagate through one of the FP elements but you feed its result to the next element every cycle in a pipeline-like manner, you're going to be feeding garbage into the next stage some of the time.)

So.... idk.... Settle for the fp math?! I'd hate to do that.

The FP filter you demonstrated last year sounded good - I'd try to rule out timing issues before assuming numerical instability.

I really hate timing constraints! But that has nothing to do with the float27 filter unstabilities anyway...

Not necessarily - adding constraints won't fix it, but if you're seeing violations that's a big hint that results are taking more than 1 cycle to arrive, and thus you need to account for that with a delay in your state machine.

There is not much difference between pwm volume and multiply volume.. BUT the pwm paula produces more fidelity, clearer sound... not much to the untrained ear, but just enough to make the difference, to feel the real Amiga, in comparison, treble is more present at both treble and bass band. And the audio whine sounds more correct, that little whine that the Amiga had, that is different from the PC softmixing whine... That is the difference... that and more omph! And it makes all the difference too.

There was an interesting thread on EAB recently where some new insights were gained into the PWM volume in the Amiga. I'd assumed that the PWM was free-running, but it's not - it's reset every time a new sample pair arrives from DMA. The implication of that is that the volume of the two samples within the pair will be slightly different from each other, since the volume counter won't necessarily have completed a full cycle when the next sample arrives.

[olekk77]

Well, mine IS free running, if i remember the state machine correctly, i tried the reset for each new sample approach last year, and it didn't seem right... to my ear.

I only commented out the //volcntr stuff from the state machine that was already there... AND added the counter and gating mechanism, plus the notch filter... but it makes all the difference i think.

Seems you were right about the pulse train and 24mhz too... i was also thinking the same earlier...
It's working like a baby now, at 3.5MHz, no glitches whatsoever.

And t.y for the kind words Robinson!
Also im now taking my time to apologize to Sorgelig. Maybe i can be a bit hmm "arro".. hmm.. myself..

Sorgelig is a genious! and a hard worker. But no man can reach over everything... without some bugs.. and besides, not all of this is his code anyway.

Anyway... here is the top level code... no time for git now... yet..

wire test_new = 1'b1; //~LED_POWER[0];

// Audio filter for Paula
wire [15:0] flt_l_in = (test_new ? {ldata_okk[8:0], 7'b0} : {ldata[14:0], 1'b0});
wire [15:0] flt_r_in = (test_new ? {rdata_okk[8:0], 7'b0} : {rdata[14:0], 1'b0});

wire [15:0] flt_l_out, flt_r_out;

iir_1pole_filter a500_notch_filter
(
.clk (clk_sys),
.clk_en (clk7_en && cck), // also make a cck input port. The filter now resets at clk_sys without clk7_en
.rst (RESET), // investigate using the correct reset signal!
.left_in (flt_l_in),
.right_in (flt_r_in),
.left_out (flt_l_out),
.right_out (flt_r_out)
);

// Audio clock domain crossing for Paula?!
reg [15:0] aud_l, aud_r;

always @(posedge CLK_AUDIO) begin
reg [15:0] old_l0, old_l1, old_r0, old_r1;

old_l0 <= flt_l_out;
old_l1 <= old_l0;
if(old_l0 == old_l1) aud_l <= old_l1;

old_r0 <= flt_r_out;
old_r1 <= old_r0;
if(old_r0 == old_r1) aud_r <= old_r1;
end

// Audio mixer
reg [15:0] out_l, out_r;

always @(posedge CLK_AUDIO) begin
reg [16:0] tmp_l, tmp_r;

tmp_l <= {aud_l[15], aud_l[15:0]}; //+ (mt32_mute ? 17'd0 : {mt32_i2s_l[15], mt32_i2s_l[15:0]});
tmp_r <= {aud_r[15], aud_r[15:0]}; //+ (mt32_mute ? 17'd0 : {mt32_i2s_r[15], mt32_i2s_r[15:0]});

if (1) begin
out_l <= tmp_l[15:0]; // [16:1] if mixing
out_r <= tmp_r[15:0]; // [16:1] if mixing
end

else begin
// clamp the output
out_l <= (^tmp_l[16:15]) ? {tmp_l[16], {15{tmp_l[15]}}} : tmp_l[15:0];
out_r <= (^tmp_r[16:15]) ? {tmp_r[16], {15{tmp_r[15]}}} : tmp_r[15:0];
end
end

assign AUDIO_S = 1;
assign AUDIO_L = out_l;
assign AUDIO_R = out_r;


about glitches from stage to stage..... nope... not this filter.. it's once cycle, the old one, the first one i wrote... it sounds best! it's a pure one cycle huge monlith of float operations chained together with wires in combo logic.... only registered at output to make it easier on the doman crossing and mixer.

F*** what sound i'm enjoying right now! Thanks to the hdmi output it's even cleaner and more realistic than on Mist (a good machine) with it's f***ed sigma delta piece of cr*p.

Now, what i want to do... is tear away the dsp filter... and hook up the mister to real Amiga dac with real active opamp filters.... because in hdl we now miss the touch of the LF347 opamp!

But i don't dare to f*** with the pins in the framework yet.... what if i run another core in accident with my dac board connected..... kapoooof... no more mister.... the day when mister becomes sister... chip castration by volt both ways... hahaha!

Hell... i really enjoy this Mister! All Sorgelig has done! Wooow!!!!
Samba network... ssh, ftp.... just build and samba over, and run... everything..... less glitches on hid input than on mist... near perfect, except that the shared mouse / kb HPS bus with disk transfer, really needs some QOS stuff! one large disk hog, and mouse still freezes... it's annoying, but was far worse on the mist.

My oh my am i having a great time!
Playing UW2 in DOS, d***ing around with the Amiga, and loving the RTG too, which i thought was unneeded back last year....

This box is fantastic! And it's all thanks to Sorgelig. My oh my what work he has put in!

Cheers!

I will fix the git stuff later.. to share... i built my stuff on a 3wks old source release...

And not to forget.. you have done a huge job yourself Robinson! Thankyou both, and all!

Sound works like a baby now!

[olekk77]

Am gonna fix the led filters too... later... i have it implemented already, but only in the multicycle version, which only works with both filters enabled using fixed point math....

Hey Rob.... could you please add some filter selector mechanism to the osd menu for me please, and share the code? I dont know that stuff quite well myself yet...
I need an option in the Audio & Video submenu to enable and disable all internal filters (a master switch), and below, a filter mode selector (A500 vs A1200 filter model), so that it's ready to hook up to my code...
If you want to... you could also make a menu option to choose between pwm volume and multiplier volume... but maybe that last thing would not be so smart.. because it could make people fallback to and use the old non correct multiplier model...

Anyhow... i have built these filters in real hardware on pcb.... so i know the values and how it should sound... it's a near perfect replica of the analog circuits on the A500 board.

I even did a 3.5MHz software mixer before i did the pcb... and made my own PT playroutine which used fake paula calls to my softpaula at 3.5mhz..... im beginning to think im mad and obsessed with the sound of the Amiga....

Hahaha!

well... this i a filter channel.... first version.... sound the best... pure combo logic... no wonder it doesnt like high clock speeds....

// Left float operations
f27_int2float left_input_conv (.A (left_in), .Q (left_fp) );
f27_mul left_input_scaler (.A (left_fp), .B (input_fraction), .Q (left_smp));
f27_mul left_filter_gain (.A (left_smp), .B (filter_gain), .Q (left_flt_in));
f27_add left_filter_add0 (.A (left_flt_x), .B (left_flt_in), .Q (left_flt_add0_out));
f27_mul left_filter_mul0 (.A (left_flt_y), .B (filter_coeff), .Q (left_flt_mul0_out));
f27_add left_filter_output (.A (left_flt_add0_out), .B (left_flt_mul0_out), .Q (left_flt_out));
f27_mul left_output_scaler (.A (left_flt_y), .B (output_scale), .Q (left_smp_out));
f27_float2int left_output_conv (.A (left_smp_out), .Q (left_int_out));

It's the one taking 4K logic elements.... the best one.

[robinsonb5]

Am gonna fix the led filters too... later... i have it implemented already, but only in the multicycle version, which only works with both filters enabled using fixed point math....

I wondered about the LED filter - that one has a steeper roll-off doesn't it?

Hey Rob.... could you please add some filter selector mechanism to the osd menu for me please, and share the code? I dont know that stuff quite well myself yet...
I need an option in the Audio & Video submenu to enable and disable all internal filters (a master switch), and below, a filter mode selector (A500 vs A1200 filter model), so that it's ready to hook up to my code...

I'm the wrong person to ask, I'm afraid - I'm not familiar with the MiSTer framework yet, and my hands are full elsewhere at the moment - hopefully someone else can step up to the plate...

[olekk77]

Steeper yes, -12db pr octave... and about 3khz cutoff i think.... it's hard to understand the analog electronics, which path has which cutoff value, from capacitors and resistors... the 2 pole led filter has a "weird" configuration in real life... one pole is at about 3khz and the other is at about 3.4khz if i remember correctly...

Yes.. if someone could add those menu entries and core signals for me, it would be nice.

[olekk77]

I got it all in hardware! My great pride, first and only pcb i'we ever made!

[olekk77]

And i BADLY want to connect it to the Mister to feed it raw Paula dat, straight to the parallel interfaced 10bit dacs.... both filter and the LF347 love og God, opamp! I really love the sound and personality of that opamp! For me, it is what makes the Amiga sound so special..... not Paula... yes, a good deal, but it's opamp that really forms the sound!

But..... i don't dare to mess around to connect it yet.... have to dic* with the framework for that... and if i run another core by accident... then... kaboom.... no....... will wait and see...

But it would be the ultimate of the ultimate for the Amiga core!

[olekk77]

That's why i designed the pcb with only 10bit dacs... i knew already back then that only 9bits was needed, due to the pwm.

[LamerDeluxe]

I'm really enjoying reading this topic. Great to see someone so passionate about perfecting the audio of the Amiga core. The Amiga's audio always sounded really good, even compared to most 16-bit audio on a PC. Its signal to noise ratio is so good that its audio output was used to drive lasers beams.

I have no idea if the USER IO port might have enough bandwidth to connect to your audio board.

[SegaSnatcher]

EDIT: Nevermind someone made me a build with your PR. So far so good.

[LamerDeluxe]

BTW I've read that MT32-pi also has audio quality problems with its analog output, maybe it is something similar to the problems described here with the MiniMig core.

[robinsonb5]

BTW I've read that MT32-pi also has audio quality problems with its analog output, maybe it is something similar to the problems described here with the MiniMig core.

Maybe, but it's important to understand that what olekk77's doing here isn't about "quality"in the traditional sense (i.e. signal-to-noise ratios, distortion, etc.) - it's about authenticity - making the core imitate the particular characteristics of the Amiga that make it sound like an Amiga (including its flaws) as accurately as possible.

[d0pefish]

Indeed, the noise problems with the Pi's PWM (headphone jack) audio are because of quantisation noise. The Pi GPU firmware (closed source) does some noise shaping and oversampling to mitigate this, but accessing this driver via baremetal (for mt32-pi) isn't possible without causing significant timing problems and adding large amounts of latency because of the awkward CPU<-->GPU coordination.

It's okay for streaming audio in desktop Linux (usual Pi use case) but a poor option for my project where we need fast response. Simplest option to avoid this is to add a cheap DAC, or in the case of MiSTer, just transfer the digital audio directly to it over I2S (which is what the mt32-pi MiSTer HAT does).

Source: https://www.raspberrypi.org/forums/view ... p?t=195178

If the noise shaping can be implemented efficiently in software I'd love to add it, but I don't have the necessary experience.

BTW, I think the MiSTer's analog audio output suffers from exactly the same phenomenon - it is most obvious when a sound gradually gets quieter.
See 3:15 of this video for a perfect example - this "sweeping/bitcrushing" noise doesn't occur with digital optical output or HDMI sound:
https://www.youtube.com/watch?v=W0ScMbmXMG8

SupraDeus on the Discord channel is/was investigating this for both MiSTer and Pi - he could probably use some help.

[robinsonb5]

BTW, I think the MiSTer's analog audio output suffers from exactly the same phenomenon - it is most obvious when a sound gradually gets quieter.
See 3:15 of this video for a perfect example - this "sweeping/bitcrushing" noise doesn't occur with digital optical output or HDMI sound:
https://www.youtube.com/watch?v=W0ScMbmXMG8

Try this instead of the simple sigma delta - https://github.com/robinsonb5/EightThir ... d_pwm_sd.v
It's been floating around in various cores for a while but I tidied it up recently. It's the result of some experimentation years ago on the original Minimig board, where I discovered that a simple 1st order Sigma-Delta converter gave significantly more noise at low input levels when it was clocked at 28MHz than exactly the same converter clocked at 7MHz.

I figured that higher clock frequencies mean narrower output pulses, maybe as they get narrower their actual and theoretical shape was diverging. If that was causing noise, widening the pulses would be a good idea. To do that, I used a 1st order sigma delta with 5-bit rather than 1-bit output, and used that to drive a PWM,

My go-to test for Minimig is to load the Protracker 3.15 ADF, play Stardust Memories with the global volume slider one pixel below minimum, and record the output on my PC at maximum input gain. This hybrid converter performs significantly better in this test than the various others we tried way back when.

(It also includes some experimental countermeasures against the power-on pop some people have complained about - not well tested yet.)

[NegSol]

I love the new sound! Huge difference imho - much clearer and I love the pronounced bass

[LamerDeluxe]

BTW I've read that MT32-pi also has audio quality problems with its analog output, maybe it is something similar to the problems described here with the MiniMig core.

Maybe, but it's important to understand that what olekk77's doing here isn't about "quality"in the traditional sense (i.e. signal-to-noise ratios, distortion, etc.) - it's about authenticity - making the core imitate the particular characteristics of the Amiga that make it sound like an Amiga (including its flaws) as accurately as possible.

Yes, I understand that, that is a really good goal, especially on the MiSTer. The Amiga has it's own way of generating digital audio with a variable frequency per channel, which sounds really good. I was thinking that their might be some of the sane basic mistakes in handling the audio signal that he mentioned, but reading d0pefish' reply I understand it is a different situation, though with similar artefacts.

Indeed, the noise problems with the Pi's PWM (headphone jack) audio are because of quantisation noise. The Pi GPU firmware (closed source) does some noise shaping and oversampling to mitigate this, but accessing this driver via baremetal (for mt32-pi) isn't possible without causing significant timing problems and adding large amounts of latency because of the awkward CPU<-->GPU coordination.

It's okay for streaming audio in desktop Linux (usual Pi use case) but a poor option for my project where we need fast response. Simplest option to avoid this is to add a cheap DAC, or in the case of MiSTer, just transfer the digital audio directly to it over I2S (which is what the mt32-pi MiSTer HAT does).

This makes it clearer for me why boards for audio like Bela exist. Too bad about that latency.

If the noise shaping can be implemented efficiently in software I'd love to add it, but I don't have the necessary experience.

BTW, I think the MiSTer's analog audio output suffers from exactly the same phenomenon - it is most obvious when a sound gradually gets quieter.
See 3:15 of this video for a perfect example - this "sweeping/bitcrushing" noise doesn't occur with digital optical output or HDMI sound:
https://www.youtube.com/watch?v=W0ScMbmXMG8

SupraDeus on the Discord channel is/was investigating this for both MiSTer and Pi - he could probably use some help.

I was giving SupraDeus a tip on a way to generate noise on Discord, I've looked into how a delta sigma DAC works a long time ago.

Generating noise can be done in the same way as an old Commodore or Atari computer does it, with a linear shift feedback register (polynomial counter), I'd expect something like that to work efficiently on an FPGA.

If you would want to shape the noise to move it mostly outside of the frequencies that human hearing is sensitive to, you could add octaves of this noise together (each octave doubles in frequency), each with their own amplitude. Though that adds a lot more complexity.

You probably already know that you add half a sample step of noise to the signal to make the rounding error random instead of an audible pattern.

[LamerDeluxe]

BTW, I think the MiSTer's analog audio output suffers from exactly the same phenomenon - it is most obvious when a sound gradually gets quieter.
See 3:15 of this video for a perfect example - this "sweeping/bitcrushing" noise doesn't occur with digital optical output or HDMI sound:
https://www.youtube.com/watch?v=W0ScMbmXMG8

I figured that higher clock frequencies mean narrower output pulses, maybe as they get narrower their actual and theoretical shape was diverging. If that was causing noise, widening the pulses would be a good idea. To do that, I used a 1st order sigma delta with 5-bit rather than 1-bit output, and used that to drive a PWM,

One-bit DACs need a really stable clock to avoid distortion, multi-bit DACs need a really stable voltage to avoid distortion. Multi-bit delta-sigma combines the best of both types, IIRC it is what is used in most modern DACs.

[rsn8887]

The new MiSTer Minimig code today has a filter enable option only in the menu. The user has to enable or disable the filter.

But the Amiga had the so called LED filter that could be enabled and disabled by software running on the Amiga. For example, driving through tunnels in Lotus 1 enabled the filter automatically (power LED would go on, sound muffled), and driving out of the tunnel disabled the filter automatically (power LED would go off, sound clear). Is this already implemented in your repo somewhere?

Implementing this "automatic" LED filter would be a great benefit to make the Minimig sound more like a real Amiga.

[limi]

Bonus points for hooking it up to the LEDs on the MiSTer

[LamerDeluxe]

I tried the beta of the audio fix yesterday and wow, fantastic job! It sounds so crisp now with a lot of bass. It really gives me that Amiga audio vibe.

[SegaSnatcher]

I tried the beta of the audio fix yesterday and wow, fantastic job! It sounds so crisp now with a lot of bass. It really gives me that Amiga audio vibe.

Try the new release and let me know what audio settings you prefer.

[rsn8887]

Awesome! The "automatic" "LED" filter is now implemented! I love it! Thank you so much to all involved!!!!

[SegaSnatcher]

I tested the "LED Filter Auto" with Lotus lll and it worked great. Filter turns on when you go in tunnels and turn off when you exist tunnels. Pretty neat.