AUDxPER for maximum playback rate

[meynaf]

Originally Posted by pandy71

you are so young meynaf, so impatient...

I am not young and i am not a padawan.
And impatient ? It just looked like tails I win, heads we continue playing. Is that fair ?
But now i have a delay so it's significantly better.
So be a gentle boy and wait for next year, just like the others.

[pandy71]

Originally Posted by meynaf

I am not young and i am not a padawan.

You are younger than ross or me so you are young and you can't argue with this (unless you are math denial).

Originally Posted by meynaf

And impatient ? It just looked like tails I win, heads we continue playing. Is that fair ?
But now i have a delay so it's significantly better.
So be a gentle boy and wait for next year, just like the others.

I'm gentle - soon programmers even highly skilled will be obsolete - replaced by machine learning mambo jumbo - someone should put this as task for ChatGPT (or similar piece of something) - i bet today Copper audio can be done by human only but in next 6..12 months... who knows?

I see no reason why Copper audio can't be done so we need to wait or for proof it can't be done or ross confirmation that he lost this competition.

[meynaf]

Originally Posted by pandy71

You are younger than ross or me so you are young and you can't argue with this (unless you are math denial).

Younger is comparative, young is adjective. Very different.
It's like a 90 years guy telling a 85 years guy that he is young.
But perhaps you want to continue this nonsense and argue on semantics now ?
I can however play this game too : my young brain works better than your old one, so take your pills and go to sleep, granddaddy.

Originally Posted by pandy71

I'm gentle - soon programmers even highly skilled will be obsolete - replaced by machine learning mambo jumbo - someone should put this as task for ChatGPT (or similar piece of something) - i bet today Copper audio can be done by human only but in next 6..12 months... who knows?

Being confidently wrong can fool many people but it won't help in making code that works.

Originally Posted by pandy71

I see no reason why Copper audio can't be done so we need to wait or for proof it can't be done or ross confirmation that he lost this competition.

Yes, we need to wait, so why are you still here ?
Just show the example and go waiting.

[pandy71]

Originally Posted by meynaf

Younger is comparative, young is adjective. Very different.
It's like a 90 years guy telling a 85 years guy that he is young.
But perhaps you want to continue this nonsense and argue on semantics now ?

I can however play this game too : my young brain works better than your old one, so take your pills and go to sleep, granddaddy.

Yes, we need to wait, so why are you still here ?
Just show the example and go waiting.

hahaha, 100% French you are young padawan

[lmimmfn]

I'm following this great discussion and all the to/fro, but out of curiosity, what's the advantage of copper driven audio? What scenarios is it beneficial?

[paraj]

The "advantage" is supposed to be that it would make it possible to play audio with a period smaller than 123 (i.e. >29KHz sample rate, the limit of DMA driven audio) on an unaccelerated A500 with some CPU time left over.

Not sure if there are any usecases outside showing off

[meynaf]

Originally Posted by pandy71

hahaha, 100% French you are young padawan

Not young and not padawan as i said, but 100% French yes

Originally Posted by lmimmfn

I'm following this great discussion and all the to/fro, but out of curiosity, what's the advantage of copper driven audio? What scenarios is it beneficial?

What paraj said.

The problem with copper audio is that contrary to cpu driven audio which can rely on audio interrupts to keep in sync, copper has no way to be synced aside of terrifying cycle counting - and the fact it is restarted every frame does not help.

[8bitbubsy]

This thread has been a very entertaining read so far!
#ibelieveinross

[meynaf]

Originally Posted by 8bitbubsy

#ibelieveinross

Now it's starting to get religious...

[Thorham]

I wanna hear this so bad

[pandy71]

Originally Posted by meynaf

Now it's starting to get religious...

Well... rather pragmatical - support someone who trying to push boundaries...
4 times oversampling create possibility to deliver higher than 16 bit quality on 8 bit samples (in fact even 2 times oversampled 8 bit audio can be close to 16 bit quality) - CPU driven audio will be still heavily affected by jitter (Copper should be free from jitter).

[meynaf]

Originally Posted by pandy71

Well... rather pragmatical - support someone who trying to push boundaries...

If your definition of "support" is "believe blindly"...

Originally Posted by pandy71

4 times oversampling create possibility to deliver higher than 16 bit quality on 8 bit samples (in fact even 2 times oversampled 8 bit audio can be close to 16 bit quality) -

No, serious ?
By having two 8-bit samples instead of one you can only achieve halfway intermediate value (and quarters with 4 samples).

Originally Posted by pandy71

CPU driven audio will be still heavily affected by jitter (Copper should be free from jitter).

Quite the opposite. CPU can sync with audio in very simple way. Copper can not.

If you use the cpu you have irq that tells you when data is needed. Provided you're fast enough, there is zero jitter. The cpu does *NOT* give the timing.
If you use the copper you have to count the clocks in very dirty way as it can absolutely not know when data will be needed - which is dramatically easy to miss and very hard to debug.

I am not saying copper audio is plain impossible. But it is incredibly hard to do (in a usable way) and clearly not worth.

[pandy71]

Originally Posted by meynaf

If your definition of "support" is "believe blindly"...

Well... isn't supporting outdated HW and SW without future fulfill your definition "believe blindly"... As a skilled programmer you are wasting your skills supporting EOL ISA (MC68K), abandoned HW and partially abandoned SW - this looks almost like defibrillation of the already rotten body...

Originally Posted by meynaf

No, serious ?
By having two 8-bit samples instead of one you can only achieve halfway intermediate value (and quarters with 4 samples).

Gerzon-Craven theorem says something different - you can push quantization noise out of most important band well above 16 bit.
And as many of us is around 50 or more then 2 times oversampling should sufficient for close to 16 bit quality.

Attaching spectrogram as example - somehow this prove than even 2 times oversampled 8 bit PCM audio can be close to 16 bit quality.
At 4kHz you have more than 96dB (16b+) dynamics and in almost whole human audio range somewhere around 10..13 bit audio and 10 bit audio is comparable to cassette tape with Dolby B, 11..12 bit is comparable to Dolby C so i would say not bad at all.
Forgot to add that based on Amiga audio output circuitry - you have there lowpass filter that efficiently suppress large part of audio bandwidth (so probably using some form of pre-emphasis could be nice way to improve higher tones and reduce perceived noise)

Originally Posted by meynaf

Quite the opposite. CPU can sync with audio in very simple way. Copper can not.

If you use the cpu you have irq that tells you when data is needed. Provided you're fast enough, there is zero jitter. The cpu does *NOT* give the timing.
If you use the copper you have to count the clocks in very dirty way as it can absolutely not know when data will be needed - which is dramatically easy to miss and very hard to debug.

I am not saying copper audio is plain impossible. But it is incredibly hard to do (in a usable way) and clearly not worth.

CPU IRQ response can be random and also very costly due pipelining and caches (IRQ penalty can be severe for higher CPU's from 68K family, on other side plain 68K may be too slow to deal with CPU driven audio). Copper on opposite is synchronous with DMA so it always guarantee right on time sample delivery.
So my impression is that this effort (Copper audio) may have sense...
Of course having higher DMA sample rates is superior - if Paula have possibility to combine DMA channels or at least support sample interleaving then it would be better to use HW than SW.

Btw Correct me if i'm wrong on this but isn't Atari ST community open borders and made overscan because it was difficult/impossible on first view? Pushing boundaries...

[meynaf]

Originally Posted by pandy71

Well... isn't supporting outdated HW and SW without future fulfill your definition "believe blindly"... As a skilled programmer you are wasting your skills supporting EOL ISA (MC68K), abandoned HW and partially abandoned SW - this looks almost like defibrillation of the already rotten body...

Nope. It is just about using something because i like doing so, there is nothing to believe in.

Originally Posted by pandy71

Gerzon-Craven theorem says something different - you can push quantization noise out of most important band well above 16 bit.
And as many of us is around 50 or more then 2 times oversampling should sufficient for close to 16 bit quality.

Attaching spectrogram as example - somehow this prove than even 2 times oversampled 8 bit PCM audio can be close to 16 bit quality.
At 4kHz you have more than 96dB (16b+) dynamics and in almost whole human audio range somewhere around 10..13 bit audio and 10 bit audio is comparable to cassette tape with Dolby B, 11..12 bit is comparable to Dolby C so i would say not bad at all.
Forgot to add that based on Amiga audio output circuitry - you have there lowpass filter that efficiently suppress large part of audio bandwidth (so probably using some form of pre-emphasis could be nice way to improve higher tones and reduce perceived noise)

You cannot increase dynamic range by dithering.
But even if this is true, where's the point ? We can get close enough by just using the regular 14-bit trick. It has the advantage of being usable under OS.
You may also want to apply noise shaping on this too... or not ?

Originally Posted by pandy71

CPU IRQ response can be random and also very costly due pipelining and caches (IRQ penalty can be severe for higher CPU's from 68K family, on other side plain 68K may be too slow to deal with CPU driven audio). Copper on opposite is synchronous with DMA so it always guarantee right on time sample delivery.

But, the thing is : there is no need to guarantee "right on time" sample delivery !

Data written in AUDxDAT isn't sent directly to D/A. It is similar in concept to a 2-byte double-buffering technique. So when the IRQ comes, you have something like 1 period (maybe 2) to send the data.

Don't tell me 68000 isn't fast enough. If, say, you want to play 32khz, you only need to perform 16000 writes per second. A 68000 can surely do this ; i've seen Quartet program on Atari ST use 16 khz interrupts to send audio to ym2149 AND perform real time 4-channel mixing at that rate... while still showing some working GUI !

So you get one IRQ per two samples, only thing you have to do is to feed the data before it's too late. The exact moment you do it does *not* matter.

In addition, you're not forced to use interrupts, you can also do irq polling.

Originally Posted by pandy71

So my impression is that this effort (Copper audio) may have sense...
Of course having higher DMA sample rates is superior - if Paula have possibility to combine DMA channels or at least support sample interleaving then it would be better to use HW than SW.

But it does not make sense.
Nor does CPU audio, by the way, but at least it is a lot simpler to code and thus much less error prone.
The reason is that neither can work (not reliably for CPU, not at all for Copper) in a multitasking environment. So you have to kill the OS, but if you do so, where do you fetch the samples you send to the audio ? No hard drive access, sorry... an i doubt a floppy will provide enough data for an oversampling technique ! You can of course preload but not on a 512k machine...

Originally Posted by pandy71

Btw Correct me if i'm wrong on this but isn't Atari ST community open borders and made overscan because it was difficult/impossible on first view? Pushing boundaries...

Did i say anywhere that i had anything against pushing boundaries ? Do not make me say something i did not say !

[pandy71]

Originally Posted by meynaf

Nope. It is just about using something because i like doing so, there is nothing to believe in.

Originally Posted by meynaf

Did i say anywhere that i had anything against pushing boundaries ? Do not make me say something i did not say !

Same for copper audio case - just test concept especially if it can't be proven as non-working in upfront...
And i bet for most of people on this and similar to this forum this is more about doing things we like than having source of income for living.

Originally Posted by meynaf

You cannot increase dynamic range by dithering.
But even if this is true, where's the point ? We can get close enough by just using the regular 14-bit trick. It has the advantage of being usable under OS.
You may also want to apply noise shaping on this too... or not ?

This is contrary to science - dither and oversampling increase dynamic range. Regular 14 bit trick will not work as expected because some limitations - to make 14 bit trick working you need assure sufficient bandwidth for PWM volume control and currently used OPAMP are simply too slow for this so conversion is far from linear (where PWM provide ideal linearity by definition - only jitter will affect PWM linearity).
And of course noise shaping, even quite aggressive need to be used to push quantization noise beyond usable (hear-able) spectrum but it works well enough even for 2 times oversampled 8 bit PCM.

Originally Posted by meynaf

But, the thing is : there is no need to guarantee "right on time" sample delivery !

Data written in AUDxDAT isn't sent directly to D/A. It is similar in concept to a 2-byte double-buffering technique. So when the IRQ comes, you have something like 1 period (maybe 2) to send the data.

Don't tell me 68000 isn't fast enough. If, say, you want to play 32khz, you only need to perform 16000 writes per second. A 68000 can surely do this ; i've seen Quartet program on Atari ST use 16 khz interrupts to send audio to ym2149 AND perform real time 4-channel mixing at that rate... while still showing some working GUI !

So you get one IRQ per two samples, only thing you have to do is to feed the data before it's too late. The exact moment you do it does *not* matter.

In addition, you're not forced to use interrupts, you can also do irq polling.

So why this method can't be applied to Copper audio - DMA slot allocation is known, Copper work synchronously, "reading" IRQ with CDANG active can be simulated. Apologies for my naive way of thinking - probably it is not so easy as it should be.

Originally Posted by meynaf

But it does not make sense.
Nor does CPU audio, by the way, but at least it is a lot simpler to code and thus much less error prone.
The reason is that neither can work (not reliably for CPU, not at all for Copper) in a multitasking environment. So you have to kill the OS, but if you do so, where do you fetch the samples you send to the audio ? No hard drive access, sorry... an i doubt a floppy will provide enough data for an oversampling technique ! You can of course preload but not on a 512k machine...

There is many things without sense - building home from 5 years (i should finish home 3 years ago) - trust me - i know lot of about nonsense.
Definitely Amiga even with 68060 is too slow to be proper source of HQ audio...
Floppy can provide 500kbps, single channel, 8 bit 2 times oversampled audio is approx 440kbps so from gotek-like flash device you can feed data with DMA into RAM to be played by DMA/Copper/CPU.
But why not use RPi Pico on clockport as source of audio... Doable (but i would rather prefer to use Pico as sound card than audio coprocessor but...) Many ideas, most of them probably not practical but... we "like doing so" so who cares if this be this year or next one.

[meynaf]

Originally Posted by pandy71

Same for copper audio case - just test concept especially if it can't be proven as non-working in upfront...
And i bet for most of people on this and similar to this forum this is more about doing things we like than having source of income for living.

There is nothing wrong about testing a concept. But it seems this discussion does not want to remain there...

Originally Posted by pandy71

This is contrary to science - dither and oversampling increase dynamic range.

They won't raise the difference between softest sounds and loudest sounds that the hardware can output, which is the definition of dynamic range - at least not up to the point you claim here.

Originally Posted by pandy71

Regular 14 bit trick will not work as expected because some limitations - to make 14 bit trick working you need assure sufficient bandwidth for PWM volume control and currently used OPAMP are simply too slow for this so conversion is far from linear (where PWM provide ideal linearity by definition - only jitter will affect PWM linearity).

Current PWM works up to ~56khz, so it's kinda enough.
The nonlinear nature of the 14bit trick is handled by calibration.

Originally Posted by pandy71

And of course noise shaping, even quite aggressive need to be used to push quantization noise beyond usable (hear-able) spectrum but it works well enough even for 2 times oversampled 8 bit PCM.

Noise shaping is better put at the very last step of sound reproduction.
Thus, while on real Amiga HW this technique might be no problem, with emulation you'll run on a machine that will eventually do this by itself (HW or SW, unimportant) - and so the re-distributed noise is summed and can cause problems.

Originally Posted by pandy71

So why this method can't be applied to Copper audio - DMA slot allocation is known, Copper work synchronously, "reading" IRQ with CDANG active can be simulated. Apologies for my naive way of thinking - probably it is not so easy as it should be.

Copper can't read registers, only write them. So you can acknowledge an IRQ, but not detect it.
This means you can only "guess" if something needs to be output or not. If your cycle counting is off by just 1 cycle, it'll drift away and you'll get repeated or ignored samples.
Of course every frame the copper will be restarted, and it will have to write the data at a different place every time !
It is possible that PAL short frames / long frames will come in the way, i don't know.
It is also possible the copper can't run for a while at some special places such as horizontal/vertical blank. Perhaps some cycles are unavailable, i don't know either.
So many things can go wrong and prevent copper audio from working at all !

OTOH the cpu does not have to count clocks, it just needs to react fast enough. Easy to code, no hidden issues.

Originally Posted by pandy71

There is many things without sense - building home from 5 years (i should finish home 3 years ago) - trust me - i know lot of about nonsense.

Yes but this puts concrete applications out of scope. It's only experimental and not useful for anything except telling "i did it".

Originally Posted by pandy71

Definitely Amiga even with 68060 is too slow to be proper source of HQ audio...

Depends where you locate "HQ".

Originally Posted by pandy71

Floppy can provide 500kbps, single channel, 8 bit 2 times oversampled audio is approx 440kbps so from gotek-like flash device you can feed data with DMA into RAM to be played by DMA/Copper/CPU.

Normal floppy drive gives approx. 22kb/s, so 176kbps at best. So not enough on unexpanded A500.
But the output rate is the smallest of problems : at CD rate a single floppy will only last a few seconds !

Originally Posted by pandy71

But why not use RPi Pico on clockport as source of audio... Doable (but i would rather prefer to use Pico as sound card than audio coprocessor but...) Many ideas, most of them probably not practical but... we "like doing so" so who cares if this be this year or next one.

Well, the goal was originally to do things on unexpanded machines. Else, simple 68030 can easily play 50khz samples.

[pandy71]

Originally Posted by meynaf

There is nothing wrong about testing a concept. But it seems this discussion does not want to remain there...

But there is no hard coded limits so i can wait for ross work.

Originally Posted by meynaf

They won't raise the difference between softest sounds and loudest sounds that the hardware can output, which is the definition of dynamic range - at least not up to the point you claim here.

It will, dither linearize quantizer and oversampling increase dynamics.
plain dither (such as TPDF) is flat across whole band but you can use "color" dither similarly to noise shaping.

Originally Posted by meynaf

Current PWM works up to ~56khz, so it's kinda enough.
The nonlinear nature of the 14bit trick is handled by calibration.

Nope, this is more tricky - PWM is uneasy - Uniform PWM vs Non Uniform (Natural) PWM, slow OPAMP (to not distort signal, operating amplifier need to be capable to deal with 1.79MHz square wave with voltage around few volts - there is very limited number of such amplifiers - we talking about something like: 350-MHz Bandwidth (G = 10, –3 dB), 470-V/?s Slew Rate 40-ns Settling Time (0.1%) - excerpt from ths4022 datasheet).
Calibration can't address those problems - check thread about real dynamics for 14 bit audio - not even close to 14 bit - there is many problems that can't be solved by static calibration.

Originally Posted by meynaf

Noise shaping is better put at the very last step of sound reproduction.
Thus, while on real Amiga HW this technique might be no problem, with emulation you'll run on a machine that will eventually do this by itself (HW or SW, unimportant) - and so the re-distributed noise is summed and can cause problems.

Yes, same as dithering - this is last step of signal processing. Emulation is different as you can't have Amiga audio anyway - common PC audio hardware has fixed sampling rates so before feeding emulated Paula signal you need to perform asynchronous sample rate conversion - this itself can be tricky to do (eventually you can upsample all Amiga audio to 1.79MHz and later downsample, 4 channels, i would say even for modern CPU this can be computationally costly).

Originally Posted by meynaf

Copper can't read registers, only write them. So you can acknowledge an IRQ, but not detect it.
This means you can only "guess" if something needs to be output or not. If your cycle counting is off by just 1 cycle, it'll drift away and you'll get repeated or ignored samples.
Of course every frame the copper will be restarted, and it will have to write the data at a different place every time !
It is possible that PAL short frames / long frames will come in the way, i don't know.
It is also possible the copper can't run for a while at some special places such as horizontal/vertical blank. Perhaps some cycles are unavailable, i don't know either.
So many things can go wrong and prevent copper audio from working at all !

OTOH the cpu does not have to count clocks, it just needs to react fast enough. Easy to code, no hidden issues.

But in Amiga RGA address define Read or Write not R/W line status. So you can "write" to "read" register - problem is of course OCS where CDANG restrict access to only RGA>DFF03E and in ECS/AGA you can increase HSync to overcome AUDxPER limitation with DMA.

But i can imagine bruteforce approach - sequence set by Copper.

Set AUDxLEN=1, AUDxDAT=X, Activate Audio DMA, - such sequence, regular pattern should create audio.

Originally Posted by meynaf

Yes but this puts concrete applications out of scope. It's only experimental and not useful for anything except telling "i did it".

Same as "overscan" or "interlace" or 9 bit PCM in YM on Atari ST?

Originally Posted by meynaf

Depends where you locate "HQ".

This is quite easy to define - you can objectively (measurements) and subjectively (by listening) define HQ

Originally Posted by meynaf

Normal floppy drive gives approx. 22kb/s, so 176kbps at best. So not enough on unexpanded A500.
But the output rate is the smallest of problems : at CD rate a single floppy will only last a few seconds !

Floppy DMA is over 500kbps (precisely it is 506699.285714286 bps) and you don't need to encode MFM or similar as you can feed data synchronously with Amiga. Additionally you can use CIA to synchronize burst sequence - there is even more possibilities - plain Amiga is very neat on this (not sure about emulation). And CD seem to be nice data source as 150KBps is suffcient to provide 2 channel, 8 bit PCM, 2 times oversampled (AUDxPER = 65 or better 64)

Originally Posted by meynaf

Well, the goal was originally to do things on unexpanded machines. Else, simple 68030 can easily play 50khz samples.

I agree - goal is plain 68000@7MHz

[8bitbubsy]

pandy71: Increasing the bandwidth of an 8-bit linear PCM signal will not increase the SNR (48dB for 8-bit linear PCM). It doesn't matter how good the original source was before quantizing it to 8-bit, or what kind of dithering technique you applied, you still end up with a maximum of 8 effective bits. Even if you were to compress the signal to always use as many effective bits as possible, you'd still easily be able to hear the quantization noise on certain waveforms (especially bass, sines etc) or quieter parts. It just isn't possible to overcome this issue on linear PCM, and dithering doesn't do magic when you have so few output bits.

The reason the 14-bit trick works is because the Paula output really isn't 8-bit if you take the volume modulation into account.

[ross]

Originally Posted by pandy71

Floppy DMA is over 500kbps (precisely it is 506699.285714286 bps) and you don't need to encode MFM or similar as you can feed data synchronously with Amiga.

Off topic but interesting.

Many experiments have been done in this regard (and many more would have to be done...) but unfortunately it doesn't work as you say.
The bps you reported are 'just right', but only in an ideal world (for those interested: it is the base frequency of the cells that Paula uses as a reference when start the disk data sampling and initialize the counters [=CCK/7]).
But 'unfortunately' (or fortunately depending on who actually wants the discs to be read even if they are in bad condition) it is not passive when reading data, but adapts the sampling frequency to the state of the input stream.

It is not known what the precise 'algorithm' of this DPLL is, but it is certainly related to the quantity and the distance between the flux changes.
So these bps can also become CCK/6 or CCK/8, adaptively, for a short time and every now and then.

As you can imagine, this does not actually allow you to exceed the expected (MFM=50%) speed by much, otherwise synchronization is lost for certain data patterns
(some 0000.. or 11.. sequences could become different).

Additionally you can use CIA to synchronize burst sequence..

I didn't understand this step, can you elaborate?

[ross]

Originally Posted by 8bitbubsy

The reason the 14-bit trick works is because the Paula output really isn't 8-bit if you take the volume modulation into account.

There is a thread somewhere where a user measured the actual dynamics and it was around 12-bit.

The problem is that with the 'ear' calibration that is usually done for 14-bit it is practically impossible to achieve this '12-bit', it would take suitable equipment and infinite patience.
And in any case it would only be valid for that particular Amiga.
However, it is not only a linearity problem but also a phase mismatch between the channels...

Anyway, dozens of threads have been opened on the subject and debated endlessly, without finding a definitive answer