Hertz Overload - new demo for AGA Amigas

[saimo]

Just a quick heads-up to let you know that I have just released a new demo for AGA Amigas.
This one focuses on delivering very high quality music also on base machines equipped with just a mass storage device (which is needed to stream the huge amount of audio data).
"Very high quality translates" to: 2 true stereo channels, 14 bit resolution and 70937.9 Hz sample rate.

Download: https://www.retream.com/Hertz_Overload / https://retream.itch.io/hertz-overload

Those who can't (bother to) run the demo on an actual Amiga can see it in this video (beware: due to technical reasons, the audio of the video has a sample of rate of just 44100 Hz):

[ Show youtube player ]

[paraj]

Neat! Confirmed working on plain A1200 and B1260, though the extra sound quality is probably lost on my ears/equipment.

[TEG]

The opening screen is very very nice. Great art.

Now the scrolling is a bit too much I think as it cannot be smooth I guess. So we see the limit of the machine. I would use something less demanding.
Perhaps static pages of text with some transition?

[saimo]

Originally Posted by paraj

Neat! Confirmed working on plain A1200 and B1260, though the extra sound quality is probably lost on my ears/equipment.

Thanks for the quick tests and letting me know!
I guess that the extra quality is lost on the ears of many (me included)
To be honest, it would have helped to have a piece of music that's built on instruments of extra quality, but I don't have any professional recording equipment. However, the music has been mixed at 192 kHz and 32 bit float, so that has helped increasing the final quality.
To make tests, I used the 96 kHz piece of music that Sony provides here and I must say that it does sound crystal clear, but in general, besides pushing the Amiga, here we're pushing also human limits.

[saimo]

Originally Posted by TEG

The opening screen is very very nice. Great art.

Do you mean the one which shows my guitar on an azure background? Well, that's just a mix of a photo with a background I made with The Gimp, color-reduced with Personal Paint: while I'm glad you like the result, I honestly don't think that it really qualifies as "art".

Now the scrolling is a bit too much I think as it cannot be smooth I guess. So we see the limit of the machine. I would use something less demanding.
Perhaps static pages of text with some transition?

The scrolling is performed every time a 64 kB chunk of audio data is loaded (so a little less than every second). Maybe it could be done every couple of samples also on a stock A1200, and thus be utterly and uselessly fast. Anything in between would be a problem because the speed management could be done only in the audio interrupt handler, but that must take as little as possible; expanded machines could deal with that easily, but not stock ones (which the demo targets).

Anyway, there's also a design aspect to the scrolling: making it smoother and faster would also make reading harder, but I want people to be able to read the scrolltext without effort, so that their attention can focus on the music. Actually, I've also considered showing no action at all during the playback, but the scroller helps appreciate more what's going on (especially the Hz revelation) and gives a hey-it's-also-showing-moving-graphics effect.

The idea of static pages did not cross my mind. That should be possible also on stock machines, but not with transitions. However, I wouldn't find it as interesting as the scroller.

[pandy71]

Three questions:

- This is DMA or CPU driven?

- Ever considered to use noise shaping to squeeze with such high oversampling more than 16 bit?

- As PWM limit is 56kHz - please share idea behind your 14 bit mode?

[saimo]

Originally Posted by pandy71

- This is DMA or CPU driven?

CPU driven.

- Ever considered to use noise shaping to squeeze with such high oversampling more than 16 bit?

Nope. At some point I basically thought: let's see which rates can be achieved by feeding Paula with the CPU(*) and started hammering code away; then, having more than satisfied my curiosity and tinnitus-plagued ears, I went for a demo. Full story:

The music track "Prockressions" was written while fiddling with the RETREAM
guitar after it got fixed and overhauled. It was not made for the Hertz
Overload, but rather Hertz Overload was made to find a use for it.
Thinking of a way to let others enjoy the music brought the idea of making an
Amiga production, which immediately suggested the creation of a CPU-based player
to achieve a sufficiently high quality. In the past, I had never tried CPU-based
audio playback, but a quick experiment showed that it was doable and quite easy.
That led to the development of a set of tools that process and play WAVE files.
They also proved that the Amiga can reach remarkably high frequencies (much
beyond 70937.9 Hz), which pushed me in another direction: making something more
artistic than a player, and that simply meant... a demo!

Basically, I was more than happy to keep it simple

(*)You and other audio specialists (I'm not one by any means) might find interesting and potentially useful the limits I measured on my Amiga 1200 (both in stock configuration and with the Blizzard 1230 IV activated - the board mounts the standard 68030 clocked at 50 MHz and 60 ns RAM).

When playing exclusively from RAM (so, machine entirely owned, no interrupts), with chipset running in PAL mode and with the core routine also writing to COLOR00 every time it writes to all the AUDxDAT registers to show some visual feedback (smallest period, highest frequency):
* stock Amiga: 12 ticks, 295574.58333... Hz
* expanded Amiga: 10 ticks, 354689.5 Hz
(By removing the write to COLORxx the performance should improve further.)

When streaming from disk, things are trickier, as adding any safety/measurement code to the interrupt handler impacts the performance (heavily); so, tests have to be done this way:
a. checking at which period buffering starts to fail;
b. checking at which period the machine freezes (due to interrupts firing faster than the CPU can handle).
The first test is boring and requires a lot of time, so, at least for the moment being, I avoided it; the second test, which is less meaningful (as buffering starts to fail before the machine freezes) but very easy to do, gave these results:
* stock Amiga: 30 ticks, 118229.8333... Hz
* expanded Amiga: 11 ticks, 322445 Hz

I plan to release shortly the command line tools mentioned in the quote, so that anyone can make tests - and listen to stupidly high frequency music on their Amiga, of course

- As PWM limit is 56kHz - please share idea behind your 14 bit mode?

Just to be clear, regarding the 14 bits I didn't invent anything: I'm just using the good old 8+6 bits method (yes, without calibration - I guess it wouldn't be nice to ask a user to perform audio calibration just to watch a demo).
As for the frequency, I didn't invent anything: the CPU simply feeds Paula with the samples, so the limit is reached when the CPU can't manage anymore to provide Paula with new samples in time while Paula loops between states 010 and 011.

[Damion]

Hey saimo!

I don't have golden ears (and what I have left is also tinnitus stricken), though I can absolutely hear the difference - particulalry the sound of fingers sliding across the strings when the second guitar layer comes in (it's significantly clearer/more audible in the second example).

No special audio gear for this test, just an A1200 with an intact audio circuit

[pandy71]

Originally Posted by saimo

CPU driven.

Thx Saimo, clear.

Originally Posted by saimo

Nope. At some point I basically thought: let's see which rates can be achieved by feeding Paula with the CPU(*) and started hammering code away; then, having more than satisfied my curiosity and tinnitus-plagued ears, I went for a demo.

Ok, i see - my point is probably best explained by quotation of some conclusion from famous Vanderkooy and Lipshitz paper (https://sjeng.org/ftp/SACD.pdf) on SACD inherited flaws:

Finally, consider 8-bit, four-times-oversampled PCM with
noise shaping. This is also a data rate one-half that of DSD and
double that of CD, with a sampling rate of 4 × 44,100 =
176,400 Hz. It can achieve a noise floor 120 dB below full
scale up to 20 kHz, using 96 dB of noise shaping, and a total
noise power of –19 dBFS. Its frequency response would be
flat to 80 kHz. This example is perhaps the most instructive of
the lot. For a data rate one-half that of DSD, it achieves a
comparable signal bandwidth, with a similar noise power
density up to 20 kHz, but much lower power above this
frequency, and 28 dB lower total noise power. It is fully
TPDF-dithered, and so is completely artefact free. At one-half
the data rate it outperforms DSD on every count! DSD is a
profligate wastrel of capacity.

So by using 8 bit PCM (thus avoiding problems with 14 bit trick and how volume regulation work in Paula) with noise shaping dynamics over 120dB can be achieved and way better characteristic. So using sufficiently high oversampling like in case of your demo with properly noise shaped 8 bit PCM samples Paula should offer dynamics better than 14 bits.

Originally Posted by saimo

Full story:

The music track "Prockressions" was written while fiddling with the RETREAM
guitar after it got fixed and overhauled. It was not made for the Hertz
Overload, but rather Hertz Overload was made to find a use for it.
Thinking of a way to let others enjoy the music brought the idea of making an
Amiga production, which immediately suggested the creation of a CPU-based player
to achieve a sufficiently high quality. In the past, I had never tried CPU-based
audio playback, but a quick experiment showed that it was doable and quite easy.
That led to the development of a set of tools that process and play WAVE files.
They also proved that the Amiga can reach remarkably high frequencies (much
beyond 70937.9 Hz), which pushed me in another direction: making something more
artistic than a player, and that simply meant... a demo!

Basically, I was more than happy to keep it simple

(*)You and other audio specialists (I'm not one by any means) might find interesting and potentially useful the limits I measured on my Amiga 1200 (both in stock configuration and with the Blizzard 1230 IV activated - the board mounts the standard 68030 clocked at 50 MHz and 60 ns RAM).

When playing exclusively from RAM (so, machine entirely owned, no interrupts), with chipset running in PAL mode and with the core routine also writing to COLOR00 every time it writes to all the AUDxDAT registers to show some visual feedback (smallest period, highest frequency):
* stock Amiga: 12 ticks, 295574.58333... Hz
* expanded Amiga: 10 ticks, 354689.5 Hz
(By removing the write to COLORxx the performance should improve further.)

When streaming from disk, things are trickier, as adding any safety/measurement code to the interrupt handler impacts the performance (heavily); so, tests have to be done this way:
a. checking at which period buffering starts to fail;
b. checking at which period the machine freezes (due to interrupts firing faster than the CPU can handle).
The first test is boring and requires a lot of time, so, at least for the moment being, I avoided it; the second test, which is less meaningful (as buffering starts to fail before the machine freezes) but very easy to do, gave these results:
* stock Amiga: 30 ticks, 118229.8333... Hz
* expanded Amiga: 11 ticks, 322445 Hz

Ok, clear, thx for explanation - probably with oversample higher than 100kHz Paula will offer more than 16 bit dynamics.
8 bit simplify other things too and of course reduce CPU load and storage space.

Originally Posted by saimo

I plan to release shortly the command line tools mentioned in the quote, so that anyone can make tests - and listen to stupidly high frequency music on their Amiga, of course

Great - it will be very interesting to search for Paula limit.

Originally Posted by saimo

Just to be clear, regarding the 14 bits I didn't invent anything: I'm just using the good old 8+6 bits method (yes, without calibration - I guess it wouldn't be nice to ask a user to perform audio calibration just to watch a demo).
As for the frequency, I didn't invent anything: the CPU simply feeds Paula with the samples, so the limit is reached when the CPU can't manage anymore to provide Paula with new samples in time while Paula loops between states 010 and 011.

Ok, in past i had idea to try pseudo DMA ultrahigh sample rate - set normally not supported very high audio period and feed buffer with CPU or Copper to remove jitter related to interrupts and other factors (my naive assumption was that based on Paula state machine, last 2 samples are repeated constantly if DMA is unable to deliver new samples required by to high sample rate). This probably not work at all but i recall on EAB some Paula Copper driven high sample rate example (few years ago).
Perhaps this can be next step for someone being inspired by your demo.

Thank you very much!
*And btw i'm not particular audio specialist - this is just general knowledge if people are quite happy with SACD then why not use Paula to be better than SACD - having sufficiently fast CPU (DSP) even 8 bit PCM Paula can be HQ audio source (please ignore other issues with audio signal path in Amiga - some of them can be fixed).

[hammer]

Originally Posted by saimo

Just a quick heads-up to let you know that I have just released a new demo for AGA Amigas.
This one focuses on delivering very high quality music also on base machines equipped with just a mass storage device (which is needed to stream the huge amount of audio data).
"Very high quality translates" to: 2 true stereo channels, 14 bit resolution and 70937.9 Hz sample rate.

Download: https://www.retream.com/Hertz_Overload / https://retream.itch.io/hertz-overload

Those who can't (bother to) run the demo on an actual Amiga can see it in this video (beware: due to technical reasons, the audio of the video has a sample of rate of just 44100 Hz):

[ Show youtube player ]

Can high-frequency CPU-driven Paula work with non-ECS Amiga (with RTG display)?

[malko]

Watched the video. Nice demo
Cool music as well as unusual "non black" colours for such music.
Had fun watching it

PS: agree that scrolling speed allows easy reading without losing focus on audio.

[TEG]

Originally Posted by saimo

Do you mean the one which shows my guitar on an azure background? Well, that's just a mix of a photo with a background I made with The Gimp, color-reduced with Personal Paint: while I'm glad you like the result, I honestly don't think that it really qualifies as "art".

I mean the whole. The guitar colour with the blue background an then the Amiga logo with the patchwork of pieces of colours.

I really like the rendering, the harmony of colours and it struck me when I saw it.

Originally Posted by saimo

Anyway, there's also a design aspect to the scrolling: making it smoother and faster would also make reading harder, but I want people to be able to read the scrolltext without effort, so that their attention can focus on the music. Actually, I've also considered showing no action at all during the playback, but the scroller helps appreciate more what's going on (especially the Hz revelation) and gives a hey-it's-also-showing-moving-graphics effect.

I was thinking in part of the opposite: slowing down even more the speed of the scrolling to favour the smoothing.

Originally Posted by saimo

The idea of static pages did not cross my mind. That should be possible also on stock machines, but not with transitions. However, I wouldn't find it as interesting as the scroller

I think there's some transitional effects which are less big eater than other. I was thinking of when pixels text dissolve for example.

[saimo]

Originally Posted by pandy71

So by using 8 bit PCM (thus avoiding problems with 14 bit trick and how volume regulation work in Paula) with noise shaping dynamics over 120dB can be achieved and way better characteristic. So using sufficiently high oversampling like in case of your demo with properly noise shaped 8 bit PCM samples Paula should offer dynamics better than 14 bits.

It should be easy to try. Could you recommend any software that performs quantization applying noise shaping? I use (an old version of) Audacity and it only provides dithering.

Ok, clear, thx for explanation - probably with oversample higher than 100kHz Paula will offer more than 16 bit dynamics.8 bit simplify other things too and of course reduce CPU load and storage space.

It would definitely reduce the CPU load, as only 2 AUDxDAT registers instead of 4 would need to be written at a time - or, with the same CPU load, even higher frequencies can be reached also on stock machines.

Great - it will be very interesting to search for Paula limit.

I just have to find the time to make a little addition to the custom (and totally simple) file format I designed for the speedy playback and to write the documentation. I might take a while as these days I'm suffering particularly with sleep deprivation (and, yes, working on this stuff doesn't help ).

Ok, in past i had idea to try pseudo DMA ultrahigh sample rate - set normally not supported very high audio period and feed buffer with CPU or Copper to remove jitter related to interrupts and other factors (my naive assumption was that based on Paula state machine, last 2 samples are repeated constantly if DMA is unable to deliver new samples required by to high sample rate). This probably not work at all but i recall on EAB some Paula Copper driven high sample rate example (few years ago).Perhaps this can be next step for someone being inspired by your demo.

Copper-driven audio must be incredibly expensive, as the Copperlist would have to be updated by the CPU and then there is the load of Copper executing the code itself. 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.

*And btw i'm not particular audio specialist - this is just general knowledge if people are quite happy with SACD then why not use Paula to be better than SACD - having sufficiently fast CPU (DSP) even 8 bit PCM Paula can be HQ audio source (please ignore other issues with audio signal path in Amiga - some of them can be fixed).

To get an idea of my ignorance in the subject matter, just think that I had never even heard of SACD and noise shaping!

[saimo]

Originally Posted by hammer

Can high-frequency CPU-driven Paula work with non-ECS Amiga (with RTG display)?

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.

[saimo]

Originally Posted by malko

Watched the video. Nice demo Cool music as well as unusual "non black" colours for such music. Had fun watching it

Glad to hear, thanks.
The music is more on the prog* than on the heavy side, so it doesn't "require" a dark theme... but it wouldn't have gotten it anyway, as I'm not a "dark" person.
*The name also hints at that, although it originates from "rock" + "progressions", as it's built on several chords progressions.

PS: agree that scrolling speed allows easy reading without losing focus on audio.

[saimo]

Originally Posted by TEG

I mean the whole. The guitar colour with the blue background an then the Amiga logo with the patchwork of pieces of colours.I really like the rendering, the harmony of colours and it struck me when I saw it.

Ah, OK. Of course I'm more than happy that you liked that (I did invest time to achieve a pleasant result)

I was thinking in part of the opposite: slowing down even more the speed of the scrolling to favour the smoothing.

The scrolling can't be made slower and smoother: it's done 1 pixel at a time and can't be made smoother than that (well, unless interlacing were used, but then the flickering would come with it - which would be much worse).

I think there's some transitional effects which are less big eater than other. I was thinking of when pixels text dissolve for example.

On a stock machine there is no time for graphical operations, as the CPU is entirely busy with playing the music.

[pandy71]

Originally Posted by saimo

It should be easy to try. Could you recommend any software that performs quantization applying noise shaping? I use (an old version of) Audacity and it only provides dithering.It would definitely reduce the CPU load, as only 2 AUDxDAT registers instead of 4 would need to be written at a time - or, with the same CPU load, even higher frequencies can be reached also on stock machines.

For best results it should be dedicated application to match Paula specifics - firstly sample rate conversion and secondly requantization with applied dithering and noiseshaping.
SoX offers HQ sample rate conversion and also noiseshaping (ffmpeg also reuese sample rate conversion and noise shaping code from SoX with some changes) but noise shaping is limited to narrow set of sampling frequencies (most common like 44.1 and 48kHz).

As example ffmpeg implementation ( filter coefficients for various sampling frequencies - https://ffmpeg.org/doxygen/7.0/noise...8c_source.html ) - usually for best results noise shaping push quantization noise from most important areas to less important part of spectrum - with high oversampling most of noise shaped quantization noise is placed in inaudible part of spectrum were it can be relatively easily filtered by lowpass filtering.

SoX and some of ffmpeg noise shaping curves are visible on this graph:





Source: https://web.archive.org/web/20201112...X/NoiseShaping

Alternatively there is java application(s) to design noiseshaping filter and apply re-quantization written by Sebastian Gesemann ( https://hydrogenaud.io/index.php/topic,47980.0.html ) - not sure if this application can be still downloaded so i will upload it to The Zone. https://eab.abime.net/zone/noise.zip
This application support limited set of sample rates but this should be not a problem as frequency transposition can be applied easily (not sure if i use correct terminology but principle is simple - if you designing filter for for example 64kHz and your real sample rate is for example 72khz then filter with notch at for example 1kHz in samplerate 64kHz will be notch at 1.125kHz for signal sampled at 72kHz (72/64).
That's why dedicated Paula application would be best best also existing applications can be used with remark that spectrum response will be shifted.

Originally Posted by saimo

I just have to find the time to make a little addition to the custom (and totally simple) file format I designed for the speedy playback and to write the documentation. I might take a while as these days I'm suffering particularly with sleep deprivation (and, yes, working on this stuff doesn't help ).

No rush on this - for me this is simply interesting for one thing (ok two things) first i need to be able inject into Paula some HQ sample data stream to verify improvements made in analog signal path (i will try if time allow to improve overall Paula environment, signal integrity, perhaps canceling external noise etc) and secondly just curiosity how much you can push boundaries for design over 35 year old. Probably ongoing year will be quite busy for me anyway (trying to finish building home so i can finally get my Amiga's unpacked and do something more productive than writing endless dispute texts about superiority of Easter over Christmas).

Originally Posted by saimo

Copper-driven audio must be incredibly expensive, as the Copperlist would have to be updated by the CPU and then there is the load of Copper executing the code itself. 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 require to start the playback in a way that all the channels are perfectly in sync.

Issue with audio is jitter - can be audible and it is easily measurable - even small irregularity in feeding audio samples with lead to distortions - Copper and eventually re-using DMA like Paula mechanism may help to reduce jitter.

Originally Posted by saimo

To get an idea of my ignorance in the subject matter, just think that I had never even header of SACD and noise shaping!

Noise shaping you hear for sure everyday - introducing dither and noise shaping was break trough for restoring "analog sound" for CD's - before 1990 lot of people complains on "metallic' CD sound and it was true - by introducing dither quantization noise can be decorrelated form audio signal (at a cost of elevated noise floor - approx 5dB lower SNR), by introducing noiseshaping, quantization noise can be removed from most sensitive (for us) part of spectrum so 16 bit recordings can sound like 20..23 bit ones.
One of the first noise shapers used widely was Sony SBM https://en.wikipedia.org/wiki/Super_...useskin=vector - for sure if you had CD bought in in first half of 90's then one of similar solutions was there. And SACD is ridiculous concept to store on CD plate 64 times oversampled 1 bit audio. Nowadays oversampling ratios are way higher - known as DSD64 for ordinary SACD but common are DSD512 or even DSD2048 ( "audiophile" formats ) - anyway paper from Vanderkooy and Lipshitz showed problems with SACD - Paula is not 1 bit but 8 bit so noise shaping is way easier to be used - nowadays most of audio DAC's are anyway few bit noiseshaped one (less than 1% of all audio DAC's has more than 5 bits resolution). So we all hear dither and noise shaped audio everyday around us.
Paula with 8 bit PCM signal should be way better at moderate oversampling - 4 times will be overkill anyway - probably better than 14 bit (in real life rarely 14 bit is more than 11 bits on Paula).
Btw to reduce storage space trick with 16 bit to 8 bit quick compression described here https://hydrogenaud.io/index.php/topic,121181.0.html can be applied - 256 word table - in Amiga it can be scaled to match 14 bit DAC resolution.

[saimo]

Originally Posted by Damion

Hey saimo!I don't have golden ears (and what I have left is also tinnitus stricken), though I can absolutely hear the difference - particulalry the sound of fingers sliding across the strings when the second guitar layer comes in (it's significantly clearer/more audible in the second example).No special audio gear for this test, just an A1200 with an intact audio circuit

I had missed this post!
Thank you for the feedback

[saimo]

@pandy71

Regarding noise shaping: thanks for the wealth of information! It looks like there's quite a lot of study and experimenting for me to do, but that's something I can't afford right now (and for the foreseeable future, as I have various projects in the pipeline).

Originally Posted by pandy71

Issue with audio is jitter - can be audible and it is easily measurable - even small irregularity in feeding audio samples with lead to distortions - Copper and eventually re-using DMA like Paula mechanism may help to reduce jitter.

I hope you're referring to the requirement of clearing INTREQ.AUDx and writing AUDxDAT before percount expires when Paula is in state 011 and not to some obscure aspect of Paula I don't know. In the former case, as long as those two operations are done in time, no jitter should occur (as Paula feeds the DACs with the data from the internal buffers it reloads from AUDxDAT when percount expires); if they are not done in time, yes, Paula would continuously stop and restart after the CPU-induced delay and the result would be terrible.
In the specific case of the demo and of the tool that streams data from disk, given that the OS must remain active (to use dos.library), interrupts caused by some system activity (expansion hardware sending requests, Blitter, etc.) might/will disrupt the playback but, on the other hand, these applications are not meant to be used when the machine is doing also other stuff (they do call Forbid(), but that can't help with interrupts and, anyway, might be broken by Read()).
Side note: using DMA, given the channels CHIP bus slots, sounds like a nightmare to me.

Btw to reduce storage space trick with 16 bit to 8 bit quick compression described here https://hydrogenaud.io/index.php/topic,121181.0.html can be applied - 256 word table - in Amiga it can be scaled to match 14 bit DAC resolution.

Compression might be an option for 68030+ (and depending on the playback frequency), but saving disk space was not a concern relatively to these experiments (after all, the data will end up using a lot of space anyway).

[pandy71]

Originally Posted by saimo

@pandy71Regarding noise shaping: thanks for the wealth of information! It looks like there's quite a lot of study and experimenting for me to do, but that's something I can't afford right now (and for the foreseeable future, as I have various projects in the pipeline).

No worries - this is probably something with relatively low priority and there are possible some workarounds (more manual work).Perhaps with clever coding (fixed point arithmetic, careful scaling) some simple real time noise shaping could be made so Paula can be feed with true 16 bit audio samples and play them as oversampled 8 bit noiseshaped with quality same or very close to source.

Originally Posted by saimo

I hope you're referring to the requirement of clearing INTREQ.AUDx and writing AUDxDAT before percount expires when Paula is in state 011 and not to some obscure aspect of Paula I don't know. In the former case, as long as those two operations are done in time, no jitter should occur (as Paula feeds the DACs with the data from the internal buffers it reloads from AUDxDAT when percount expires); if they are not done in time, yes, Paula would continuously stop and restart after the CPU-induced delay and the result would be terrible.In the specific case of the demo and of the tool that streams data from disk, given that the OS must remain active (to use dos.library), interrupts caused by some system activity (expansion hardware sending requests, Blitter, etc.) might/will disrupt the playback but, on the other hand, these applications are not meant to be used when the machine is doing also other stuff (they do call Forbid(), but that can't help with interrupts and, anyway, might be broken by Read()).Side note: using DMA, given the channels CHIP bus slots, sounds like a nightmare to me.

Yep, problem is that with high sample rates CPU may stall and miss proper time slot so risk of loosing samples.

Originally Posted by saimo

Compression might be an option for 68030+ (and depending on the playback frequency), but saving disk space was not a concern relatively to these experiments (after all, the data will end up using a lot of space anyway).

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