Hertz Overload - new demo for AGA Amigas

[saimo]

Originally Posted by Karlos

That sounds great,

Thanks!

but I can only hear it via YT, so I'm not getting the true experience.

Indeed the video is just a pretty WinUAE-generated fake

[pixie]

Originally Posted by saimo

Thanks!


Indeed the video is just a pretty WinUAE-generated fake

How the "fakery" compares with "teh real thing"tm?

[saimo]

Originally Posted by pixie

How the "fakery" compares with "teh real thing"tm?

That's something anyone should judge by themselves.
What I can do (it just occurred to me) is to post a recording from my A1200, although with all the already mentioned limitations (no quality equipment). Maybe later today...

[pixie]

Originally Posted by saimo

That's something anyone should judge by themselves.
What I can do (it just occurred to me) is to post a recording from my A1200, although with all the already mentioned limitations (no quality equipment). Maybe later today...

That would be nice! And the winuae version to compare it with

[hammer]

Originally Posted by saimo

Here are the findings from my latests tests.
Please keep in mind that all the equipment I have this humble ASRock J5040-ITX PC with its anonymous on-board audio chip

J5040-ITX's audio is Realtek ALC892 Audio Codec with ELNA Audio Caps.

https://www.realtek.com/Product/Inde...99&cate_id=195
Hardware Features

• DACs with 95dB SNR (A-weighting), ADCs with 90dB SNR (A-weighting)
• Ten DAC channels support 16/20/24-bit PCM format for 7.1 channel sound playback, plus 2 channels of concurrent independent stereo sound output (multiple streaming) through the front panel output
• Two stereo ADCs support 16/20/24-bit PCM format, multiple stereo recording
• All DACs supports 44.1k/48k/96k/192kHz sample rate
• All ADCs supports 44.1k/48k/96k/192kHz sample rate

Originally Posted by saimo

@hammer

Even if emu68k would have an easier life, it still would be severely slowed down by the continuous, constant and numerous interrupts and writes to the Paula registers. An AHI driver should be possible, but its use would be limited because the CPU-driven method is inherently limited and not suitable for multitasking contexts.

I purchased a low-cost ECS Denise for my A500 Rev6A. Is AGA an absolute requirement for your demo?

[saimo]

Originally Posted by hammer

J5040-ITX's audio is Realtek ALC892 Audio Codec with ELNA Audio Caps.https://www.realtek.com/Product/Inde...99&cate_id=195Hardware Features

• DACs with 95dB SNR (A-weighting), ADCs with 90dB SNR (A-weighting)
• Ten DAC channels support 16/20/24-bit PCM format for 7.1 channel sound playback, plus 2 channels of concurrent independent stereo sound output (multiple streaming) through the front panel output
• Two stereo ADCs support 16/20/24-bit PCM format, multiple stereo recording
• All DACs supports 44.1k/48k/96k/192kHz sample rate
• All ADCs supports 44.1k/48k/96k/192kHz sample rate

Precisely because of that I couldn't make tests with sampling frequency higher than 192 kHz.

I purchased a low-cost ECS Denise for my A500 Rev6A. Is AGA an absolute requirement for your demo?

Yes: the graphics side requires 8 bitplanes, 24 bit colors and 64 bit bitplanes data fetch.

[saimo]

@all

After recording the music from the A1200, I realized that it was way too noisy, so I realized that something must have gone wrong. It turned out that the last-minute changes to the converter (cWAV16toAQA1) were totally ill-advised and also buggy, so the converted music was affected by a horrible noise!
I have uploaded the fixed version now - download from the usual place: https://retream.itch.io/hertz-overload

And here is the sampled Amiga 1200 output (19 kHz, 32 bit float): https://www.retream.com/_temporary/P...ions-A1200.wav - grab it while it's hot, as sooner or later I'll remove it

Moreover, in the afternoon, I couldn't help but make more volume-related tests. Very interesting results. I'll share them later or tomorrow, depending on how long it will take me to write the post.

[Tsak]

Great work @saimo

Originally Posted by saimo

Precisely because of that I couldn't make tests with sampling frequency higher than 192 kHz.

Is there any point to that really? Unless you are an extreme audiophile with super trained ears, there's no way in the world you can hear the difference. 48k is more than enough already. Given the fact the sample will get squashed to a lower frequency and bit depth, this makes even less sense. Or am I missing something?

From a purely musical/artistic perspective, you'd get much greater gains in quality by good-old fashioned mastering (especially when we are talking about mixed tracks like this one). Better EQ to the instruments, compression and maximizing/limiting. The louder the track is, the easier it becomes hiding that pesky noise as well.

Originally Posted by saimo

RTG doesn't matter. The method should work on all chipsets, although as far as I know OCS and ECS output is severely muffled by the filter

Imho the filter on a500 should have been "banned" long ago
Afaik it can be disabled by tweaking the power led (can be done in software). Once I heard results without it I vowed never to go back (when it comes to game making on OCS).

[saimo]

Originally Posted by Tsak

Great work @saimo

Thank you

Is there any point to that really? Unless you are an extreme audiophile with super trained ears, there's no way in the world you can hear the difference. 48k is more than enough already. Given the fact the sample will get squashed to a lower frequency and bit depth, this makes even less sense. Or am I missing something?

From a human standpoint, you're absolutely right, of course.
The tests I'm referring to were aimed at finding out how Paula works and how (im)precise it is, so the more precision the better

From a purely musical/artistic perspective, you'd get much greater gains in quality by good-old fashioned mastering (especially when we are talking about mixed tracks like this one). Better EQ to the instruments, compression and maximizing/limiting. The louder the track is, the easier it becomes hiding that pesky noise as well.

Yep. Regarding this, I do try to exploit the dynamic range an much as possible, but I don't resort to compression, as I prefer to keep the sound "pure". What I do is manually eliminating all the critical peaks (without distorting the sound). Of course there are limits to this. As a result, for example, the acoustic intro of the demo's music, being naturally quieter, has a lower SNR and thus produces some noise when played with the 14 bit technique.
From the picture of the source 192 kHz 32 bit file you can appreciate the total lack of compression (click for full size):

Imho the filter on a500 should have been "banned" long ago Afaik it can be disabled by tweaking the power led (can be done in software). Once I heard results without it I vowed never to go back (when it comes to game making on OCS).

I cannot imagine how it sounds with such a strong filter, but still I wholeheartedly agree thinking of how my A1200 sounds like when the filter is on.

[saimo]

@all

I just can't post the results now, but I have a question for the Amiga audio gurus out there.
To scratch a certain itch of mine (which I'll tell you about), today I had to find out the formula that gives the ideal volumes listed at page 163 of the ARHM, and came up with 20*log(AUDxVOL/64) (with log(0) defined as -infinity) - the rounded results match exactly those in the table.
Is the formula correct? If so, how does it relate to the samples amplitude? Maybe it should be 20*log(abs(AUDxDAT/128)*(AUDxVOL/64))?

EDIT: I made a few tests with amplitude 64 and the measured results are not too far off from those given by the formula:
* volume 64: formula -6.021, measured -5.597
* volume 32: formula -12.041, measured -11.823
* volume 8: formula -24.0824, measured -22.958

Big fat note: I didn't remove the weird DC-offset "peaks" that can be seen in the picture included in my post #118, so with proper measurements and equipment the results could be closer.

[Tsak]

Originally Posted by saimo

Yep. Regarding this, I do try to exploit the dynamic range an much as possible, but I don't resort to compression, as I prefer to keep the sound "pure". What I do is manually eliminating all the critical peaks (without distorting the sound). Of course there are limits to this. As a result, for example, the acoustic intro of the demo's music, being naturally quieter, has a lower SNR and thus produces some noise when played with the 14 bit technique.
From the picture of the source 192 kHz 32 bit file you can appreciate the total lack of compression (click for full size):

Yup, I got that while listening to the track
A classic maximizer can do the critical peaks elimination for you automatically. You'd be surprised how much you'll be able to push it before you start actually hearing any distortion or change in quality. I usually do something around -5db with individual samples, you can probably set it even further for a track with zero compression and a wide dynamic range like this one. Overall this single step has yet to disappoint me so far as the difference on the Amiga side tends to be more than profound (especially when it comes to eliminating noise).

As for purity, (and considering the genre) things getting a bit 'dirtier' can very well be a legit artistic choice

[saimo]

Originally Posted by Tsak

Yup, I got that while listening to the track A classic maximizer can do the critical peaks elimination for you automatically. You'd be surprised how much you'll be able to push it before you start actually hearing any distortion or change in quality. I usually do something around -5db with individual samples, you can probably set it even further for a track with zero compression and a wide dynamic range like this one. Overall this single step has yet to disappoint me so far as the difference on the Amiga side tends to be more than profound (especially when it comes to eliminating noise).

Indeed a minimal compression is hard/impossible to notice. It's just that personally I prefer to keep the "perfect" undistorded sound (yeah, I know that perfection can't be reached... it's just me.)

As for purity, (and considering the genre) things getting a bit 'dirtier' can very well be a legit artistic choice

Sure.

[saimo]

Latest findings...

As reported earlier, I had measured a volume discrepancy of -37.035+37.130 = 0.095 dB when playing a full-amplitude sine tone at volume 1 and periods 64 and 50, with the latter giving a louder output (as usual, click the pictures for full size):



I couldn't scratch that difference off my mind, so I thought that maybe I should change the converter to take that into consideration when converting to 14 bits.
First, I asked myself, which virtual volume in the Paula linear scale would give a difference of 0.095 dB against the volume produced by AUDxVOL set to 1, without distortions caused by the period?
Unfortunately the AHRM, at page 163, just provides a table that lists all the <volume, dB> couples. From those numbers, I derived the formula

20*log(AUDxVOL/64)

(with the convention that log(0) = -infinity). I don't know for sure if it's correct, but it provides values that, when rounded, match exactly those in the AHRM.
The question could thus be formulated as follows:

<dB given by the virtual volume x> minus <dB given by volume 1>

i.e.

20*log(x/64) - 20*log(1/64) = 0.095

Doing the maths leads to

x = 10^(0.095/20) = 1.0109973098876536037870941273379.

Let's counter-check:

20*log(1.0109973098876536037870941273379/64) - 20*log(1/64) = -36.028599479677743425648667366939 + 36.123599479677743425648667366939 = 0.095

OK, it works.

Therefore, in theory, the low 6 bits of samples should be somehow scaled down according to a factor of 1.0109973098876536037870941273379.
Uhm... I smell precision issues. Also, which is the relationship between volume (AUDxVOL) and amplitude (AUDxDAT)? It is known that, at least in practice, it is not linear (hence the need to calibrate the 14 bit playback).
I've been pondering a little bit on it and came up with the second formula I already mentioned, i.e. 20*log(abs(AUDxDAT/128)*(AUDxVOL/64)) (about whose correctness I'm all but sure), but before diving deeper I thought I'd better make more precise tests.

Given that the sampled sine tone suffered from a little volume loss in general, I decided to go back to a square tone (as I had intended to anyway):



And here's the same tone sampled from the Amiga:



The last step was to sample the tone playing it at volume 1 with periods 64 and 50. However, this time I put extra care in removing those weird peaks shown in the first picture (they are not really peaks: periodically Paula introduces a little DC offset, and does so for many - if not all - combinations of volume and period). After removing them from a 5 seconds sample, the result was:





I was utterly (and of course pleasantly) surprised that the volumes matched perfectly.

Conclusion: Paula handles the volume regulation surprisingly well (although, as already said, not perfectly) and, at least for the specific case of Hertz Overload, I must no longer worry about extra distortions (not) introduced by period 50.

test samples and pictures download (as usual, sooner or later I'll remove it from the server).

Side note: I've been plugging and unplugging the cable into the PC line-in so many times these days that the jack is becoming a bit loose; I intended to sample also the noise floor of my machine, but I'll refrain from doing that.

[pandy71]

Originally Posted by saimo

Latest findings...

Big question is where some of those distortions are produced - in Paula or in surrounding audio circuitry.
Paula to control signal level use PWM - from one side this is very linear way but on opposite some problems occur related to slew rate.

PWM demand high speed audio signal path (frequency 3.58MHz) - unless your circuitry has symmetric rising/falling edge response then some issues must be expected.

IMHO OPAMP used in Amiga (especially working in I/V converter) are to slow to deal correctly with Paula PWM signal and this may lead to level and non-linear distortions observed.

[saimo]

Originally Posted by pandy71

Big question is where some of those distortions are produced - in Paula or in surrounding audio circuitry.Paula to control signal level use PWM - from one side this is very linear way but on opposite some problems occur related to slew rate.PWM demand high speed audio signal path (frequency 3.58MHz) - unless your circuitry has symmetric rising/falling edge response then some issues must be expected. IMHO OPAMP used in Amiga (especially working in I/V converter) are to slow to deal correctly with Paula PWM signal and this may lead to level and non-linear distortions observed.

I really have no idea of what happens hardware-wise.

[pandy71]

Originally Posted by saimo

I really have no idea of what happens hardware-wise.

My point was that it may be impossible to answer your question without detailed analysis of software and hardware mutual relations - can be tricky.So probably best approach is just accept some outcomes.

[saimo]

Originally Posted by pandy71

My point was that it may be impossible to answer your question without detailed analysis of software and hardware mutual relations - can be tricky.So probably best approach is just accept some outcomes.

Yeah, precisely because I don't have the means to make a deeper and more scientific analysis, I was happy with knowing that Paula does adjust the volume for periods smaller than 64 (and maybe it's just part of the bigger picture: it must adjust also for any period not multiple of 64) and that for the specific case of the demo's period (50) the adjustment is practically perfect.

[saimo]

Hello folks,

after working on some other unrelated internal stuff, polishing, improving and releasing a couple of tools (APEO and TestCode) and, above all, taking the first real vacation in something like 25 years (moved 70 km away from here, on the seaside, 11 full days away from any computer), I finally returned to this - there was still the converter from WAV to 8+6 bits AM data (AQA2 format) left to do.

First of all, I got around to sample and measure my A1200's noise floor.



Over a period of 10 seconds, the highest peak reaches an amplitude of about -49.403 dB. Given that I captured it after booting without startup sequence with the screen set in PAL mode and that the peaks are spaced by about 20 ms, it looks like the peaks are due to some vertical blanking activity performed by the OS - or maybe it's interference from the video signal? Except for the peaks, the noise is very low.
For the record: when the Workbench is loaded, even bigger peaks appear every 5 seconds; I guess that's when the Workbench checks for volumes changes.

As I was saying, I returned to this stuff (mainly) to finally write the tool that converts a 16-bit WAV to the custom 8-bit carrier + 6-bit signal AQA2 file format. That's done now.
The quality of the output is decent, although it's inferior to the classic 14-bit one (after all, it's still 8+8+6 = 22 bits of information for 2 samples, instead of 14+14 = 28 bits).
The quiet intro of the demo's music reveals the noise caused by this method, which is otherwise definitely good for high SNR audio.
To make sure I wasn't screwing anything up, I have also written a little tool that reconstructs the WAV file from the AQA2 file and then I subtracted the reconstructed waveform from the original one: the resulting difference (quantization noise) scored a level of -50.309 dB.
Unsurprisingly, on the real Amiga the noise is more audible than in Audacity or UAE, but still it isn't too bad.

That said, I wonder if the noise is also due to something I'm doing wrong; in case anyone feels like double-checking, here is the converter's core routine:

************************************************************************************************************************
* INFO              Given two 16-bit samples, calculates the corresponding normalized 8-bit samples and the volume to
*                   play them at.
*
* IN                d0.w                signed little-endian 16-bit sample 0
*                   d1.w                signed little-endian 16-bit sample 1
*                   d6.l                32767
*                   a2.l                511
*
* OUT               d0.w                high byte: normalized signed 8-bit sample 0
*                                        low byte: normalized signed 8-bit sample 1
*                   d7.w                volume [0, 64]
*
* TRASH             d1/d2
************************************************************************************************************************

GetVolumeAndSamples

* NOTE
* The idea is to minimize the 8-bit quantization error by normalizing the 16-bit samples to [-32768, 32767] and then by
* playing the normalized samples at a volume that compensates the normalization. For example, an amplitude of -16384
* gets normalized to -32768 (doubled) and then played back at volume 32 (half volume). (Of course, this assumes that
* Paula works linearly, but that is another story.)
* Given that Paula allows volume modulation only per sample pairs, it is necessary to calculate the best volume for
* each pair of samples and then to normalize (or, for want of a better word, scale) them according to the volume found -
* which is what this function does.
*
* Schematically, things work as follows:
*  1. calculate the volume for sample 0;
*  2. calculate the volume for sample 1;
*  3. select the highest volume found;
*  4. scale the samples according to the volume found;
*  5. quantize the samples to 8-bit.
*
* Theoretically, the volume for a sample s can be calculated as follows:
*  1a. positive amplitude: calculate the multiplier m the sample must be theoretically scaled by as 32767/s (hence,
*      s*m = 32767);
*  1b. negative amplitude: calculate the multiplier m the sample must be theoretically scaled by as -32768/s (hence,
*      s*m = -32768);
*  2. calculate the volume v as ceil(64/m).
* The ceil-rounding is needed because, to cope with the integer calculations errors, the samples are not actually scaled
* by m but according to the volume that will be actually used, i.e. by 64/v (in fact, v = 64/m -> m = 64/m). Basically,
* a scaled sample s' is not calculated as s*m, but as (s*64)/v. If v were not ceil-rounded, s' might exceed 16 bits.
* Staying within 16 bits is also the reason why, after the volumes for both samples have been calculated, the highest
* volume gets selected.
*
* Given that m = 32767/s or m = -32768/s and that v = ceil(64/m), v can be calculated as:
*  * s >= 0: v = ceil((s*64)/32767) = (s*64+32766)/32767
*  * s < 0:  v = ceil((s*64)/-32768) = ceil(s/-512) = (-s+511)/512

* Calculate the highest volume for both samples.

                    rol.w               #8,d0               ;make s0 big-endian
                    rol.w               #8,d1               ;make s1 big-endian
                    ext.l               d0
                    ext.l               d1
                    move.l              d0,d2               ;(s0)
                    bsr.b               .CalculateVolume    ;(d2: v0)
                    move.w              d2,d7               ;(v0)
                    move.l              d1,d2               ;(s1)
                    bsr.b               .CalculateVolume    ;(d2: v1)
                    cmp.w               d2,d7
                    bhi.b               .ScaleSamples
                    move.w              d2,d7               ;(v = max(v0, v1))

* Scale the samples according to the volume.

.ScaleSamples       tst.w               d7
                    beq.b               .ZeroSamples        ;if 0 volume...
                    lsl.l               #6,d0               ;(s0*64)
                    lsl.l               #6,d1               ;(s1*64)
                    divs.w              d7,d0               ;(s0' = (s0*64)/v)
                    divs.w              d7,d1               ;(s1' = (s1*64)/v)

* Combine or zero out the samples and exit.
*
* NOTE
* The zeroing out is meant to just favour compression.

                    lsr.w               #8,d1
                    move.b              d1,d0               ;([8-bit s0'][8-bit s1'])
                    rts

.ZeroSamples        clr.w               d0
                    rts

* Calculate the volume to play the sample at.

.CalculateVolume    bmi.b               .HandleNegativeAmplitude                ;if negative amplitude...
                    lsl.l               #6,d2                                   ;(s*64)
                    add.l               d6,d2                                   ;(s*64+32767)
                    subq.l              #1,d2                                   ;(s*64+32766)
                    divu.w              d6,d2                                   ;(v = (s*64+32766)/32767)
                    rts

.HandleNegativeAmplitude
                    neg.l               d2                                      ;(-s)
                    add.l               a2,d2                                   ;(-s+511)
                    lsr.l               #8,d2                                   ;((-s+511)/256)
                    lsr.l               #1,d2                                   ;(v = (-s+511)/512)
                    rts

Finally, I added another conversion tool, improved the tools a little bit and even written a proper manual which, besides the tools usage instructions, also provides information about the period/frequency playback limits and the AQA file formats, and sums up the key results of the tests I hammered you with here.

The archive at https://www.retream.com/_temporary/AQA.lha contains all the abovementioned stuff, plus the WAV and AQA files of the demo music intro, so that you can hear the abovementioned noise for yourself.

[saimo]

I thought I should make more meaningful noise floor measurements.



The top part shows the noise floor when AmigaOS and all the DMA channels are off, and the CPU is simply polling the CIA A PRA register to wait for a mouse click. The highest peak reaches an amplitude of -51.033 dB. The peaks appear at intervals of 20 ms, so, given that the machine is a PAL one connected to a 50 Hz power grid, they must be due to the power input.
The middle part shows the noise floor when sAQA1 streams a completely silent AQA1 file (all samples 0) at 70937.90 Hz (period 50), with the bitplanes, Copper and sprites DMA channels off. The highest peak reaches an amplitude of -53.284 dB.
The bottom part shows the noise floor when sAQA2 streams a completely silent AQA2 file (all samples 0) at 70937.90 Hz (period 50), with the bitplanes, Copper and sprites DMA channels off. The highest peak reaches an amplitude of -54.322 dB. The noise is the same of the AQA1 case, although the Paula registers are used in a different way (in particular, sAQA2 writes to the AUDxVOL registers continuously, while AQA1 writes them only once, before the streaming).

[pandy71]

Something is wrong - this is regular interference - perhaps lost samples or something like this - that's why i hoped for Copper driven audio as it can be more deterministic than CPU.