AUDxPER for maximum playback rate

[ross]

Originally Posted by Karlos

1. What is copper audio?

A poor man's version of silver audio.
Legends say that even golden audio exists, at the end of the rainbow.

2. What are the proposed advantages of copper audio over regular Paula/DMA or AHI?

The advantages are many!

- make sure meynaf doesn't die of boredom
- know the end of this story (no spoiler please!)
- your Amiga will make you a coffee while it plays
- peace in the world
- and, last but not least, my nuts will stop cracking

[Karlos]

So how does 56kHz normally work? I recall it being available in double scan modes and also when using cybergfx display. Presumably this is ECS/AGA only?

[ross]

Originally Posted by Karlos

So how does 56kHz normally work? I recall it being available in double scan modes and also when using cybergfx display.

Audio DMA channels are bound to video line frequency.
The higher the horizontal video frequency, the higher the achievable audio frequency.
Of course you need a chipset that supports programmable video modes (ECS+).

[Karlos]

So is the goal to implement (up to) 56K without the need for higher scan rates (eg OCS compatible) but equally without bogging down the CPU? At some point, the conversation seemed to be veering into using interleaving to increase the logical channel count, which would work better at higher frequencies.

[ross]

Originally Posted by Karlos

So is the goal to implement (up to) 56K without the need for higher scan rates (eg OCS compatible) but equally without bogging down the CPU? At some point, the conversation seemed to be veering into using interleaving to increase the logical channel count, which would work better at higher frequencies.

If I'm not mistaken this was discussed in the other thread (roondar's one?).

This one is more imaginative and anything can be talked about, the main thing is to keep the viewers entertained.

[No.3]

In practice this "up to 56 kHz" is ~50-52 kHz depending on which channel is used (Productivity and Euro72).

[ross]

Originally Posted by No.3

In practice this "up to 56 kHz" is ~50-52 kHz depending on which channel is used (Productivity and Euro72).

The channel number doesn't make much difference (there is a single period of difference between the next ones).

Otherwise it is correct, there can be many KHz of difference depending on the video mode.
Somewhere in another thread here on EAB I wrote how to calculate it.

[No.3]

Originally Posted by ross

The channel number doesn't make much difference (there is a single period of difference between the next ones).

The smaller the period, the bigger is the difference of the resulting replay rate !! e.g.

3546895 / 124 = 28604
3546895 / 125 = 28375
3546895 / 126 = 28150

3546895 / 60 = 59115
3546895 / 61 = 58146
3546895 / 62 = 57208

[pandy71]

Originally Posted by meynaf

By itself mp3 is bad enough so that you don't need perfect sound system to play it.
Anyway, vampires (68080) are supposed to have higher audio dma limits and 16-bit sound.

It is not CPU related - or we talking about CPU or SoC?
And MP3 is not that bad but de facto it is standard satisfactory to more than 99.9% of listeners.

Originally Posted by meynaf

I hope this is a misunderstanding.
The point has never been to emulate a 68000. It was about the 68000 itself doing clock-by-clock simulation ! (Which is obviously impossible.)

My point was to clock accurate simulation of system so CPU + Agnus/Paula and Denise if necessary - with HDL simulators this is doable with reasonable speed as nowadays those 150k transistors is rather low complexity design.

Originally Posted by meynaf

It's you who are waiting, not me.

it is you who started calling ross about missing code so seem you are waiting for this code more than me.

Originally Posted by meynaf

You know full well that superior marketing beats out superior products.
Btw. Didn't they have to fire quite a few people recently ?

NT was not invented by MS but by DEC - and as i read stories they mostly firing people responsible for same bullshit that is behind fail of Silicon Valley Bank - 'diversity, equity and inclusion'

Originally Posted by meynaf

They probably require working mmu so yes they can forbid anything.

oh, but this is OS controlled by some secret organization or by programmer?

[pandy71]

Originally Posted by No.3

The smaller the period, the bigger is the difference of the resulting replay rate !! e.g.

3546895 / 124 = 28604
3546895 / 125 = 28375
3546895 / 126 = 28150

3546895 / 60 = 59115
3546895 / 61 = 58146
3546895 / 62 = 57208

Yes, one of biggest flaws in Paula - simple divider returns high resolution where it not useful at all - having NCO (and 2 DAC shared between channels) will probably reduce size of die and significantly improve Paula capabilities and make this discussion not present)

btw seem if volume control is active then there is no sense to go for periods lower than 128 (to not violate Nyquist rate) so 14 bit mode may be worse at periods lower than 128 (introduce distortions)

[ross]

Originally Posted by pandy71

btw seem if volume control is active then there is no sense to go for periods lower than 128 (to not violate Nyquist rate) so 14 bit mode may be worse at periods lower than 128 (introduce distortions)

Why period 128?
Distortions start at <64 because there is no way to set up in a right way a PWM pulse (for a full volume counter value).
In my opinion it is quite the opposite, if you want to reach high frequencies for the Nyquist theorem you have to sample at double the maximum of the frequency to be reproduced correctly and therefore you should get as close as possible to the lower available period value.

Also for 14-bits the volume of the channels is fixed so I don't know how a period between 64 and 128 can be a problem.
But maybe I don't understand what you mean

[pandy71]

Originally Posted by ross

Why period 128?
Distortions start at <64 because there is no way to set up in a right way a PWM pulse (for a full volume counter value).
In my opinion it is quite the opposite, if you want to reach high frequencies for the Nyquist theorem you have to sample at double the maximum of the frequency to be reproduced correctly and therefore you should get as close as possible to the lower available period value.

Also for 14-bits the volume of the channels is fixed so I don't know how a period between 64 and 128 can be a problem.
But maybe I don't understand what you mean

But this is case with double sampling, PCM is sampled by PWM (and PWM frequency is 1/64 as counter is 6 bit) so in overall PCM rule is extended to PCM or before PWM they shall be reconstructed by reconstruction filter to restore analog signal (but this not implemented in Paula).
Good topic for academic math analysis.
Based on https://en.wikipedia.org/wiki/Pulse-...mpling_theorem

PWM sampling theorem states that "Any bandlimited baseband signal within ±0.637 can be represented by a pulsewidth modulation (PWM) waveform with unit amplitude. The number of pulses in the waveform is equal to the number of Nyquist samples and the peak constraint is independent of whether the waveform is two-level or three-level."

Problem is: PCM samples before PWM are not bandlimited...

[meynaf]

Originally Posted by pandy71

It is not CPU related - or we talking about CPU or SoC?

Accelerators are not only cpu related. On my A1230 i had more memory, a battery-backed clock, an fpu socket, a maprom option, an scsi interface...

Originally Posted by pandy71

And MP3 is not that bad but de facto it is standard satisfactory to more than 99.9% of listeners.

Sorry, but today many listeners use MP4 (AAC), or maybe Opus. MP3 is slowly dying.
I can also return this argument and say that 14-bit satisfies more than 99.9% of listeners.

Originally Posted by pandy71

My point was to clock accurate simulation of system so CPU + Agnus/Paula and Denise if necessary - with HDL simulators this is doable with reasonable speed as nowadays those 150k transistors is rather low complexity design.

Valid point, but OT - this won't help you in having 68000 do copper audio (which was the original issue).

Originally Posted by pandy71

it is you who started calling ross about missing code so seem you are waiting for this code more than me.

I came back here just to say : hey, no code available after a whole month, so you lost the challenge - i was expecting this, end of story, let's move on.
Unfortunately this only created a monster thread.

Originally Posted by pandy71

NT was not invented by MS but by DEC - and as i read stories they mostly firing people responsible for same bullshit that is behind fail of Silicon Valley Bank - 'diversity, equity and inclusion'

The issue isn't the kernel itself, it's everything that runs on top of it. NT kernel is actually quite good.
Regardless of the reason they fire people, you can at least reckon they don't exactly have the best reputation of reliability.

Originally Posted by pandy71

oh, but this is OS controlled by some secret organization or by programmer?

So now you want to hack their kernel ?
Better hack AmigaOS, it's a magnitude easier.

[pandy71]

Originally Posted by meynaf

Accelerators are not only cpu related. On my A1230 i had more memory, a battery-backed clock, an fpu socket, a maprom option, an scsi interface...

You may add to this I/O, sound, graphics, network etc but at some point from 20 MIPS you going in area of 100..200 MIPS maybe.

Originally Posted by meynaf

Sorry, but today many listeners use MP4 (AAC), or maybe Opus. MP3 is slowly dying.
I can also return this argument and say that 14-bit satisfies more than 99.9% of listeners.

Add to AAC at least FLAC, DSD... but still MP3 is common and provide good quality vs overall complexity and as patents are expired nothing can be its market penetrations - on opposite side 14 bit trick market penetration is millions time lower.
Saying that MP3 is slowly dying seem to be quite brave statement especially that on Amiga it is still one of holly grails...

Originally Posted by meynaf

Valid point, but OT - this won't help you in having 68000 do copper audio (which was the original issue).

Well - having simulator may substantially help to understand best approach for Copper audio - i can imagine on real HW this can be very time consuming process to get proper and stable Copper timing and at the same time optimize resource usage. We may call this 'profiler'.

Originally Posted by meynaf

I came back here just to say : hey, no code available after a whole month, so you lost the challenge - i was expecting this, end of story, let's move on.
Unfortunately this only created a monster thread.

Yes, i feel guilty for helping you derailing thread and making it longer than OP initial intention.
And yes, i know this is not about code but about how 'mine is longer than yours'

Originally Posted by meynaf

The issue isn't the kernel itself, it's everything that runs on top of it. NT kernel is actually quite good.
Regardless of the reason they fire people, you can at least reckon they don't exactly have the best reputation of reliability.

Like everything on this planet recently... and to be honest seem nobody care, perhaps excepts some old farts...

Originally Posted by meynaf

So now you want to hack their kernel ?
Better hack AmigaOS, it's a magnitude easier.

It was just example (and FreeRTOS is Open Source so probably don't need to be hacked), there are other mini OS that can be used as reference (like Contiki or x86 KolibriOS ) .
Hacking Amiga OS... good luck in endless court battles...

[meynaf]

Originally Posted by pandy71

Add to AAC at least FLAC, DSD... but still MP3 is common and provide good quality vs overall complexity and as patents are expired nothing can be its market penetrations - on opposite side 14 bit trick market penetration is millions time lower.
Saying that MP3 is slowly dying seem to be quite brave statement especially that on Amiga it is still one of holly grails...

Frankly i do not see mp3 as a holy grail. It has been done long ago.
On 'opposite side', 14 bit trick has been used extensively on the Amiga. The fact it is niche market does not change that, please do not compare apples and oranges.

Originally Posted by pandy71

Well - having simulator may substantially help to understand best approach for Copper audio - i can imagine on real HW this can be very time consuming process to get proper and stable Copper timing and at the same time optimize resource usage. We may call this 'profiler'.

This is provided the simulator is 100% accurate, which is a little bit difficult to guarantee.

Originally Posted by pandy71

Yes, i feel guilty for helping you derailing thread and making it longer than OP initial intention.

You are guilty but not me. I didn't derail this thread, only replied to others who actually did it.

Originally Posted by pandy71

And yes, i know this is not about code but about how 'mine is longer than yours'

This is how you see it and you are actually participating... What conclusion shall we draw from this ?

Originally Posted by pandy71

It was just example (and FreeRTOS is Open Source so probably don't need to be hacked), there are other mini OS that can be used as reference (like Contiki or x86 KolibriOS ) .

I call hacking the kernel anything that touches the core of the OS. That you have sources or not doesn't matter. But you can find as many miniOS as you want, none will solve the problem at hand - as, provided they actually run on Amiga (which does not appear to be the case), they wouldn't support much of its hardware.

Originally Posted by pandy71

Hacking Amiga OS... good luck in endless court battles...

Many, many patches have been made that completely contradict this.
Anyone can call exec.library/SetFunction to replace any part of the OS. Yes you can hack AmigaOS while it is currently running !
Now, please do not speak about things you do not know.

[pandy71]

Originally Posted by meynaf

Frankly i do not see mp3 as a holy grail. It has been done long ago.
On 'opposite side', 14 bit trick has been used extensively on the Amiga. The fact it is niche market does not change that, please do not compare apples and oranges.

lol... once again - even most powerful accelerator in Amiga is still unable to provide at CPU level some basic functionality related to audio without additional sound card but i'm glad that you are happy with 14 bit...

btw apples and oranges are fruits - they can be compared easily... at least i can compare them easily.

Originally Posted by meynaf

This is provided the simulator is 100% accurate, which is a little bit difficult to guarantee.

if it can be verified - it can be guaranteed

Originally Posted by meynaf

You are guilty but not me. I didn't derail this thread, only replied to others who actually did it.

lol, indeed, it was other meynaf, not you

Originally Posted by meynaf

This is how you see it and you are actually participating... What conclusion shall we draw from this ?

Me? participating?, why you think so?, i was just interested in Copper audio or CPU audio with AUDxPER=65 preferably on OCS if possible and plain MC68000 - as you can't prove that Copper Audio is not possible and also you can't prove that CPU audio is possible under normal OS operation with active multitasking then my conclusion was quite obvious but you seem to not agree with this going even further and denying your previous statement.

Originally Posted by meynaf

I call hacking the kernel anything that touches the core of the OS. That you have sources or not doesn't matter. But you can find as many miniOS as you want, none will solve the problem at hand - as, provided they actually run on Amiga (which does not appear to be the case), they wouldn't support much of its hardware.

And if i understand correctly you, Amiga specific HW support can't be added to any of those mini OS's?

Originally Posted by meynaf

Many, many patches have been made that completely contradict this.
Anyone can call exec.library/SetFunction to replace any part of the OS. Yes you can hack AmigaOS while it is currently running !
Now, please do not speak about things you do not know.

Seem this is contradictory to your previous statements but OK - not speak, not ask. Thx for patience.

[ross]

Originally Posted by pandy71

lol, indeed, it was other meynaf, not you

Now everything is explained!
But the thorny question becomes: how many are there in total!?!?

Just kidding, as always

[meynaf]

Originally Posted by pandy71

lol... once again - even most powerful accelerator in Amiga is still unable to provide at CPU level some basic functionality related to audio without additional sound card but i'm glad that you are happy with 14 bit...

We have a lot more than "basic" functionality related to audio. We actually have more versatile audio than in "modern" machines. We have independent audio channels, each with own dma and extremely low latencies. We have per-channel volume, we're not locked to a few set of fixed frequencies.
But all you are looking at is the amount of noise on the paper. This is sad.

Originally Posted by pandy71

btw apples and oranges are fruits - they can be compared easily... at least i can compare them easily.

You perfectly know it is an English expression saying that one attempts to compare two things that are unrelated.

Originally Posted by pandy71

if it can be verified - it can be guaranteed

But it can't be completely verified. It's like software, you can't prove anything is bug-free.

Originally Posted by pandy71

lol, indeed, it was other meynaf, not you

Are you starting to be contemptuous now ?
The two statements you quoted are both correct.
I came here to say : nothing after a month. Then it should have stopped, but people started to argue and i just replied.
Note that during all that time, we've seen working cpu audio code but no code doing copper audio.

Originally Posted by pandy71

Me? participating?, why you think so?

Yes, you, participating. You are endlessly arguing in here - and often on unrelated points. You so badly want to be 'right' that you end up doing quite a few fallacies (like the two i mentioned below).

Originally Posted by pandy71

i was just interested in Copper audio or CPU audio with AUDxPER=65 preferably on OCS if possible and plain MC68000 - as you can't prove that Copper Audio is not possible and also you can't prove that CPU audio is possible under normal OS operation with active multitasking then my conclusion was quite obvious but you seem to not agree with this going even further and denying your previous statement.

I won't give you any proof that copper audio isn't possible, especially because i haven't said it wasn't ! (Note that even if i did, this is reversing the charge of the proof.)
I also didn't pretend one could get cpu audio reliably under OS (even though i actually made it work under jit).
Again you put words in my mouth that i didn't say. (This is strawman fallacy.)
And I am not denying my previous statements, you just see contradictions where there are none - maybe for just the sake of arguing.

Originally Posted by pandy71

And if i understand correctly you, Amiga specific HW support can't be added to any of those mini OS's?

Haven't said that. Why do you always surinterpret what i'm writing ?
Yes it could eventually be added, but it is big amount of work - to not solve the problem at the end.

Originally Posted by pandy71

Seem this is contradictory to your previous statements but OK - not speak, not ask. Thx for patience.

Where's the sense in that ?

Originally Posted by ross

Now everything is explained!
But the thorny question becomes: how many are there in total!?!?

Just kidding, as always

Actual number is pretty much unimportant. You will be assimilated. All resistance is futile.

[ross]

Originally Posted by meynaf

Actual number is pretty much unimportant. You will be assimilated. All resistance is futile.

meynaf, in his majesty:

[meynaf]

Originally Posted by ross

meynaf, in his majesty:
<snip>

Nope. That's not me.
But don't worry, even assimilators will be assimilated.