AUDxPER for maximum playback rate

[ross]

Originally Posted by meynaf

As code takes ages to write..

Nahh, I wrote the code not much later the claim.
Is that I'm (we are, with some friends) using the code for something that's not a pure proof of concept, but really usable in a little intro (a little tech jewel).

You just have to be patient, I assure you that someone has already seen the code in action

..you have to admit at least that it is very convoluted method, a lot more complex than just feeding the data with the cpu.

Never said the opposite, but the challenge is just that (besides overcoming the limits imposed by the hardware in using only DMA).

[meynaf]

Originally Posted by ross

Nahh, I wrote the code not much later the claim.
Is that I'm (we are, with some friends) using the code for something that's not a pure proof of concept, but really usable in a little intro (a little tech jewel).

I now see what was missing in the above specifications... a timeout !

Originally Posted by ross

You just have to be patient, I assure you that someone has already seen the code in action

I am not patient
If "someone" has already seen the code in action, why not us here too ?

Originally Posted by ross

Never said the opposite, but the challenge is just that (besides overcoming the limits imposed by the hardware in using only DMA).

This contradicts what you've written above. If the challenge is "just that", release a working version instead of attempting to use it in a little intro.

[ross]

Originally Posted by meynaf

If "someone" has already seen the code in action, why not us here too ?

To make you suffer, of course

This contradicts what you've written above. If the challenge is "just that", release a working version instead of attempting to use it in a little intro.

No contradiction.
This way of 'pushing' the limits using copper frees up the CPU for other tasks and my aim is to demonstrate that even a simple OCS machine can use it.
It would be totally impossible by using only the CPU to do what you will see.

Obviously it is much more 'convoluted' and 'complex'.

[ross]

Originally Posted by meynaf

I now see what was missing in the above specifications... a timeout !

Originally Posted by ross

To make you suffer, of course

Well, all kidding aside, unfortunately I don't have much time to dedicate to it, so it will take me more time.
But I guess, apart from meynaf (), nobody here is in a hurry.

I hope to finish everything in the next (few!) months (as soon as possible..).
Basically it's something that hasn't been done for almost 35 years so I don't think a month more or less makes a difference.

[meynaf]

Originally Posted by ross

To make you suffer, of course

Then - for me at least - this is a complete miss. It just makes me believe that you simply can't do it and refuse to admit it. And be deceived as i expected more honesty from you.

Originally Posted by ross

No contradiction.
This way of 'pushing' the limits using copper frees up the CPU for other tasks and my aim is to demonstrate that even a simple OCS machine can use it.
It would be totally impossible by using only the CPU to do what you will see.

Obviously it is much more 'convoluted' and 'complex'.

So you want to move the goalposts, huh ? I can do it too and add a deadline...

The challenge is to decrunch audio and send it thru copper, not writing an intro (for which regular dma would be enough anyway). You do not need anything else to prove the cpu can do other tasks than just sending audio data.
So please show some code. You'll do your intro later.

And that it would be totally impossible by only using the CPU, of course not. A stronger CPU is all that's needed - and i am not even sure it is even required, the cpu usage difference might be non significant. Oh, and one could just downsample with a good resampling program so that nobody hears the difference.

Originally Posted by ross

Well, all kidding aside, unfortunately I don't have much time to dedicate to it, so it will take me more time.

May I respectully remind you that you're supposed to have written the code just a few time right after the claim ?

Originally Posted by ross

But I guess, apart from meynaf (), nobody here is in a hurry.

I'm not in a hurry. I just thought one month was largely enough.
But ok, i'll wake you up next year

Originally Posted by ross

I hope to finish everything in the next (few!) months (as soon as possible..).
Basically it's something that hasn't been done for almost 35 years so I don't think a month more or less makes a difference.

It isn't something that hasn't been done for almost 35 years. It is something that has never been done (in a successful way), unless proven otherwise.
So what do you want here ? Gain some time, in the hope I (and possibly others) will forget about it ?
If what you want is some kind of "complete victory", you can start by showing what you have already, then (few! ) months later you show your "impossible to do otherwise" intro. You don't need to make us wait.

[ross]

Originally Posted by meynaf

The challenge is to decrunch audio and send it thru copper, not writing an intro..

This is already done, you can believe it or not, but since it would be 'ugly' to do only this, I decided to make an intro.
As you said yourself, there was no deadline, so i decided to do things 'right'.
The code is mine and I manage it as I think is best, can I?

You do not need anything else to prove the cpu can do other tasks than just sending audio data.

I do not agree.
The fundamental purpose is also the usability of this technique.
That is, to make it clear that you don't need a powerful CPU (or an AGA machine) to break the DMA limits of audio, but even a measly A500 is enough.

And that it would be totally impossible by only using the CPU, of course not. A stronger CPU is all that's needed - and i am not even sure it is even required, the cpu usage difference might be non significant. Oh, and one could just downsample with a good resampling program so that nobody hears the difference.

Ok, so after you've seen the intro you'll tell me how you'll do the same thing with the CPU and what frequency it should have

May I respectully remind you that you're supposed to have written the code just a few time right after the claim ?

I was talking about the full intro here of course..

It isn't something that hasn't been done for almost 35 years. It is something that has never been done (in a successful way), unless proven otherwise.

Yes, I spelled it wrong, I just meant to say it's been something we've been waiting for years (since 1985..) so a month doesn't make a difference.

So what do you want here ? Gain some time, in the hope I (and possibly others) will forget about it ?
If what you want is some kind of "complete victory", you can start by showing what you have already, then (few! ) months later you show your "impossible to do otherwise" intro. You don't need to make us wait.

No, if for any reason I don't complete the intro, I will release the code as it stands.
It's not just me who owns it, so others in case will be able to.

But what are we discussing anyway?
I repeat, you just have to be patient and eventually you will see something.
How and when, I decide.

[a/b]

If you use digitized Sabrina or Sam Fox music, make sure to add some digi pictures as well!
Extra dare: release at Revision while it's being streamed on twitch!

[ross]

Originally Posted by a/b

If you use digitized Sabrina or Sam Fox music, make sure to add some digi pictures as well!

How did you find out about my plans!?

Extra dare: release at Revision while it's being streamed on twitch!

[ross]

But dammit, I wanted the stupid intro to be a surprise and now we all know there is going to be.

And expectations will be high, so it will have to be even better than it was planned.. damn it.

Well, it will be as it will be, don't expect too much (but copper audio ).

[meynaf]

Originally Posted by ross

This is already done, you can believe it or not, but since it would be 'ugly' to do only this, I decided to make an intro.

One doesn't preclude the other. Really.
Besides, you did accept the challenge and it wasn't about writing an intro.

Originally Posted by ross

As you said yourself, there was no deadline, so i decided to do things 'right'.
The code is mine and I manage it as I think is best, can I?

Sure you can, but this sends a different message than the one you want.
And the challenge is enough for having it "right".

Originally Posted by ross

I do not agree.
The fundamental purpose is also the usability of this technique.
That is, to make it clear that you don't need a powerful CPU (or an AGA machine) to break the DMA limits of audio, but even a measly A500 is enough.

And i told you that for this, the challenge is perfectly fine.
Remember, you don't just have to send audio, you also need to decrunch it !

Originally Posted by ross

Ok, so after you've seen the intro you'll tell me how you'll do the same thing with the CPU and what frequency it should have

Be assured i will... provided there is anything at all to see.

Originally Posted by ross

I was talking about the full intro here of course..

Making me wonder why you insist so much on this. Oh, wait, there is an easy answer.

Originally Posted by ross

Yes, I spelled it wrong, I just meant to say it's been something we've been waiting for years (since 1985..) so a month doesn't make a difference.

I doubt that in 1985 anyone was waiting for this.
But the situation has changed. Before, there was only theoretical discussion, saying at best that it is perhaps doable. Nothing to wait for. Now, there is someone not only saying it is possible, but that he could actually do it !

Originally Posted by ross

No, if for any reason I don't complete the intro, I will release the code as it stands.

Why not doing this right now ? That would be enough to make me STFU

Originally Posted by ross

It's not just me who owns it, so others in case will be able to.

Then send it to me too, so i can be one of those proud owners...

Originally Posted by ross

But what are we discussing anyway?

My experience tells me that if someone says he has some code doing something that seems incredible but refuses categorically to show anything, then he actually has nothing at all to show. I'd never have thought you were the type, though.

Originally Posted by ross

I repeat, you just have to be patient and eventually you will see something.
How and when, I decide.

Sure, easy way to get out.
Will you still say the same thing if i recall you one year from now ?

Originally Posted by ross

But dammit, I wanted the stupid intro to be a surprise and now we all know there is going to be.

And expectations will be high, so it will have to be even better than it was planned.. damn it.

Well, it will be as it will be, don't expect too much (but copper audio ).

Perhaps you should just have released simple copper audio proof of concept and kept quiet about the intro...
Then release the unexpected intro : one blow to stun, one blow to finish !

I don't think the expectations are higher now. Just do it !

That said, it's not as easy as it looks.
If you use fixed beam positions in the copper list to send audio data, you'll necessarily either miss a write or write once too many. It is not dividable.
And remember that missing samples makes the challenge to fail (otherwise i can do the same under OS, ha !).
So you have to rewrite not only audio data, but also copper wait instructions. Or store a copper list that's so huge i can't even imagine.
This will take significant cpu toll.
Add to this all the dma clocks that will be used by the copper itself, which will slow down the cpu.
Note that an interrupt could eventually not save registers at all, using some that are not used by main code - we can do this as we're not running under OS. So much for interrupt overhead.
So copper audio better than cpu audio ? Really ?

[ross]

The last part of your previous message is very interesting.
If I didn't know that it's something that can be done (and that I have done) I would consider the challenge impossible, even more on OCS 7MHz machines..

Ok, we've the title for the intro: "Impossible challenge".
---

Another person added to the Copper-Audio-solo pre-'intro'.
Who received it can comment here on the thread, but it is his decision to do it (but only regarding its functioning or not ).

---
@meynaf: have you considered this may be a late April Fool?

[meynaf]

Originally Posted by ross

The last part of your previous message is very interesting.
If I didn't know that it's something that can be done (and that I have done) I would consider the challenge impossible, even more on OCS 7MHz machines..

But have you really done it ?
You didn't say anything about how you could/would cope with what I wrote above.

Originally Posted by ross

@meynaf: have you considered this may be a late April Fool?

This challenge isn't an April's Fool.
If your reply was one, you can now just admit that you failed the challenge.

[a/b]

Yeah, I didn't hear any touch me's. Clearly a fail! ;P

[ross]

Originally Posted by a/b

Yeah, I didn't hear any touch me's. Clearly a fail! ;P

Only for the final version

[Toni Wilen]

I had one version almost 2 weeks ago for testing and scope/logic analyzer checking to confirm it does not have any glitches. It worked perfectly but was really boring to "watch"

btw, why would it be impossible? Copper MOVEs "only" need to be perfectly cycle-accurately timed.

[ross]

Thanks Tony for sharing your experience.
I take this opportunity to thank you again for the fantastic WinUAE!

Of course the chipset emulation need to be cycle exact for my code to work.
We did several tests/debugs for the audio part of the Amiga and it is thanks to WinUAE that I was able to create the code.

[meynaf]

And me, i can't have a version ?

[meynaf]

Originally Posted by Toni Wilen

I had one version almost 2 weeks ago for testing and scope/logic analyzer checking to confirm it does not have any glitches. It worked perfectly but was really boring to "watch"

Let me guess, it was a square wave ?

Originally Posted by Toni Wilen

btw, why would it be impossible? Copper MOVEs "only" need to be perfectly cycle-accurately timed.

Which in turn needs to constantly redo the timing as number of per-frame cycles isn't dividable by anything useful as a frequency.

[ross]

Originally Posted by meynaf

Which in turn needs to constantly redo the timing as number of per-frame cycles isn't dividable by anything useful as a frequency.

You are right, but as usual with the Amiga you can/need to be creative to overcome the limits.

The problem is not so much recalculating the audio/video synchronization per frame (it suffices to have computing power and bandwidth on the bus available to regenerate the copper list), but to do it in a fast and usable way.
But I won't say a word more about that for now

What's the fun when a magician tells you how he did a trick?

[TCD]

Originally Posted by ross

What's the fun when a magician tells you how he did a trick?

No idea what it is, but now I really want to see the magic trick