AUDxPER for maximum playback rate

[Gorack]

Various information on the web states that 124 is the minimum value that can be used in this register.
But is this a limitation caused by the number of DMA cycles?
Can a faster sampling rate be achieved if the AUDxDAT registers are fed by the CPU instead?
If so what is the fastest theoretical rate that could be achieved?

[paraj]

Discussion of the minimum period: https://eab.abime.net/showthread.php?t=70783
Maximum rate: http://bax.comlab.uni-rostock.de/dl/...mTheoretic.pdf (54567 Hz)

Also some other discussions here you may find interesting:

https://eab.abime.net/showthread.php?t=112931
https://eab.abime.net/showthread.php?t=105355

[Gorack]

Thanks, a lot more information than most web sites (and books) that say, 124 is the minimum value that can be put into these registers.

So if DMA limits it to 28.8 kHz because there is only one DMA access slot allocated to each of the audio channels per scan line, I was thinking of trying to feed the registers using the copper. That way more than a single update can occur on a scan line but still be mostly DMA driven. However, the CPU will need to refresh parts of the copper list per frame (but now the sample data can be in fast ram).

[koobo]

This is interesting! I'm guessing the max output rate in non-DMA mode is likely related to the clock frequency used to run Paula.

[ross]

Originally Posted by koobo

This is interesting! I'm guessing the max output rate in non-DMA mode is likely related to the clock frequency used to run Paula.

Well, everything in Paula is CCK (PAL: 3546895Hz) related

So if you set AUDxPER/AUDxLEN=1, AUDxVOL=64 and AUDxDAT=$7F81 you can generate a perfect square wave with 50% duty cycle at 1.7xMHz.
The problem is that you have to get the signal directly on the AUDx pins because otherwise it would be heavily filtered.

The main impediment in using the non-DMA mode is related to the fact that you are practically forced to use the Copper (otherwise the processor could do practically nothing else and also the synchronization would change depending on the CPU model).

And also using the Copper is not so trivial because to load the values in AUDxDAT you must somehow generate a synchronous stream and in the meantime maybe you would also like to use the Copper to make some video effects. So usually you ends up use a (sub)multiple of the video line frequency.

Also mixing DMA mode with non-DMA mode is a pain... the complication is just not worth it and you end up using one of two 'natural' ways.

To conclude: there are no free lunches

[meynaf]

Originally Posted by ross

The main impediment in using the non-DMA mode is related to the fact that you are practically forced to use the Copper (otherwise the processor could do practically nothing else and also the synchronization would change depending on the CPU model).

I don't think so.
To feed AUDxDAT 'by hand', the cpu remains the best option as you can use audio interrupts. You get 1 irq per 2 samples (AUDxDAT holds 2 samples). Thus, if you want to play at f.e. 50khz, you need 25,000 ints/sec - which seem perfectly doable.

[ross]

Originally Posted by meynaf

I don't think so.
To feed AUDxDAT 'by hand', the cpu remains the best option as you can use audio interrupts. You get 1 irq per 2 samples (AUDxDAT holds 2 samples). Thus, if you want to play at f.e. 50khz, you need 25,000 ints/sec - which seem perfectly doable.

Try it on a 7Mhz 68000


EDIT: I was thinking that even on fast machines the use of resources would be exaggerated, I imagine that at least a fast 030 would be needed to have a somewhat responsive machine in such a situation.
Almost two IRQs per video line, with the latency of IRQ acknowledging, saving registers and the routine itself is way too much to be usable.
I don't think it's a solution that anyone has used, at least not in a non-test environment.
So I confirm, in my opinion CPU usage to manual feed AUDxDAT is the worst situation, not the best.
But always happy to be proved wrong

[meynaf]

Originally Posted by ross

Try it on a 7Mhz 68000

I haven't, but i guess it can reach something like 16000 ints/sec or even more.
But where's the point anyway ? If you have very slow machine there is little incentive to go over what DMA can do.

Originally Posted by ross

EDIT: I was thinking that even on fast machines the use of resources would be exaggerated, I imagine that at least a fast 030 would be needed to have a somewhat responsive machine in such a situation.
Almost two IRQs per video line, with the latency of IRQ acknowledging, saving registers and the routine itself is way too much to be usable.

The routine can be quite simple and there is no need to save all registers.
My 68030 could do 25000 ints/sec even under OS and the machine was responsive enough - audio just wasn't stable due to other system activity.

Which leaves us with another very interesting problem : how to feed that player with data, as file I/O from hard drive requires working OS and all the solutions presented here need to kill the system...

Originally Posted by ross

I don't think it's a solution that anyone has used, at least not in a non-test environment.

It has been done by myself and probably also by others. The main problem isn't cpu load here (see above).
So i can tell you for a fact that using the cpu to feed audio data has been done with some success, contrary to using the copper for which AFAIK all attempts have failed.

Originally Posted by ross

So I confirm, in my opinion CPU usage to manual feed AUDxDAT is the worst situation, not the best.

The best solution is a solution that actually works. With cpu it does work, with some limits. With the copper it never has.

Originally Posted by ross

But always happy to be proved wrong

You can prove this yourself, by just attempting to make audio work with the copper, and failing like everyone else before

[ross]

Originally Posted by meynaf

But where's the point anyway ? If you have very slow machine there is little incentive to go over what DMA can do.

That this can be done even on a slow machine (a proof of concept)

The routine can be quite simple and there is no need to save all registers.
My 68030 could do 25000 ints/sec even under OS and the machine was responsive enough - audio just wasn't stable due to other system activity.

Well, if the audio is not stable I would say that it means that in a multi-tasking environment it can't be done. Period.
Of course for a demo or similar with 030 50 there would be no problem, but in any case it would eat up a good part of your resources.
And for a slow machine, basically all resources..

Which leaves us with another very interesting problem : how to feed that player with data, as file I/O from hard drive requires working OS and all the solutions presented here need to kill the system...

And this is another sore point to which there is no answer.
At the very least, tests can be done with the system disabled.
And then we go back to the beginning.

It has been done by myself and probably also by others. The main problem isn't cpu load here (see above).
So i can tell you for a fact that using the cpu to feed audio data has been done with some success, contrary to using the copper for which AFAIK all attempts have failed.

Yeah, I absolutely do not argue that it can be done or that someone has done it, but that "at least not in a non-test environment."
I don't know of any released programs or demos or games that use it for a player instead of the DMA mode, but I could be wrong.
(I'm obviously talking about IRQ code that plays one word at a time, not IRQ handling that uses a block of memory; there are thousands of those )

The best solution is a solution that actually works. With cpu it does work, with some limits. With the copper it never has.

Some attempts have been made and working, with some limitations to the frequency due to the specific use of Copper during the line.

You can prove this yourself, by just attempting to make audio work with the copper, and failing like everyone else before

Ok, challenge accepted.
But we have to define the specifications.
I'm fine with a 68000 at 7Mhz, but with the system disabled.

The data problem can also be solved by loading it from floppy, so not at too high a frequency...
The important thing is that the DMA or the IRQs are not used but only and exclusively manually through the Copper.
All right?

[meynaf]

Originally Posted by ross

That this can be done even on a slow machine (a proof of concept)

A mere proof of concept may be fun, but frankly i'd prefer the ability to play straight 44.1khz wave files on a PAL display.

Originally Posted by ross

Well, if the audio is not stable I would say that it means that in a multi-tasking environment it can't be done. Period.

Depends what you call "be done". It can really be done, it's just that it sometimes misses. Don't expect the copper to never miss either.

Originally Posted by ross

Of course for a demo or similar with 030 50 there would be no problem, but in any case it would eat up a good part of your resources.
And for a slow machine, basically all resources..

This is a non-issue, really.
A slow machine wouldn't be able to give it enough data to start with - so you need an accelerated machine anyhow.

Originally Posted by ross

And this is another sore point to which there is no answer.
At the very least, tests can be done with the system disabled.
And then we go back to the beginning.

IOW, it can only be a proof of concept - of course with system disabled as the situation is worse than with the cpu.

Originally Posted by ross

Yeah, I absolutely do not argue that it can be done or that someone has done it, but that "at least not in a non-test environment."
I don't know of any released programs or demos or games that use it for a player instead of the DMA mode, but I could be wrong.
(I'm obviously talking about IRQ code that plays one word at a time, not IRQ handling that uses a block of memory; there are thousands of those )

Same can be said for the copper method (except that i still have to see it working at all).

Originally Posted by ross

Some attempts have been made and working, with some limitations to the frequency due to the specific use of Copper during the line.

Really ? I've never seen any. All attempts i know of could just play square waves with errors.

Originally Posted by ross

Ok, challenge accepted.
But we have to define the specifications.
I'm fine with a 68000 at 7Mhz, but with the system disabled.

And OCS chipset maybe ?

Originally Posted by ross

The data problem can also be solved by loading it from floppy, so not at too high a frequency...

You will end up below 28khz this way. Makes the proof of concept much less interesting.
I think you'd better preload from HD.

Originally Posted by ross

The important thing is that the DMA or the IRQs are not used but only and exclusively manually through the Copper.
All right?

Important things for me are :
- the copper must be the only one sending data to AUDxDAT
- no parasite noise - IOW it must not miss a sample
- must play real samples - not just a simple tone

[ross]

Originally Posted by meynaf

And OCS chipset maybe ?

And OCS

You will end up below 28khz this way. Makes the proof of concept much less interesting.
I think you'd better preload from HD.

Gasp...
Ok, above 28KHz, but a short one then, the data that can be played from a floppy contents, preloaded in memory.

Important things for me are :
- the copper must be the only one sending data to AUDxDAT
- no parasite noise - IOW it must not miss a sample
- must play real samples - not just a simple tone

Agreed.

[koobo]

Well, this escalated quickly grabs some popcorn

[meynaf]

Originally Posted by ross

And OCS

Can copper access full chipset on OCS ?

Originally Posted by ross

Gasp...
Ok, above 28KHz, but a short one then, the data that can be played from a floppy contents, preloaded in memory.

You could crunch it (and decrunch real time). As the cpu is supposed to be available for something else with this method.

[ross]

Originally Posted by meynaf

Can copper access full chipset on OCS ?

Do you mean all the RGA bus?
No, it can't, but that's okay, the registers you need are available.

You could crunch it (and decrunch real time). As the cpu is supposed to be available for something else with this method.

Addition challenge accepted

[meynaf]

Originally Posted by ross

Do you mean all the RGA bus?
No, it can't, but that's okay, the registers you need are available.

Audio yes, but what about INTREQ ?
Chances are big that audio interrupt must be cleared before writing to AUDxDAT again, otherwise you'll play first two samples and after that, silence on the line.

[ross]

Originally Posted by meynaf

Audio yes, but what about INTREQ ?
Chances are big that audio interrupt must be cleared before writing to AUDxDAT again, otherwise you'll play first two samples and after that, silence on the line.

Yes, it's already all planned out in my mind on how to do it.
I just have to write the code

[pandy71]

If i recall correctly someone already provided Copper Audio code on EAB - can't find it at this moment.
Isn't possible to use quasi DMA mode ie set period intentionally beyond DMA capability and just feed audio samples in more or less regular mode by CPU/Copper - if DMA buffer will be filled with zeros then CPU/Copper samples will be separated by null samples from memory (OK from math perspective) but timing should be constant (unless writing something by CPU to AUDxDAT disarm DMA)

[meynaf]

One month later, still nothing ?

Originally Posted by ross

I just have to write the code

Let me guess...
Step 1 : establish a plan
Step 2 : write the code
Step 3 : find out why it doesn't work
Step 4 : drop the plan

[ross]

Let me guess...
You will be really surprised

[meynaf]

Originally Posted by ross

Let me guess...
You will be really surprised

So far it hasn't been the case. How long do we have to wait to see something, one year ?
As code takes ages to write, you have to admit at least that it is very convoluted method, a lot more complex than just feeding the data with the cpu.
And if we see nothing at all at the end...