Hertz Overload - new demo for AGA Amigas

[saimo]

Originally Posted by pandy71

Compression is just reading from 256 word table value (but overall data to be moved reduced by half from storage device).

Ah, OK, then that might help on 68020, too.

[Torti-the-Smurf]

Great Stereo Panning !

Very cool stuff Saimo

[copse]

Originally Posted by saimo

I can see the benefit of allowing the CPU not to care about synchronization with Paula, though. By the way, the Copper is a key part of my implementation as it is strictly required to start the playback in a way that all the channels are perfectly in sync.

Is there any chance you could elaborate on this? Thanks!

[saimo]

Originally Posted by copse

Is there any chance you could elaborate on this? Thanks!

Quick answer during a break at work...
It is strictly necessary that all the channels operate in perfect sync. However, there's no way to start all of them at the same time due to the fact that they start when the AUDxDAT registers are written to, and neither the CPU, nor Copper, nor Paula itself via DMA (due to the CHIP bus slots allocation) can do that. CPU-wise things are even more complicated because the access timings vary depending on the CPU and on the expansion board.
Therefore, I resorted to the method illustrated in the code below, which is a snippet of the Copperlist that gets executed only once and when no bitplane DMA is going on.

* Set the periods to values decreasing by 4 ticks to compensate the fact that the channels are started with a difference
* of 4 color clocks by the writes to AUD*DAT below here - thanks to such periods, all the channels will end playing the
* first samples at the same time, thus synchronizing the playback of the following samples.
*
* NOTE
* a) The synchronization must be done by the Copper as tests showed that the stock Amiga and the expanded Amiga have
*    different access times to the chipset registers (i.e. the writes to AUD*DAT would happen at different and possibly
*    irregular times).
* b) The periods are such that they can be comfortably fixed later (see below).

    dc.w    RO_AUD0PER,400
    dc.w    RO_AUD1PER,396
    dc.w    RO_AUD2PER,392
    dc.w    RO_AUD3PER,388

* Wait for a color clock beyond the memory refresh slots.

    dc.w    $00e1,$80fe
    dc.w    $0011,$80fe

* Clear the AUD* interrupt requests and enable the AUD0 interrupt.

    dc.w    RO_INTREQ,$0780
    dc.w    RO_INTENA,$8080

* Start the channels with null samples.
*
* NOTE
* This causes the transition 000 -> 010. Before the samples finish playing (i.e. before the 011 -> 010 transition), the
* proper periods must be set so that: the next samples will be played at the right frequency; the channels will restart
* at the same time. Initially Paula loads the internal period counters from AUD*PER after the writes to AUD*DAT (i.e at
* transition 000 -> 010), so writing AUD*PER before the transition 011 -> 010 (when AUD*PER will be read again) has no
* no immediate effect.

    dc.w    RO_AUD0DAT,0
    dc.w    RO_AUD1DAT,0
    dc.w    RO_AUD2DAT,0
    dc.w    RO_AUD3DAT,0

* Fix the periods.

Copperlist_FP    dc.w    RO_AUD0PER,PERIOD
    dc.w    RO_AUD1PER,PERIOD
    dc.w    RO_AUD2PER,PERIOD
    dc.w    RO_AUD3PER,PERIOD

EDIT: lately the forum handling of line feeds has stopped working; I can't paste the code in a readable way, not even with quote tags.

[hammer]

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 (I never heard a non-AGA Amiga in person, so I can't say), so that would kind of defy the trick. Another downside is that the slower CHIP bus would limit the maximum frequency when graphics are shown.

I was thinking about a high-frequency non-DMA AHI driver for non-ECS Paula with an RTG display. The CPU power is provided by Emu68.

I have both A1200 rev1d4 and A500 rev6A.

[saimo]

Regarding the bottom note in my previous post: editing the post to add that note magically fixed the code! I don't dare touching that post again.

@hammer

Originally Posted by hammer

I was thinking about a high-frequency non-DMA AHI driver for non-ECS Paula with an RTG display. The CPU power is provided by Emu68. I have both A1200 rev1d4 and A500 rev6A.

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.

[klx300r]

@ saimo

sweet Demo! I can really here the quality of the music when played through my amp and 14" old school Boston Acoustics speakers

[saimo]

@klx300r

Thank you (also for the tests on your 68060 machines)

@all

Some remarks by Gunnar in this thread on AmigaWorld made me realize a major flaw of this playback method - quoting myself:

But I have to thank you for insisting because you opened my eyes: happy with the basic thought that the volumes would keep working as usual, I had not considered the implications relatively to the low 6 bits playback!
[Thinking aloud]
There's no problem with the high 8 bits as those are sent to the DACs continuously, but the 6 bits are supposed to be played back with a volume of 1, i.e. they should be sent to the DACs only once every 64 clocks. Paula does not reload the volume counters between the 010 and 011 transitions, so that means that the internal volume counters just loop from 63 to 0 continuously. However, for the demo the period is set to 50 clocks, so the reloading of the output buffers and the sending of their data to the DACs go out of phase! In practice, the high byte and the corresponding low byte go to the DAC in sync only partially and the rest of the time the high byte gets played in conjuction with the previous (and sometimes next-to-previous) low byte (which thus acts as a sort of random dithering)! This is bad and effectively limits the period to 64 clocks (for use with volumes less than 64, that is).

In short, for 14-bit playback the period should not be less than 64. For higher periods, it looks like noise shaping is the way to go...
Any thoughts?

EDIT: line feeds are becoming a serious problem; I'm using FireFox.

[roondar]

Quite a cool demo, thanks for sharing it
Also, that Copper-synchronisation trick is pretty cool!

May I ask how you figured out the exact values? Calculation or experimentation?

[saimo]

Originally Posted by roondar

Quite a cool demo, thanks for sharing it

My pleasure

Also, that Copper-synchronisation trick is pretty cool! May I ask how you figured out the exact values? Calculation or experimentation?

The absolute values don't really matter, as long as the Copper subsequently has enough time to set the correct ones. It's sufficient that they're spaced by 4 cycles, i.e. the time that the Copper needs to perform each write (and, as you can see, I've been extremely generous).

[roondar]

Originally Posted by saimo

My pleasure The absolute values don't really matter, as long as the Copper subsequently has enough time to set the correct ones. It's sufficient that they're spaced by 4 cycles, i.e. the time that the Copper needs to perform each write (and, as you can see, I've been extremely generous).

Ahhh, I see. I misread the Copperlist's comments and your explanation. The first 4 writes to AUDxPER you do aren't actually the period values you need, they just need to be high enough and have at least a difference of 4 each.

Then, the synchronisation happens and lastly the desired actual period values get written.

Thanks for explaining it

[pandy71]

Originally Posted by saimo

@allSome remarks by Gunnar in this thread on AmigaWorld made me realize a major flaw of this playback method - quoting myself: In short, for 14-bit playback the period should not be less than 64. For higher periods, it looks like noise shaping is the way to go...Any thoughts?EDIT: line feeds are becoming a serious problem; I'm using FireFox.

So it was my 3rd question about 14 bit mode and how you implemented it if audio period is shorter than 64 clocks. Signal need to be averaged over time so in theory sample period should be at least 64 or better 128 (Nyquist rate).Yep, there is some issue with linefeed on forum - CR/LF is removed by forum engine.

[saimo]

Originally Posted by pandy71

So it was my 3rd question about 14 bit mode and how you implemented it if audio period is shorter than 64 clocks.

I see. I had not connected your question to the volume issue (because I had not yet thought about the volume!)

Due to this last realization, I've spent the afternoon looking into dithering and noise shaping. I have downloaded a number of tools and made a few tests (I've just finished) by reducing the original 32-bit float waveform to 8 bits, keeping the 192 kHz rate. These are the results, quantization noise-wise:
* Audacity, with all its dithering methods (including shaping): very audible;
* foobar2000 (https://www.foobar2000.org), which offers a SSRC resampler: very audible;
* Acoustica (https://acondigital.com/products/acoustica), with the 8 bit aggressive noise shaping (the others are worse): better than the ones above, but still distinctly audible;
* Reaper (https://www.reaper.fm) - barely audible at 176400 Hz; beyond my (poor ears) perception at 192000 Hz.

Apart from the very last case, none of the other tests comes even close to the (albeit flawed) 14-bit playback (at the much lower rate of about 70938 Hz) as regards quality. Of course I'm a total noob, so somebody with experience and proper tools might achieve better results, but, on the other hand, only Acoustica provides configuration options, so... maybe there's only so much that can be done with 8 bits? Make no mistake, I'm impressed that 8 bits can sound so good at 192 kHz, but that's too taxing for a poor stock A1200.

[Karlos]

Is it possible to use the CPU to drive the volume control in tandem with an 8 bit stream? Maybe a volume modulated, preprocessed 8 bit stream could sound better than a vanilla 8-bit one at fixed volume. This is a variation on an idea I had a long time ago that was to be based on channel modulation.

[saimo]

Originally Posted by Karlos

Is it possible to use the CPU to drive the volume control in tandem with an 8 bit stream? Maybe a volume modulated, preprocessed 8 bit stream could sound better than a vanilla 8-bit one at fixed volume. This is a variation on an idea I had a long time ago that was to be based on channel modulation.

Ah, yes, I remember when you first mentioned this (I think it was on Amigaworld)! And the idea did cross my mind briefly while making this stuff, but I decided to go the easiest route as I just did not think about the implications relative to the volume counters.
That said, I'm not sure that your idea is feasible: according to the audio state diagram on the AHRM, the volume counter does not get reloaded when it's the CPU that writes to AUDxDAT - and that sounds plausible, otherwise, at volume 1, the low 6 bits would never be heard and the demo music wouldn't sound so good (especially the coda, where the signal is so weak that it would drown in the 8 bit quantization noise); on the other hand, in DMA mode, the volume counters do get reloaded, so it would be natural and much cheaper to keep the same behaviour... I don't know, but I'll make a few tests right away and see what the actual behaviour is.

Edit: given the result of the tests, your idea should be definitely doable and should work great at 3546895/64 = 55420 Hz also, it just occurred to me that I implemented the same concept to remove the noise at the end of the music of my other demo THE CURE: the music there is just 8-bit and its clean guitar arpeggio at the end would be totally noisy without volume control (but the solution there is really basic and rough: from a certain point on to the very end, I amplified linearly the waveform from 100% to the maximum and then the code performs the fade-out by decreasing AUDxVOL).

[saimo]

@Karlos

I just did a couple of quick tests:
1. writing to AUDxVOL the low 6 bits (which is basically what the player based on your idea would do): the sound was totally distorted, which proves that the volume counters do get reloaded also in non-DMA mode;
2. setting AUDxVOL to 0 for the low 6 bits channels: even my poor ears could hear the quantization noise!

What gives?!?

Edit: could it be that Paula scales the internal volume counters to the period value, when the latter is less than 64? how can the fact that a volume of 1 works (or at least has a certain effect) when the period is less than 64?

[pandy71]

Originally Posted by saimo

I see. I had not connected your question to the volume issue (because I had not yet thought about the volume!) Due to this last realization, I've spent the afternoon looking into dithering and noise shaping. I have downloaded a number of tools and made a few tests (I've just finished) by reducing the original 32-bit float waveform to 8 bits, keeping the 192 kHz rate. These are the results, quantization noise-wise: * Audacity, with all its dithering methods (including shaping): very audible; * foobar2000 (https://www.foobar2000.org), which offers a SSRC resampler: very audible; * Acoustica (https://acondigital.com/products/acoustica), with the 8 bit aggressive noise shaping (the others are worse): better than the ones above, but still distinctly audible; * Reaper (https://www.reaper.fm) - barely audible at 176400 Hz; beyond my (poor ears) perception at 192000 Hz.Apart from the very last case, none of the other tests comes even close to the (albeit flawed) 14-bit playback (at the much lower rate of about 70938 Hz) as regards quality. Of course I'm a total noob, so somebody with experience and proper tools might achieve better results, but, on the other hand, only Acoustica provides configuration options, so... maybe there's only so much that can be done with 8 bits? Make no mistake, I'm impressed that 8 bits can sound so good at 192 kHz, but that's too taxing for a poor stock A1200.

In free time i will try to prepare samples for you to test various approaches.8 bit at 176kHz should deliver 120dB dynamics range - of course Paula itself will be limitation (PCB layout, internal IC layout, I/V converter can be probably to slow so some distortions related to PWM VOL control are probably also key to distortions we observing now).I will also apply some premhpasis to deal with internal Amiga analog signal path problems (low pass filters).It is important to lowpass signal beyond audible range as high level of noise shaping (aggressive noise shaping) may produce some sonic distortions (also there is a chance to ruin tweeters if they are forced to work with high power - normally such high level of signal is not present in natural audio). I strongly recommends to reduce trebles especially for better amplifiers and better speakers. And this is normal for all high sample rate signals - they can produce sonic distortions if not properly bandlimited.

I will try to use 64489Hz sample rate (close to two times oversampled 32kHz) - personally not hear anything above 15kHz.

[saimo]

Originally Posted by pandy71

In free time i will try to prepare samples for you to test various approaches.8 bit at 176kHz should deliver 120dB dynamics range - of course Paula itself will be limitation (PCB layout, internal IC layout, I/V converter can be probably to slow so some distortions related to PWM VOL control are probably also key to distortions we observing now).I will also apply some premhpasis to deal with internal Amiga analog signal path problems (low pass filters).It is important to lowpass signal beyond audible range as high level of noise shaping (aggressive noise shaping) may produce some sonic distortions (also there is a chance to ruin tweeters if they are forced to work with high power - normally such high level of signal is not present in natural audio). I strongly recommends to reduce trebles especially for better amplifiers and better speakers. And this is normal for all high sample rate signals - they can produce sonic distortions if not properly bandlimited.
I will try to use 64489Hz sample rate (close to two times oversampled 32kHz) - personally not hear anything above 15kHz.

That would be great
In turn, tomorrow I'll prepare a modifed version of the playback tool that simply plays 8 bit data, so that anybody can make tests.

Edit: relatively to the dither + noise shaping tests, I forgot to mention that I listened to the resulting waveforms directly on the PC where the processing was done, not on the Amiga (so the results were not affected by the Amiga's hardware).

[copse]

Originally Posted by saimo

It is strictly necessary that all the channel operate in perfect sync. However, there's no way to start all of them at the same time due to the fact that they start when the AUDxDAT registers are written to, and neither the CPU, nor Copper, nor Paula itself via DMA (due to the CHIP bus slots allocation) can do that. CPU-wise things are even more complicated because the access timings vary depending on the CPU and on the expansion board.

As a noob it makes me wonder how do all the other music playing routines on the Amiga deal with this? Is it not relevant for them for some reason? Or is this something that becomes obvious to the ear when dealing with your higher resolution data?

[Karlos]

Originally Posted by saimo

@Karlos

I just did a couple of quick tests:
1. writing to AUDxVOL the low 6 bits (which is basically what the player based on your idea would do): the sound was totally distorted, which proves that the volume counters do get reloaded also in non-DMA mode;
2. setting AUDxVOL to 0 for the low 6 bits channels: even my poor ears could hear the quantization noise!

What gives?!?

Edit: could it be that Paula scales the internal volume counters to the period value, when the latter is less than 64? how can the fact that a volume of 1 works (or at least has a certain effect) when the period is less than 64?

That doesn't seem likely. Surely, when the volume is set to zero, there shouldn't be any sound to hear at all?

I'm not sure if the concept is still clear, so just to recap, the original idea was that your source 16 bit audio (for example) would be preprocessed into a set of frames (minimum size of 2 samples) of 8 bit that have been scaled so that it can be played back at a particular volume to re-approximate what the 16 bit sample levels would be. This 2:1 sample to volume data rate was a side effect of how channel modulation works and the fact that Paula DMA fetches 16 bits. My original experiments were all in pure software and used a bigger ratio, e.g 16:1 as this reduces the stream size quite a bit and didn't degrade the output too much.

Paraj (or another gentleman of quality) did implement the proposed HW playback mechanism in a prototype, which sounded pretty good to me, but unfortunately, that was all under emulation as my real HW is not currently in a working state.