mpega.library faster than itself

[meynaf]

Originally Posted by Thorham

Maybe you can with palette based screen modes

Sure, but your desktop surely isn't in one of those modes, is it ?

Originally Posted by Thorham

So this does both in one go, eh? Doesn't that still mean the huffman decoding simply has to be written to output the variable length data, after which the scaling and re-quantization are handled Maybe I just don't get enough of it, yet

I dunno. Anyway it's more than enough to make the code unreadable

Originally Posted by Thorham

95% is pretty steep. I suppose optimizing the 14bit routine really should be done then. Although I still believe most of the gain will come from finding optimizations in the really heavy parts of the code

Yeah, 95%, when it's not 100% until the last few seconds. When it's fast enough at all, of course. And all of that is with quality=medium, not high. And you won't play a 256kbps file in medium quality (at least not on a 030).
Ah, and, yes, did I say it needed to be set up in mono, not stereo ?

Originally Posted by Thorham

It's a big shame the audio dma can only be doubled by doubling the screen scan rate, otherwise the down-sampling wouldn't be needed and one could just chop off two bits, would be faster and sound better.

This wasn't a big deal in 1985, but, yes, in AGA they should have done something with that...

Originally Posted by Thorham

By the way, have you ever thought of a 15bit routine by any chance? I know I should probably not be bringing this up (will slow things down), but I just couldn't resist

I'll do it if you can tell me how to output 15 bit (in a hardware point of view). Sure !

[FrenchShark]

Originally Posted by meynaf

I don't know if it's better to rewrite it all or start from its actual code.
I started both but the rewrite stopped 'coz lack of understanding of the layer3 (that is, lack of docs).

Hello Meynaf,

I have the MPEG audio and video specification in PDF.
If you need them, tell me how I can send that to you.
[EDIT] I just found the CD, it is actually in Word format, I have MPEG 1 and 2 (and maybe 4).
If you need them as PDF, I can convert them.
I have also the test bitstreams for layers 1,2,3.

Regards,

Frederic

[Thorham]

Originally Posted by FrenchShark

Hello Meynaf,

I have the MPEG audio and video specification in PDF.
If you need them, tell me how I can send that to you.

Regards,

Frederic

Welcome to the eab, FrenchShark

I suppose you can just post again and attach the pdf to the post, unless it's very large then you can upload it to the zone. I know he'll appreciate it if has the info he needs, and others may, too, and I know I would. If you do put it in the zone, I'd wait a couple of days (meynaf is probably not going to be online here for a few days), as files only stay in the zone for a week, so I'd suggest you try attaching it first.

Merry Christmas

[FrenchShark]

Originally Posted by Thorham

Welcome to the eab, FrenchShark

I suppose you can just post again and attach the pdf to the post, unless it's very large then you can upload it to the zone. I know he'll appreciate it if has the info he needs, and others may, too, and I know I would. If you do put it in the zone, I'd wait a couple of days (meynaf is probably not going to be online here for a few days), as files only stay in the zone for a week, so I'd suggest you try attaching it first.

Merry Christmas

Hello,
here is the MPEG2 Audio spec (568 KB)

PS: Meynaf is working on a JPEG decoder too. Does he need the JFIF spec as well ?

Regards,

[meynaf]

Unfortunately, I already had the Fraunhofer mpeg spec. If you have an attentive look at it, you'll see that explanations for the most complex things are... code (when, of course, it's not a whole bunch of mathematics). But thanks anyway.

Do I need the jpeg spec ? I don't know. I'm not going to rewrite things from scratch, the IJG code has all the structure and infos I need, and I'll simply do in asm what they do in c. But post it anyway (in the appropriate thread), it's always interesting.

I'll be online tomorrow, and once a week (if I can) until mid-january.
But do as if I was here and post everything you find. Just because I'm not here doesn't mean things can't advance

And, yes, happy (whatever you want) !
(don't drink too much )

[Thorham]

Originally Posted by meynaf

Sure, but your desktop surely isn't in one of those modes, is it ?

Absolutely not. That would just be insane

Originally Posted by meynaf

I dunno. Anyway it's more than enough to make the code unreadable

Come on, it can't be that hard

Originally Posted by meynaf

Yeah, 95%, when it's not 100% until the last few seconds. When it's fast enough at all, of course. And all of that is with quality=medium, not high. And you won't play a 256kbps file in medium quality (at least not on a 030).
Ah, and, yes, did I say it needed to be set up in mono, not stereo ?

Ouch, that's really something. Sorry for asking, but why do you even want to do it on a '30 if you know it's not going to produce good audio quality? Seems to me that spending time on your gfx viewer is a lot more useful. There's a whole plethora of options not present in other viewers that can be included in yours, making it the best one yet, 'all' it takes is getting the jpeg decoding up to speed

Originally Posted by meynaf

This wasn't a big deal in 1985, but, yes, in AGA they should have done something with that...

Doesn't that just require using a separate frequency generator, like a crystal? Typical commodore stuff

Originally Posted by meynaf

I'll do it if you can tell me how to output 15 bit (in a hardware point of view). Sure !

The basic idea is to use a single channel for 14bit sound and then combining two channels to get a 15bit channel. Simply turn on/off one of the channels depending on the extra bit, and make sure the two channels are playing the same sample at the same volume. I guess this should work in theory, since I've never tried it.

The problem is, of course, that it will rely on a ton of interrupts or on the copper, which requires a 16 color image or less to be useful. I thought it would be interesting to mention, as I haven't actually seen this in action, and I wanted your opinion on this. But since it's rather limited/slow, it probably won't benefit anyone, unless you kill the os.

[meynaf]

I don't know if I will be able to produce good audio quality, but the goal here is rather to produce audio that is *as good as possible*. On some files, mpega already produces a good quality.

Of course I can work on my viewer, but I don't want to drop my audio project. Sometimes I can become quite stubborn
I agree there is a whole plethora of options that could be included in it. But do I want them ? Wouldn't it then become a bloatware filled with a bunch of useless options ?

Doesn't that just require using a separate frequency generator, like a crystal?

I'm no electronician and I don't know what can be done to accelerate AGA... but I'm pretty sure it's more complex than just raising its clock speed !

The basic idea is to use a single channel for 14bit sound and then combining two channels to get a 15bit channel.

Then I'm afraid I have to deceive you. Playing in 14 bit already requires *two* channels.
One is playing at maximum volume (64), and does the 8 leftmost bits. The other is playing at minimum volume (1) and is playing the remaining 6.
Furthermore, the D/A converters aren't exactly linear, and even vary from a Miggy to another, so some sort of calibration can achieve a further gain on quality. The 14-bit calibration system is given in the Play16 archive, available on Aminet.

Anyway, I don't think that, if we could play 15 bits or even 16, we would hear any difference. Try a 22 khz wave on a PC (16-bit) then on your Miga (with calibrated 14bit output) - with good loudspeakers, the same on both sides if possible - and tell me who's the best ! (take care : last time I did that, the pc has lost...)

[Thorham]

Originally Posted by meynaf

I don't know if I will be able to produce good audio quality, but the goal here is rather to produce audio that is *as good as possible*. On some files, mpega already produces a good quality.

Understood. I just wanted to know your motivation

Originally Posted by meynaf

Of course I can work on my viewer, but I don't want to drop my audio project. Sometimes I can become quite stubborn
I agree there is a whole plethora of options that could be included in it. But do I want them ? Wouldn't it then become a bloatware filled with a bunch of /useless/ options ?

Well, a lot depends on the nature of the options. Of course there are silly options (strange, I can't think of any!), but there are probably plenty of useful ones which won't make the executable that much bigger. A good example is the scaling: Yields nice results and takes up very little space in the code, and can actually make it faster, especially when used with very large images. These are the kind of functions I'm talking about: Getting a lot for very little

Originally Posted by meynaf

I'm no electronician and I don't know what can be done to accelerate AGA... but I'm pretty sure it's more complex than just raising its clock speed !

It might not be. Doubling the display scan rate seems to just double the frequency of the audio dma because they're probably linked. This saves adding another frequency generator, and knowing Commodore this seems to make some sense. Then again, I'm not an engineer, either

Originally Posted by meynaf

Then I'm afraid I have to deceive you. Playing in 14 bit already requires *two* channels.
One is playing at maximum volume (64), and does the 8 leftmost bits. The other is playing at minimum volume (1) and is playing the remaining 6.
Furthermore, the D/A converters aren't exactly linear, and even vary from a Miggy to another, so some sort of calibration can achieve a further gain on quality. The 14-bit calibration system is given in the Play16 archive, available on Aminet.

Yes, that's true, however that is the dma method. The method I've thought of doesn't require dma and thus works with only one channel. The trick is to make a table which converts the 16bit audio to an eight bit sample and a six bit volume component. The calibration can then be applied to the table. However, as said, this method remains untested, and I still have to figure out how to make the table...

Originally Posted by meynaf

Anyway, I don't think that, if we could play 15 bits or even 16, we would hear any difference. Try a 22 khz wave on a PC (16-bit) then on your Miga (with calibrated 14bit output) - with good loudspeakers, the same on both sides if possible - and tell me who's the best ! (take care : last time I did that, the pc has lost...)

I once converted good quality, loud game music (from Trickster) to eight bit stereo in 24khz. Because the music uses the upper eight bits very well the quality is pretty damn good, and yes, thats with just eight bits. Extra bits make the softer components of a sample sound a lot better. I will try your experiment, just to know if a few more bits would make a difference! Damn, now I have to find the calibration file I made once

[meynaf]

Originally Posted by Thorham

Understood. I just wanted to know your motivation

What I want is to be able to play those (very) common MP3 files with the best possible quality. Here gaining speed is also gaining quality !

Originally Posted by Thorham

Well, a lot depends on the nature of the options. Of course there are silly options (strange, I can't think of any!), but there are probably plenty of useful ones which won't make the executable that much bigger. A good example is the scaling: Yields nice results and takes up very little space in the code, and can actually make it faster, especially when used with very large images. These are the kind of functions I'm talking about: Getting a lot for very little

Ahem. Just noticed we're off topic in here
To get my answer, please go on the jpeg topic.

Originally Posted by Thorham

It might not be. Doubling the display scan rate seems to just double the frequency of the audio dma because they're probably linked. This saves adding another frequency generator, and knowing Commodore this seems to make some sense. Then again, I'm not an engineer, either

I think it's probably more to keep the things in sync rather than to just spare a quartz. At least it was that in the original design
Btw I wonder how difficult it could be to make a clone of AGA chips with an FPGA... Errrh... off-topic again...

Originally Posted by Thorham

Yes, that's true, however that is the dma method. The method I've thought of doesn't require dma and thus works with only one channel. The trick is to make a table which converts the 16bit audio to an eight bit sample and a six bit volume component. The calibration can then be applied to the table. However, as said, this method remains untested, and I still have to figure out how to make the table...

Oh, I see what you want to do. That's sorting all combinations of 8-bit data and 6-bit volumes, to get 14-bit output, isn't it ?
The calibration will be a real pain...

But if you try that, you'll never be able to keep the volume and the data in sync. Then you'll add noise. Then you'll lose all the (potential) benefit.

And you really can't do 14 bit output with just one channel : it is true that you can write dff0a8/dff0aa in one go, but you'll get two data values for one volume, and have ~0.3 microseconds at best between them because they really won't be written simultaneously. Of course you can write two identical data... but this won't solve the delay. Things become worse, of course, when you use 2 channels or more...

If you plan on killing the OS, then just try to perform true 44.1 khz replay, it might be much better in quality than just adding one bit (well, ok, you can try both at once). I'm not sure it's even possible because of channel sync again.
But it will become useless if you play e.g. a wave file, as those usually don't fit into memory : you need some i/o and this requires the OS nowadays.
And if you target an MP3, you'll end up using so much cpu for your replay that there will be not much (and surely not enough) left to decode the file...

Originally Posted by Thorham

I once converted good quality, loud game music (from Trickster) to eight bit stereo in 24khz. Because the music uses the upper eight bits very well the quality is pretty damn good, and yes, thats with just eight bits. Extra bits make the softer components of a sample sound a lot better. I will try your experiment, just to know if a few more bits would make a difference! Damn, now I have to find the calibration file I made once

With 8 bit sounds you have to somehow saturate your sound to get the best out of it. It also depends a lot on what type of sound you're hearing, some are good enough while others are not (you'll have more trouble with a sweet feminine voice than with drums !).

More bits are useful, but even if you use true 16 bits, you still have the parasites made by the other circuitry, mostly the cpu. You'll then end up with 14 bit output, if not 12.

Originally Posted by Thorham

Damn, now I have to find the calibration file I made once

You'd better do so. I've played some files on my second A1200 (yes I have two) and noticed a lot of jitter, until I did the calibration, which ended up pretty different from the one I did long ago for my main machine. The Amiga DACs must have some sort of personality

[Thorham]

Originally Posted by meynaf

Ahem. Just noticed we're off topic in here
To get my answer, please go on the jpeg topic.

Yup, you're right. Only audio should go in here.

Originally Posted by meynaf

I think it's probably more to keep the things in sync rather than to just spare a quartz. At least it was that in the original design
Btw I wonder how difficult it could be to make a clone of AGA chips with an FPGA... Errrh... off-topic again...

One last word about it then. Check out the minimig project on the eab.

Originally Posted by meynaf

But if you try that, you'll never be able to keep the volume and the data in sync. Then you'll add noise. Then you'll lose all the (potential) benefit.

And you really can't do 14 bit output with just one channel : it is true that you can write dff0a8/dff0aa in one go, but you'll get two data values for one volume, and have ~0.3 microseconds at best between them because they really won't be written simultaneously. Of course you can write two identical data... but this won't solve the delay. Things become worse, of course, when you use 2 channels or more...

If you plan on killing the OS, then just try to perform true 44.1 khz replay, it might be much better in quality than just adding one bit (well, ok, you can try both at once). I'm not sure it's even possible because of channel sync again.
But it will become useless if you play e.g. a wave file, as those usually don't fit into memory : you need some i/o and this requires the OS nowadays.
And if you target an MP3, you'll end up using so much cpu for your replay that there will be not much (and surely not enough) left to decode the file...

Yes, you might be right. It's just a theory, however. A lot depends on how fast the custom chip regs can be written. On an a500 you can use the cpu to replay at 80khz, if I remember correctly, and on a 68030 it might be possible to write to the regs faster. It really has to be tested. Of course, if it works, it will only be useful for uncompressed audio on a '030. On a '060 it might be fast enough. But I really don't know. The normal 14bit routine has to sync the channels, too: First you set channel 1, then channel 2, and even though this can't be done at the same time, the audio quality does improve a lot, so 15bit might still be possible, if slow.

Originally Posted by meynaf

With 8 bit sounds you have to somehow saturate your sound to get the best out of it. It also depends a lot on what type of sound you're hearing, some are good enough while others are not (you'll have more trouble with a sweet feminine voice than with drums !).

More bits are useful, but even if you use true 16 bits, you still have the parasites made by the other circuitry, mostly the cpu. You'll then end up with 14 bit output, if not 12.

I hadn't thought of that, and it's certainly worth testing. If it's true, then even if 15bit would work, it wouldn't make a difference. Maybe I should just pop the whole idea in the bin

Originally Posted by meynaf

You'd better do so. I've played some files on my second A1200 (yes I have two) and noticed a lot of jitter, until I did the calibration, which ended up pretty different from the one I did long ago for my main machine. The Amiga DACs must have some sort of personality

Hmm, the calibration file doesn't seem to do much on my miggy! I'll probably have to redo the calibration again just make sure that I really did get it right the first time. It's just a shame that apart from testing purposes, I don't really have a use for it

Anyway, have you made any progress on the huffman decoding thing? I haven't looked at it for a while, but when I did, I really didn't find anything usefull, so I hope you have.

[meynaf]

Originally Posted by Thorham

One last word about it then. Check out the minimig project on the eab.

Looks promising. But they're apparently wanting to do only the existing hardware, with accurate timing ; I would prefer a more advanced thing, like AGA was for its time (some sort of AAA, but with 68k, not ppc).
I dream of 8 or more dma channels, with 8/16 bit output, 256 levels of volume, higher base clock and 32-bit period values, no 28 khz limitation, no timing problems when stopping/restarting channels...
(/me sighs)

Originally Posted by Thorham

Yes, you might be right. It's just a theory, however. A lot depends on how fast the custom chip regs can be written. On an a500 you can use the cpu to replay at 80khz, if I remember correctly, and on a 68030 it might be possible to write to the regs faster. It really has to be tested. Of course, if it works, it will only be useful for uncompressed audio on a '030. On a '060 it might be fast enough. But I really don't know. The normal 14bit routine has to sync the channels, too: First you set channel 1, then channel 2, and even though this can't be done at the same time, the audio quality does improve a lot, so 15bit might still be possible, if slow.

A 030 is fast enough to go above 28 khz in interrupts even under the os. I did this long ago, but the voices didn't keep sync'ed.

The normal 14bit routine syncs the channels by using the dma and that seems the only right way to do so. Maybe starting them with the dma and taking over with the cpu might help.

Originally Posted by Thorham

I hadn't thought of that, and it's certainly worth testing. If it's true, then even if 15bit would work, it wouldn't make a difference. Maybe I should just pop the whole idea in the bin

I suggest you make all possible tests before putting anything in the trashcan

Originally Posted by Thorham

Hmm, the calibration file doesn't seem to do much on my miggy! I'll probably have to redo the calibration again just make sure that I really did get it right the first time. It's just a shame that apart from testing purposes, I don't really have a use for it

No waves to play with Play16 ? No multi-channel modules to play on DeliTracker with 14-bit noteplayer ?

I don't know a lot on the effect on a calibration file vs nothing, but a calibration file for another machine sure did a lot of difference for me !

Originally Posted by Thorham

Anyway, have you made any progress on the huffman decoding thing? I haven't looked at it for a while, but when I did, I really didn't find anything usefull, so I hope you have.

Errh... Errm... Not on the huffman decoding.

But I now have the architecture for a player, that is, a central part which is pretty much like what I did for my viewer. There is even some common code (file reading, buffer handling)

[Thorham]

Originally Posted by meynaf

Looks promising. But they're apparently wanting to do only the existing hardware, with accurate timing ; I would prefer a more advanced thing, like AGA was for its time (some sort of AAA, but with 68k, not ppc).
I dream of 8 or more dma channels, with 8/16 bit output, 256 levels of volume, higher base clock and 32-bit period values, no 28 khz limitation, no timing problems when stopping/restarting channels...
(/me sighs)

To stay off-topic, personally, doing the existing classic hardware is already awesome, and would keep the Amiga alive for decades to come. AAA is something I have read about in relation to the minimig project, so there is a chance it's going to happen.

Originally Posted by meynaf

A 030 is fast enough to go above 28 khz in interrupts even under the os. I did this long ago, but the voices didn't keep sync'ed.

The normal 14bit routine syncs the channels by using the dma and that seems the only right way to do so. Maybe starting them with the dma and taking over with the cpu might help.

Or use audio dma for the sample part, and the cpu/copper dma for the volume part. But then you're limited to 28khz again, aaaaargh

Originally Posted by meynaf

I suggest you make all possible tests before putting anything in the trashcan

You're right, of course. If it does work and makes a difference, it would be a waste of a good idea. The calibration is going to be a pain though. I don't have a clue on where to start.

Originally Posted by meynaf

No waves to play with Play16 ? No multi-channel modules to play on DeliTracker with 14-bit noteplayer ?

I usually play everything on my pc. Furthermore, I only have a couple of digibooster mods, which require ahi, and the combination of ahi and digibooster just refuses to work well on my system. The only things I play on my miggy, are mod, thx and sid files.

Originally Posted by meynaf

I don't know a lot on the effect on a calibration file vs nothing, but a calibration file for another machine sure did a lot of difference for me !

I think this might be a little software problem. I'll have to fiddle around with it, and see what the problem is, as I seem to remeber that it did make a difference. It's also possible that the good calibration file got wiped after the full system reinstall I did last year, and I just backed up a half way finished file

Originally Posted by meynaf

Errh... Errm... Not on the huffman decoding.

But I now have the architecture for a player, that is, a central part which is pretty much like what I did for my viewer. There is even some common code (file reading, buffer handling)

Yay But you still need the stupid huffman decoding thing. It never seizes to amaze me how difficult some things can be.... until you finally figure it out and you think 'damn, that was just too easy'. But no, really, it shouldn't be that hard, the hard part is finding the right info on what is to be done. In the end you may still have to resort to hand-compiling a bunch of c code, or paining your brain to figure out what happens in the c code. And if that is the case, I wish you the best of luck.

[meynaf]

Originally Posted by Thorham

To stay off-topic, personally, doing the existing classic hardware is already awesome, and would keep the Amiga alive for decades to come. AAA is something I have read about in relation to the minimig project, so there is a chance it's going to happen.

Wait and see...

Originally Posted by Thorham

Or use audio dma for the sample part, and the cpu/copper dma for the volume part. But then you're limited to 28khz again, aaaaargh

I've never seen an app using the copper for audio. Looks more like a theoretical possibility to me.
Then again, I don't see the point in playing 44.1 like this : with 16Mb you can have one minute and a half of music, or so.

Originally Posted by Thorham

You're right, of course. If it does work and makes a difference, it would be a waste of a good idea. The calibration is going to be a pain though. I don't have a clue on where to start.

Like you did for me, I wish you the best of luck.

Originally Posted by Thorham

I usually play everything on my pc. Furthermore, I only have a couple of digibooster mods, which require ahi, and the combination of ahi and digibooster just refuses to work well on my system. The only things I play on my miggy, are mod, thx and sid files.

AHI isn't good on systems without a sound board. Too high cpu load, a lot of sample clipping if the boost value is too high, and the rendering quality isn't as good as DeliTracker's 14 bit note player.

Originally Posted by Thorham

I think this might be a little software problem. I'll have to fiddle around with it, and see what the problem is, as I seem to remeber that it did make a difference. It's also possible that the good calibration file got wiped after the full system reinstall I did last year, and I just backed up a half way finished file

Making a new one isn't that long...

If you're using ahi, then I suggest you lower the "boost" value, else you'll hear a lot of noise (as it doesn't saturate correctly).

Originally Posted by Thorham

Yay But you still need the stupid huffman decoding thing. It never seizes to amaze me how difficult some things can be.... until you finally figure it out and you think 'damn, that was just too easy'. But no, really, it shouldn't be that hard, the hard part is finding the right info on what is to be done. In the end you may still have to resort to hand-compiling a bunch of c code, or paining your brain to figure out what happens in the c code. And if that is the case, I wish you the best of luck.

the hard part is finding the right info on what is to be done : I couldn't have explained it better !

[Thorham]

Originally Posted by meynaf

I've never seen an app using the copper for audio. Looks more like a theoretical possibility to me.

The copper seems ideal for this, since it has a bandwidth of more then a megabyte per sec! The only two requirements are that 1. the copper has to be able to do each register write in eight lowres pixels, which limits the number of colors on screen, and possibly resolution (this can even work on a plain a500), and 2. the copper works contiguously, without any breaks (which I don't know).

Originally Posted by meynaf

Then again, I don't see the point in playing 44.1 like this : with 16Mb you can have one minute and a half of music, or so.

Yes, that's a problem. You'd have to leave the os on, and use a custom copper list for the audio handling. The things the system copper list handles, can just be done in with the vbl interrupt+cpu. Also, there is more than enough copper time left to generate c64 style 'raster' interrupts to handle things such as sliding screens up and down. The back draw would be that on aga you're always limited to 16 color screens.

Originally Posted by meynaf

Like you did for me, I wish you the best of luck.

Thank you The above statement has made me seriously consider trying it out anyway. It would be just plain awesome to be able to break the stupid 28khz dma limit just like that. But... the system would require some patches, probably nothing complicated, but still. Well, if the method itself works, there are always people who can help with the system part.

Originally Posted by meynaf

AHI isn't good on systems without a sound board. Too high cpu load, a lot of sample clipping if the boost value is too high, and the rendering quality isn't as good as DeliTracker's 14 bit note player.

Good to know! So how's Delitracker's Digibooster mod handling? If it's any good, I'm going to use it alongside Hippoplayer, which uses, guess what, ahi for this, although it does use it's own 14bit routine for things like s3m mods.

Originally Posted by meynaf

Making a new one isn't that long...

If you're using ahi, then I suggest you lower the "boost" value, else you'll hear a lot of noise (as it doesn't saturate correctly).

It would be really cool to get rid of ahi completely, and just use a player's own 14bit routine, since, as you've said, that's better then ahi's 14bit.

By the way, the audio channels can modulate each others volume. Does that mean you can effectively set a channels volume using eight bits? Pobably not, or it would have been used. Just asking.

[meynaf]

Originally Posted by Thorham

The copper seems ideal for this, since it has a bandwidth of more then a megabyte per sec! The only two requirements are that 1. the copper has to be able to do each register write in eight lowres pixels, which limits the number of colors on screen, and possibly resolution (this can even work on a plain a500), and 2. the copper works contiguously, without any breaks (which I don't know).

That could be a good starting point : see how the copper behaves.

Originally Posted by Thorham

Yes, that's a problem. You'd have to leave the os on, and use a custom copper list for the audio handling. The things the system copper list handles, can just be done in with the vbl interrupt+cpu. Also, there is more than enough copper time left to generate c64 style 'raster' interrupts to handle things such as sliding screens up and down. The back draw would be that on aga you're always limited to 16 color screens.

You may keep the OS running but lock the screen, so that no screen but yours is displayed as long as you play something.
To avoid screen scrolling you can set the exclusive flag, like I do for my viewer when it's needed for vertical screen centering (have you noticed that most, if not all, viewers don't center the image vertically ?).
Screen switching would then either be impossible (I don't know how to do that), or stop the replay.

Originally Posted by Thorham

Thank you The above statement has made me seriously consider trying it out anyway. It would be just plain awesome to be able to break the stupid 28khz dma limit just like that. But... the system would require some patches, probably nothing complicated, but still. Well, if the method itself works, there are always people who can help with the system part.

If you can make it work, I'd like to help with the system part, sure !

Originally Posted by Thorham

Good to know! So how's Delitracker's Digibooster mod handling? If it's any good, I'm going to use it alongside Hippoplayer, which uses, guess what, ahi for this, although it does use it's own 14bit routine for things like s3m mods.
It would be really cool to get rid of ahi completely, and just use a player's own 14bit routine, since, as you've said, that's better then ahi's 14bit.

Alas, Delitracker's DigiboosterPro player uses ahi. But it has a little configuration window, and when things go wrong on the quality it usually only needs to decrease that boost value. Anyway it works for me like that

Originally Posted by Thorham

By the way, the audio channels can modulate each others volume. Does that mean you can effectively set a channels volume using eight bits? Pobably not, or it would have been used. Just asking.

I don't think so, that would have been too nice !
And there would be no reason to use the full 8 bits here where dff0a8 can accept 16 bits and is limited to 6.
What I know here is that values above 64 don't make a difference from 64, but I didn't test the upper bits (they're more than likely ignored).

[Thorham]

Originally Posted by meynaf

That could be a good starting point : see how the copper behaves.

Exactly. For instance, how many moves can the copper execute per frame (long and short frames)? And of course these numbers are also needed to know how close it can get to 44.1 khz: Can it get there just like that, or do you have to use extra skips? These things should be very easy to figure out.

Originally Posted by meynaf

You may keep the OS running but lock the screen, so that no screen but yours is displayed as long as you play something.
To avoid screen scrolling you can set the exclusive flag, like I do for my viewer when it's needed for vertical screen centering (have you noticed that most, if not all, viewers don't center the image vertically ?).
Screen switching would then either be impossible (I don't know how to do that), or stop the replay.

I've never noticed viewers not centering vertically. Guess I just haven't paid it any thought... Anyway, those are possibilities, but only as a last resort. I really want the screen handling to work as normal. That's why it would be nice if all the system copper stuff could be handled with the cpu, so the user can continue doing other things on their miggy without interfering with the sound.

Originally Posted by meynaf

If you can make it work, I'd like to help with the system part, sure !

Thanks I'll let you know if the copper can be used for audio dma purposes, whould be cool for uncompressed formats, including direct cd playing!

Originally Posted by meynaf

Alas, Delitracker's DigiboosterPro player uses ahi. But it has a little configuration window, and when things go wrong on the quality it usually only needs to decrease that boost value. Anyway it works for me like that

Cool. I'll just download the latest version.

Originally Posted by meynaf

don't think so, that would have been too nice !
And there would be no reason to use the full 8 bits here where dff0a8 can accept 16 bits and is limited to 6.
What I know here is that values above 64 don't make a difference from 64, but I didn't test the upper bits (they're more than likely ignored).

This is not exactly what I meant: When modulation is turned on for a channel, it's sample data influences the next channel's volume. But, does it affect the channels volume through it's volume register, or does it affect the channel volume in some other way? It probably does the first, but I just want to make sure (I agree that would be rather too nice).

[meynaf]

Originally Posted by Thorham

Exactly. For instance, how many moves can the copper execute per frame (long and short frames)? And of course these numbers are also needed to know how close it can get to 44.1 khz: Can it get there just like that, or do you have to use extra skips? These things should be very easy to figure out.

The copper can execute enough moves per scanline to reach 100 khz or so, because 28 (in fact 31) khz replay only require 4 moves per line (I'm sure the copper can do at least 16, if not many more).
But there can be problems with long/short frames, I'm not sure but it's probably the reason why we're limited to 28, not 31 (horizontal freq in pal is 15.5 khz).

Originally Posted by Thorham

I've never noticed viewers not centering vertically. Guess I just haven't paid it any thought... Anyway, those are possibilities, but only as a last resort. I really want the screen handling to work as normal. That's why it would be nice if all the system copper stuff could be handled with the cpu, so the user can continue doing other things on their miggy without interfering with the sound.

You could use just one instruction of the copper to make a copper interrupt and then do you stuff with the cpu, but :
- if it's too busy (i.e. higher priority interrupts interfere) it can miss the deadline,
- if the copper uses all chipmem cycles there will be nothing left for the cpu,
- and some lower priority interrupts won't like it.

I think it would be better to let the copper do its stuff, its bandwidth is more than enough for that. It wouldn't require more than interleaving the audio with the rest of the copper list, and maybe raise the inter-screen gap a little. Just a guess.

Originally Posted by Thorham

Thanks I'll let you know if the copper can be used for audio dma purposes, whould be cool for uncompressed formats, including direct cd playing!

Would be cool, sure. Some compressed formats may even be light enough to be played this way, who knows...

Originally Posted by Thorham

This is not exactly what I meant: When modulation is turned on for a channel, it's sample data influences the next channel's volume. But, does it affect the channels volume through it's volume register, or does it affect the channel volume in some other way? It probably does the first, but I just want to make sure (I agree that would be rather too nice).

The docs say it affects the channel volume, and there's no reason to think it does otherwise.

[Thorham]

Originally Posted by meynaf

he copper can execute enough moves per scanline to reach 100 khz or so, because 28 (in fact 31) khz replay only require 4 moves per line (I'm sure the copper can do at least 16, if not many more).
But there can be problems with long/short frames, I'm not sure but it's probably the reason why we're limited to 28, not 31 (horizontal freq in pal is 15.5 khz).

Actually, the copper can do 55 or 56 moves per line: 40 in the visible area and 15 or 16 (I think it's 15) in the border. This amounts to over a megabyte (1.5 megs or so) a sec. Way more than fast enough. This does limit the nr of colors on screen. On aga, anything above 16 colors will slow down the copper and make it work less accurate. In 16 colors or less, one copper move takes exactly eight lowres pixels to execute. I just hope this works in hires-lace, too.

Originally Posted by meynaf

You could use just one instruction of the copper to make a copper interrupt and then do you stuff with the cpu, but :
- if it's too busy (i.e. higher priority interrupts interfere) it can miss the deadline,
- if the copper uses all chipmem cycles there will be nothing left for the cpu,
- and some lower priority interrupts won't like it.

I think it would be better to let the copper do its stuff, its bandwidth is more than enough for that. It wouldn't require more than interleaving the audio with the rest of the copper list, and maybe raise the inter-screen gap a little. Just a guess.

Seeing how fast the copper is for sound, everything can definitely be interleaved. I just hope it's somehow possible to mix this with the system stuff.

Originally Posted by meynaf

Would be cool, sure. Some compressed formats may even be light enough to be played this way, who knows...

Which ones are those? I only really know the lossy ones, and they're probably all pretty heavy duty...

Originally Posted by meynaf

The docs say it affects the channel volume, and there's no reason to think it does otherwise.

The volume regs, eh? Well, it would've been too good to be true anyway.

[meynaf]

Originally Posted by Thorham

Actually, the copper can do 55 or 56 moves per line: 40 in the visible area and 15 or 16 (I think it's 15) in the border. This amounts to over a megabyte (1.5 megs or so) a sec. Way more than fast enough. This does limit the nr of colors on screen. On aga, anything above 16 colors will slow down the copper and make it work less accurate. In 16 colors or less, one copper move takes exactly eight lowres pixels to execute. I just hope this works in hires-lace, too.

Hires modes require twice the bandwidth, so I'm not sure it will work the same... However lace modes should be ok.

Originally Posted by Thorham

Seeing how fast the copper is for sound, everything can definitely be interleaved. I just hope it's somehow possible to mix this with the system stuff.

I suggest you simply make it work for now ; the system part will come in play later. That should be enough for a few headaches !

Originally Posted by Thorham

Which ones are those? I only really know the lossy ones, and they're probably all pretty heavy duty...

I guess it all depends on whatever cpu power is left. Anyway layer 1 or 2 mpeg audio (maybe also a-law or µ-law compressions for waves) shouldn't be that heavy.

Originally Posted by Thorham

The volume regs, eh? Well, it would've been too good to be true anyway.

If only they did for audio what they did for graphics when making AGA...
32-bit accesses... wow... but they didn't !

[Thorham]

Originally Posted by meynaf

Hires modes require twice the bandwidth, so I'm not sure it will work the same... However lace modes should be ok.

Yes, that's something that's going to have to be tested.

Originally Posted by meynaf

I suggest you simply make it work for now ; the system part will come in play later. That should be enough for a few headaches !

Good idea. It would just be nice to know if proper system integration would be possible, because if you can't do things like swapping screens, then it would become a lot less interesting to me, although it might still be cool for a music demo

Originally Posted by meynaf

I guess it all depends on whatever cpu power is left. Anyway layer 1 or 2 mpeg audio (maybe also a-law or µ-law compressions for waves) shouldn't be that heavy.

Well, even though the cpu has to copy data to chip mem, the amount of data for cd quality sound is less then 180kb per second, should be cool. So, what do they do for layer 1 and 2? Then again, how often do you run into mp1 and mp2, I havn't heard of it being used a lot.

Originally Posted by meynaf

If only they did for audio what they did for graphics when making AGA...
32-bit accesses... wow... but they didn't !

Yes, indeed. How difficult/expensive would that have been anyway? I mean, the paula itself can already handle 80khz in eight bits with the cpu (even an a500 can do that), so it seems like a small step to upgrade the audio.