mpega.library faster than itself

[meynaf]

Originally Posted by Thorham

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

It may require ugly patches and be incompatible with software such as magiccopper, but I believe it is possible.

Originally Posted by Thorham

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.

I have one mp2. Well, ok, that's not much

However, playing a wave file, though much simpler than mpeg audio, is a little bit more complex than just copying data to chipmem. I have code for this, dunno if it can be useful to you.

Originally Posted by Thorham

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.

Yes, and 80 khz comes from the speed of the cpu, not the audio hardware. In theory you can reach 3.5Mhz if setting period=1 !

[Thorham]

Originally Posted by meynaf

It may require ugly patches and be incompatible with software such as magiccopper, but I believe it is possible.

Well, I really do hope that the patches can be implemented in a clean fashion, although it would be good enough if the patches would at least not screwup anything in the system.

Originally Posted by meynaf

I have one mp2. Well, ok, that's not much

However, playing a wave file, though much simpler than mpeg audio, is a little bit more complex than just copying data to chipmem. I have code for this, dunno if it can be useful to you.

Ok, but isn't wav just a simple raw format like bmp for graphics is? If so, it should at least be similar in speed to plain copying.

Originally Posted by meynaf

Yes, and 80 khz comes from the speed of the cpu, not the audio hardware. In theory you can reach 3.5Mhz if setting period=1 !

Now theres something I didn't know! 3.5mhz is just plain awesome, not that it has any practical application , but still.

[meynaf]

Originally Posted by Thorham

Well, I really do hope that the patches can be implemented in a clean fashion, although it would be good enough if the patches would at least not screwup anything in the system.

That's difficult to estimate, as we don't have any working code for that, even in an os-unfriendly way...

Originally Posted by Thorham

Ok, but isn't wav just a simple raw format like bmp for graphics is? If so, it should at least be similar in speed to plain copying.

It's very similar to bmp. Same simplicity to handle. Same curious stuff. Same... authors.

It is as much copying as bmp is : bmp was bgr->rgb. Here it is unsigned->signed (8 bits), little endian (16 bits). Of course few people can tell why it's unsigned if 8 bits and signed if 16.
At least it isn't bottom-to-top

Things are a little bit more complex when it comes to 16 bit sounds, you have a 14-bit table that comes into play.

Here is my conversion code for a mono file (a0=src, a1=dest, d7=# of samples, d6=offset to next channel) :

cn16bl
 move.l a1,a2           ; v0 (high) - already in a1
 add.l d6,a2            ; v1 (low)
 lea d14b+$8000,a3
.loop
 move.w (a0)+,d0        ; our sample
 ror.w #8,d0            ; little -> big endian
 move.w (a3,d0.w*2),d0
 move.b d0,(a2)+        ; low
 lsr.w #8,d0
 move.b d0,(a1)+        ; high
 subq.l #1,d7
 bne.s .loop
 rts

(of course this code assumes we're not going above 28867 hz)

Originally Posted by Thorham

Now theres something I didn't know! 3.5mhz is just plain awesome, not that it has any practical application , but still.

That's theory. The base frequency is half of the main clock (-> 3546895 hz in pal). It's divided by the period to get the final frequency, so with a period of 1 you know what you get.
However, due to chipmem bandwidth, you simply can't copy the data at this rate. I also have no idea whether the DACs would follow or not.

Btw the dma can't cope with periods lower than 123 (28.8 khz), I don't know where's the real limit for a 030 (nor do I know for the copper).

[Thorham]

Originally Posted by meynaf

That's difficult to estimate, as we don't have any working code for that, even in an os-unfriendly way...

Yes, it would have to be tested. That means that two things have to be tested, as I really want to know how well the system can handle this. Just how clean are those copper wb programs? Those may give an idea of how clean/dirty the patches would become.

Originally Posted by meynaf

It's very similar to bmp. Same simplicity to handle. Same curious stuff. Same... authors.

It is as much copying as bmp is : bmp was bgr->rgb. Here it is unsigned->signed (8 bits), little endian (16 bits). Of course few people can tell why it's unsigned if 8 bits and signed if 16.
At least it isn't bottom-to-top

Things are a little bit more complex when it comes to 16 bit sounds, you have a 14-bit table that comes into play.

Here is my conversion code for a mono file (a0=src, a1=dest, d7=# of samples, d6=offset to next channel) :

That code doesn't look too slow. Perfectly doable. You can get rid of the ror.w #8,d0 if you reorganize the table, shouldn't make it any longer.

Originally Posted by meynaf

That's theory. The base frequency is half of the main clock (-> 3546895 hz in pal). It's divided by the period to get the final frequency, so with a period of 1 you know what you get.
However, due to chipmem bandwidth, you simply can't copy the data at this rate. I also have no idea whether the DACs would follow or not.

It wouldn't even be very useful. And there definitively is limit on how fast you can write the chipset regs, anyway, so you won't be able to get 3.5mhz at all.

Originally Posted by meynaf

Btw the dma can't cope with periods lower than 123 (28.8 khz), I don't know where's the real limit for a 030 (nor do I know for the copper).

I suppose you don't mean the audio dma, but I still didn't get that bit, so please explain. The limit for the copper is about 1.5mb per sec, I think.

[meynaf]

Originally Posted by Thorham

Yes, it would have to be tested. That means that two things have to be tested, as I really want to know how well the system can handle this. Just how clean are those copper wb programs? Those may give an idea of how clean/dirty the patches would become.

Those copper wb programs seem quite clean ; however you simply can't do what they do. Calling a graphics.library function for each copper instruction you add would be way too much overhead.
Ever noticed that every system-friendly copper program gives a static result ?

Originally Posted by Thorham

That code doesn't look too slow. Perfectly doable. You can get rid of the ror.w #8,d0 if you reorganize the table, shouldn't make it any longer.

That code sure isn't slow, and it doesn't need to be very fast anyway, because it copes with relatively low frequencies.

Things become different if we need to downsample. With 44.1 khz (stereo) we have 566 clock cycles (or so) per sample so we'd better be fast.

Originally Posted by Thorham

It wouldn't even be very useful. And there definitively is limit on how fast you can write the chipset regs, anyway, so you won't be able to get 3.5mhz at all.

That's what I say

Originally Posted by Thorham

I suppose you don't mean the audio dma, but I still didn't get that bit, so please explain. The limit for the copper is about 1.5mb per sec, I think.

I really meant the audio dma : you can't use periods less than 123 or you won't hear what you expected.

A limit of 1.5mb per sec, for 4 channels, would be 375khz. Not bad. But the copper has no way to find out if a new data is required or not in AUDxDAT (the cpu simply examines the interrupt request). I really wonder how you plan on solving that issue.

[Thorham]

Originally Posted by meynaf

Those copper wb programs seem quite clean ; however you simply can't do what they do. Calling a graphics.library function for each copper instruction you add would be way too much overhead.
Ever noticed that every system-friendly copper program gives a static result ?

I'm glad I asked. I haven't noticed because I never use these programs. All this probably means that proper system integration is not going to be easy. On the plus side, it should become very obvious if it's even worth it, or not.

Originally Posted by meynaf

That code sure isn't slow, and it doesn't need to be very fast anyway, because it copes with relatively low frequencies.

Things become different if we need to downsample. With 44.1 khz (stereo) we have 566 clock cycles (or so) per sample so we'd better be fast.

Wow, 566 cycles, huh. Per sample that's a little steep. How do you down sample samples anyway? Is it similar to down scaling graphics?

Originally Posted by meynaf

I really meant the audio dma : you can't use periods less than 123 or you won't hear what you expected.

A limit of 1.5mb per sec, for 4 channels, would be 375khz. Not bad. But the copper has no way to find out if a new data is required or not in AUDxDAT (the cpu simply examines the interrupt request). I really wonder how you plan on solving that issue.

I was thinking about using two copperlists for double buffering. It would appear to me that that would just work... Well it should work if the audio hardware keeps playing the last sample put into AUDxDAT.

[meynaf]

Originally Posted by Thorham

I'm glad I asked. I haven't noticed because I never use these programs. All this probably means that proper system integration is not going to be easy. On the plus side, it should become very obvious if it's even worth it, or not.

Why not simply making it work without worrying about the system integration ?

Originally Posted by Thorham

Wow, 566 cycles, huh. Per sample that's a little steep. How do you down sample samples anyway? Is it similar to down scaling graphics?

566 is 50,000,000/(44100*2)
(it's *2 because of stereo)

Downsampling is basically very similar to down scaling graphics, just averaging will do the trick. For more advanced methods they will differ ; just don't attempt dithering for audio or you'll likely add noise.
Of course for audio you only have 1 dimension, not 2 (you have stereo but you treat this as 2 independent waveforms).

Originally Posted by Thorham

I was thinking about using two copperlists for double buffering. It would appear to me that that would just work... Well it should work if the audio hardware keeps playing the last sample put into AUDxDAT.

The hardware keeps playing the last sample put into AUDxDAT even if you don't want it to (e.g. if you're too slow). But I don't see any link with the double-buffering

[Thorham]

Originally Posted by meynaf

Why not simply making it work without worrying about the system integration ?

Because to me, the program would be useless if it doesn't behave well under the os. I guess I just don't want to write it if it's not going to be os friendly.

Originally Posted by meynaf

566 is 50,000,000/(44100*2)
(it's *2 because of stereo)

Downsampling is basically very similar to down scaling graphics, just averaging will do the trick. For more advanced methods they will differ ; just don't attempt dithering for audio or you'll likely add noise.
Of course for audio you only have 1 dimension, not 2 (you have stereo but you treat this as 2 independent waveforms).

So it's really that simple. That's great. But does it really have to use 566 cycles? Can you post the code, please?

Originally Posted by meynaf

The hardware keeps playing the last sample put into AUDxDAT even if you don't want it to (e.g. if you're too slow). But I don't see any link with the double-buffering

Maybe were talking about different things again So here goes:

Originally Posted by meynaf

But the copper has no way to find out if a new data is required or not in AUDxDAT

Why would you need to know this? If it's just to know when to supply the audio chip with more data, then the double copperlist method should do the trick, if I'm not mistaken. If you mean something else, please explain.

[meynaf]

Originally Posted by Thorham

Because to me, the program would be useless if it doesn't behave well under the os. I guess I just don't want to write it if it's not going to be os friendly.

But you don't even know if it can work at all. You don't know the exact work to perform. How then could you know if it's gonna be os friendly or not ???

Originally Posted by Thorham

So it's really that simple. That's great. But does it really have to use 566 cycles? Can you post the code, please?

It doesn't have to use 566 cycles. It really shouldn't either. This value is the maximum number of clock cycles to use per sample if you want to perform in real time.

If you want to see my actual player code (very crude and experimental I'm afraid), you can find it here :
http://meynaf.free.fr/tmp/p.zip

... and sorry for the french comments again

Originally Posted by Thorham

Maybe were talking about different things again So here goes:
Why would you need to know this? If it's just to know when to supply the audio chip with more data, then the double copperlist method should do the trick, if I'm not mistaken. If you mean something else, please explain.

Playing audio isn't just flooding AUDxDAT registers with data. You must wait for the actual word to be output before writing another. The copper doesn't have this information.

[Thorham]

Originally Posted by meynaf

But you don't even know if it can work at all. You don't know the exact work to perform. How then could you know if it's gonna be os friendly or not ???

Yes, that's a problem. I guess I'll just have to go and do it. It's not like it's an impossible task, and I agree the only way to know is to try. It just would've been nice to know some stuff before hand, so I don't run the risk of ending up with a working, but useless program!

Originally Posted by meynaf

It doesn't have to use 566 cycles. It really shouldn't either. This value is the maximum number of clock cycles to use per sample if you want to perform in real time.

If you want to see my actual player code (very crude and experimental I'm afraid), you can find it here :
http://meynaf.free.fr/tmp/p.zip

... and sorry for the french comments again

Aha, if it's the maximum nr of cycles than a real version would indeed be a whole lot faster. And don't worry about the comments!

Originally Posted by meynaf

Playing audio isn't just flooding AUDxDAT registers with data. You must wait for the actual word to be output before writing another. The copper doesn't have this information.

Then I suppose I would have to figure out some sort of timing so that the copper doesn't need the info. A said before, I'll just have to try and write it, just to see what happens, and try to address issues as the come up. There is just no other way

By the way (to get back on topic ), have you made any progress with that damned layer 3 decoding?

[meynaf]

Originally Posted by Thorham

Yes, that's a problem. I guess I'll just have to go and do it. It's not like it's an impossible task, and I agree the only way to know is to try. It just would've been nice to know some stuff before hand, so I don't run the risk of ending up with a working, but useless program!

That's what happened to me when I did my cpu-only DeliTracker noteplayer. It worked and wasn't limited to 28 khz. But its inability to keep channels in sync, and the fact that it sometimes missed a write, made some nasty effects. Anyway I don't regret having done it, you always learn something and it may end up being the program's sole purpose.

Originally Posted by Thorham

Aha, if it's the maximum nr of cycles than a real version would indeed be a whole lot faster. And don't worry about the comments!

A real version is much faster, but the more it consumes, the less remains for the decoding part. Just using 100 clock cycles here is nearly 20% cpu use !

So I won't worry about the comments. Just don't hesitate to ask me instead of trusting online translators

Originally Posted by Thorham

Then I suppose I would have to figure out some sort of timing so that the copper doesn't need the info. A said before, I'll just have to try and write it, just to see what happens, and try to address issues as the come up. There is just no other way

You'll probably end up counting the video clock cycles. Hopefully the copper isn't annoyed by cpu/blitter activity, so it should be possible to get exact timings from it.

Originally Posted by Thorham

By the way (to get back on topic ), have you made any progress with that damned layer 3 decoding?

That damned layer 3 decoding didn't evolve, as I have problems with my damned buffer handling code and I want to solve this before.

When dealing with high cpu use like in mp3, you simply can't do an ordinary double-buffering. The decoder will send you frames of 1152 (sometimes 576) samples, this is way too small and the slightest activity in the background will make you miss the deadline and have a "hole" in your replay (my actual "p" program emits a warning after it ended the playing, if such thing occured).

Furthermore, I wanted to downsample 44.1 to 26.46 khz instead of 22.05 to get better quality. It's not hard to do, however the data I receive from the codec won't be a size it can handle (should be a multiple of 10 samples).

And to add another layer of trouble, if you collect many frames before sending them to audio output, there'll be a long delay between the typed command and the time you hear something. Not to mention your chimem buffer not being a multiple of the frame length.

Oh, and, yes, did I tell about the file reading problem ? An mp3 is better when read entirely in memory as there will be no i/o while decoding (speed is critical), but that's not the case with a huge wave file... but it could be with a small one

If you have ideas, you're welcome...


PS: more banghead here -
(that thing's driving me nuts, please forgive me )

[Thorham]

Originally Posted by meynaf

That's what happened to me when I did my cpu-only DeliTracker noteplayer. It worked and wasn't limited to 28 khz. But its inability to keep channels in sync, and the fact that it sometimes missed a write, made some nasty effects. Anyway I don't regret having done it, you always learn something and it may end up being the program's sole purpose.

Wow, I would not have been happy about that, I can tell you that much. Oh well, ya can't have it all... I'm just going to try it anyway. If the system screws things up, it might be useful for a demo/intro or something. Or just playing a cd while working on another computer. Who knows.

Originally Posted by meynaf

A real version is much faster, but the more it consumes, the less remains for the decoding part. Just using 100 clock cycles here is nearly 20% cpu use !

So I won't worry about the comments. Just don't hesitate to ask me instead of trusting online translators

20% is a lot. Should be possible to make it faster than that. I think I'll give it a go.

Originally Posted by meynaf

You'll probably end up counting the video clock cycles. Hopefully the copper isn't annoyed by cpu/blitter activity, so it should be possible to get exact timings from it.

Should be easy to find out. I've got an old game I was doing in asm about 10 years ago for non-aga. This code should make it easy to test those things. Now, why didn't I think of that before

Originally Posted by meynaf

That damned layer 3 decoding didn't evolve, as I have problems with my damned buffer handling code and I want to solve this before.

When dealing with high cpu use like in mp3, you simply can't do an ordinary double-buffering. The decoder will send you frames of 1152 (sometimes 576) samples, this is way too small and the slightest activity in the background will make you miss the deadline and have a "hole" in your replay (my actual "p" program emits a warning after it ended the playing, if such thing occured).

Furthermore, I wanted to downsample 44.1 to 26.46 khz instead of 22.05 to get better quality. It's not hard to do, however the data I receive from the codec won't be a size it can handle (should be a multiple of 10 samples).

And to add another layer of trouble, if you collect many frames before sending them to audio output, there'll be a long delay between the typed command and the time you hear something. Not to mention your chimem buffer not being a multiple of the frame length.

Oh, and, yes, did I tell about the file reading problem ? An mp3 is better when read entirely in memory as there will be no i/o while decoding (speed is critical), but that's not the case with a huge wave file... but it could be with a small one

If you have ideas, you're welcome...


PS: more banghead here -
(that thing's driving me nuts, please forgive me )

I might be able to come up with some small things, I suppose I could test them if I do the audio test program I'm planning. Yes, these things need to be addressed in order to make a proper player. And don't worry, this would drive almost everyone insane!

[meynaf]

Originally Posted by Thorham

Wow, I would not have been happy about that, I can tell you that much. Oh well, ya can't have it all... I'm just going to try it anyway. If the system screws things up, it might be useful for a demo/intro or something. Or just playing a cd while working on another computer. Who knows.

Who knows, yes... Good luck on doing it.

Originally Posted by Thorham

20% is a lot. Should be possible to make it faster than that. I think I'll give it a go.

The code for that is in sndconv.s. A whole lot of conversion routines lie here, some work well while others don't.

Originally Posted by Thorham

Should be easy to find out. I've got an old game I was doing in asm about 10 years ago for non-aga. This code should make it easy to test those things. Now, why didn't I think of that before

I'm really curious to see if the copper can really be used for audio. Wow ! This probably hasn't been done before !

Originally Posted by Thorham

I might be able to come up with some small things, I suppose I could test them if I do the audio test program I'm planning. Yes, these things need to be addressed in order to make a proper player. And don't worry, this would drive almost everyone insane!

Yes, sure. The best thing to do is handling multiple buffers so that you can take as many advance as memory allows, but still be reactive when playing starts. I think this is what the mpega player for DT does.

For read buffers there should be a limit ; if the file fits within the limits it is completely read, else a reasonable buffer size is chosen. But what sizes to chose ???

Actually my player has two options to set up buffers :
. maxmem n : n is a number of kilobytes, the max length of the read buffers (will use less memory if the file is smaller than that)
. chipbuf n : n is 0 to 5 but I don't remember the exact buffer sizes it gives, it's for chipmem buffers

You can test it and tell me what you think of it. If you want files to be played with it I can give you some.

[Thorham]

Originally Posted by meynaf

Who knows, yes... Good luck on doing it.

Why, thank you, sir

Originally Posted by meynaf

The code for that is in sndconv.s. A whole lot of conversion routines lie here, some work well while others don't.

Right, that clears it up. I didn't know where to look! Maybe I should those 'Learning French' links on your site!

Originally Posted by meynaf

I'm really curious to see if the copper can really be used for audio. Wow ! This probably hasn't been done before !

Really? I don't see why it shouldn't work, though. On the other hand, the there might be a very good reason why it hasn't been done before...

Originally Posted by meynaf

Yes, sure. The best thing to do is handling multiple buffers so that you can take as many advance as memory allows, but still be reactive when playing starts. I think this is what the mpega player for DT does.

For read buffers there should be a limit ; if the file fits within the limits it is completely read, else a reasonable buffer size is chosen. But what sizes to chose ???

Actually my player has two options to set up buffers :
. maxmem n : n is a number of kilobytes, the max length of the read buffers (will use less memory if the file is smaller than that)
. chipbuf n : n is 0 to 5 but I don't remember the exact buffer sizes it gives, it's for chipmem buffers

You can test it and tell me what you think of it. If you want files to be played with it I can give you some.

Ok, I'll test it. But if they're just wavs, I can easily make them from mp3s! As for aiff, I can make those, too, no problem

[meynaf]

Originally Posted by Thorham

Right, that clears it up. I didn't know where to look! Maybe I should those 'Learning French' links on your site!

Maybe...

If you don't know where to look, the source name usually suggests what it does... are they unclear to you ?

Originally Posted by Thorham

Really? I don't see why it shouldn't work, though. On the other hand, the there might be a very good reason why it hasn't been done before...

If there's a very good reason, at least you'll know it.

Originally Posted by Thorham

Ok, I'll test it. But if they're just wavs, I can easily make them from mp3s! As for aiff, I can make those, too, no problem

My aiff support is very basic, so I won't be surprised if you run into a problem...

[Thorham]

Originally Posted by meynaf

Maybe...

If you don't know where to look, the source name usually suggests what it does... are they unclear to you ?

No, it's not that, I was just a bit lazy, that's all

Originally Posted by meynaf

If there's a very good reason, at least you'll know it.

True. You can't do these things without learning something!

Originally Posted by meynaf

My aiff support is very basic, so I won't be surprised if you run into a problem...

No problem. I'll just stick to formats which do work properly.

[meynaf]

Originally Posted by Thorham

No, it's not that, I was just a bit lazy, that's all

No problem then
Don't hesitate to ask if a particular file looks mysterious to you.

Originally Posted by Thorham

True. You can't do these things without learning something!

I'm eager to see - errh, sorry, to hear - your first results !

Originally Posted by Thorham

No problem. I'll just stick to formats which do work properly.

I did the aiff implementation before reading the spec, that's why

[Thorham]

Originally Posted by meynaf

No problem then
Don't hesitate to ask if a particular file looks mysterious to you.

Ok, I will do that.

Originally Posted by meynaf

I'm eager to see - errh, sorry, to hear - your first results !

So am I! I think I'm going to try it out this weekend. With the code I still have from that old game, it will actually be a cake walk to try!

Originally Posted by meynaf

I did the aiff implementation before reading the spec, that's why

Any chance that's going to get fixed? For now wav is fine for me, though.

[meynaf]

Originally Posted by Thorham

So am I! I think I'm going to try it out this weekend. With the code I still have from that old game, it will actually be a cake walk to try!

Now the week-end has elapsed... Suspense...

Originally Posted by Thorham

Any chance that's going to get fixed? For now wav is fine for me, though.

The aiff *might* work. It does with the one and only file I have.
Anyway it shouldn't crash

I will fix this someday. Just need to get a correct frequency from this 10-byte float value (they use an extended 80-bits float to store replay frequency, it looked incredible to me !).

[Thorham]

Originally Posted by meynaf

Now the week-end has elapsed... Suspense...

Hoo boy, this copper business is extremely fiddly As you can guess, I haven't been successful, yet. There's an extremely irritating timing issue, and it's this: Getting the copper to run absolutely continuously, without a single break. And to think that I thought this was going to be a cake walk... Well, this is just a little harder than expected, and is still going to require more work. At least I always have access to my miggy, so I can still work on it at night. I'll keep you posted.

Originally Posted by meynaf

The aiff *might* work. It does with the one and only file I have.
Anyway it shouldn't crash

I will fix this someday. Just need to get a correct frequency from this 10-byte float value (they use an extended 80-bits float to store replay frequency, it looked incredible to me !).

They use scientific precision floats for that? Really? Hahaha, that's one of the silliest things you can do in such a format. Why on earth didn't they just use a 32bit integer for that?