mpega.library faster than itself

[Thorham]

Originally Posted by meynaf

You can fit some system parts just before the wait if you're sure this will be fast enough. That is, one or two moves before each wait or so.

You'd think that more than a megabyte per sec is enough. Still, proper copper irqs for a c64 style raster irq to handle the system copper list stuff, is good enough for me, as long as it's compatible and not too dirty to implement.

Originally Posted by meynaf

I guess we don't have the choice anyway...

Hmm, I wonder why the author can't be contacted. I sure hope it's not because they passed away, or something similarly bad

Originally Posted by meynaf

See the new thread then
If you're interested and have access to something that's not 020/030 then you could perform some tests of mine to get more. I'm especially looking for 010/040/060 to check.

Sorry, but I only have a '030... I do still have an a500, but it's as dead as they come. On the plus side, all the important chips in it still work, if I'm not mistaken. Might be usefull for parts...

[meynaf]

Originally Posted by Thorham

You'd think that more than a megabyte per sec is enough. Still, proper copper irqs for a c64 style raster irq to handle the system copper list stuff, is good enough for me, as long as it's compatible and not too dirty to implement.

But for the audio part itself, how's it going ? Did you reach an acceptable quality yet ?

Originally Posted by Thorham

Hmm, I wonder why the author can't be contacted. I sure hope it's not because they passed away, or something similarly bad

Or something even worse : lost interest and gone to PC.

Originally Posted by Thorham

Sorry, but I only have a '030... I do still have an a500, but it's as dead as they come. On the plus side, all the important chips in it still work, if I'm not mistaken. Might be usefull for parts...

Yes, 030 (and 020) tests are already done. I did my first 68000 tests long ago on an Atari St and was nearly deceived not to find a single undocumented opcode

[Thorham]

Originally Posted by meynaf

But for the audio part itself, how's it going ? Did you reach an acceptable quality yet ?

I actually haven't reached any quality yet, as I can't get the copper, nor the cpu to generate sound without the audio dma at all. I have no clue what so ever as to what I'm doing wrong. I just know I am screwing something up big time All I know is that with the audio dma is playing null samples I can get some sound from both the copper and the cpu, but with the dma turned of, which it has to, theres nothing at all On the plus side, now that I'm using waits, there doesn't seem to be any timing problems any more

Originally Posted by meynaf

Or something even worse : lost interest and gone to PC.

Peecees are kinda cool, but only because they're fast, and you can play Diablo 2 Lod on them They're not cool enough to give up on the good old Amiga, though. It's impossible to understand those people

Originally Posted by meynaf

Yes, 030 (and 020) tests are already done. I did my first 68000 tests long ago on an Atari St and was nearly deceived not to find a single undocumented opcode

Yep, the 68k family doesn't have undocumented opcodes as far as I know. The only cpu I've heard of which has those, is the 6502/6510 in the Commodore 64 (ace machine, btw, wrote my first basic program on that as a little kid).

[meynaf]

Strange you don't get any sound at all.

What you have to do is to set up a volume (DFF0A8), set up a playing frequency (DFF0A6) and then repetitively bang on the data register (DFF0AA).

Didn't you forget something you thought wasn't important ?

[Thorham]

Originally Posted by meynaf

Strange you don't get any sound at all.

What you have to do is to set up a volume (DFF0A8), set up a playing frequency (DFF0A6) and then repetitively bang on the data register (DFF0AA).

Didn't you forget something you thought wasn't important ?

I think I'm doing it right Then again, I'm using that old game source code, the one used for my test bmp viewer, for doing hit the hardware stuff, and it doesn't behave properly. The screen staying black is one of them. I think that code needs a rewrite from scratch. It's probably the main killing routines that screw up somehow.

I have noticed something strange: If after a copper write to aud0dat I do a copper write to color00, there is some soft sound, the frequency can be changed, but it should be a lot louder. I have no idea where this comes from Furthermore, when playing an empty sample using dma, the copper writes to aud0dat can be heard clearly. I'm probably doing something minuscule wrong here.

Anyway, as said, there are no more timing issues because of the waits, and it seems perfectly possible to get the copper to playback at almost exactly 44.100 khz. So except for the buggy old game source, I have good hopes that this is indeed going to work. I've already posted another thread about sound coding, and got Toni to help me Guess this will be working in no time. Furthermore, there seems to be plenty of copper time left to handle the system stuff, so this really could be a winner.

[meynaf]

Originally Posted by Thorham

I think I'm doing it right Then again, I'm using that old game source code, the one used for my test bmp viewer, for doing hit the hardware stuff, and it doesn't behave properly. The screen staying black is one of them. I think that code needs a rewrite from scratch. It's probably the main killing routines that screw up somehow.

Then you can start from the bmp viewer. At least you won't end up with a black screen

Originally Posted by Thorham

I have noticed something strange: If after a copper write to aud0dat I do a copper write to color00, there is some soft sound, the frequency can be changed, but it should be a lot louder. I have no idea where this comes from Furthermore, when playing an empty sample using dma, the copper writes to aud0dat can be heard clearly. I'm probably doing something minuscule wrong here.

You won't hear a lot of sound by playing a single sample anyway (maybe a click). Even one full frame won't give you much.
Also, you should be aware that when writing to AUDxDAT, you'll actually end up playing two samples (high byte first). Just my 2 cents attempt to find out what's wrong

Originally Posted by Thorham

Anyway, as said, there are no more timing issues because of the waits, and it seems perfectly possible to get the copper to playback at almost exactly 44.100 khz. So except for the buggy old game source, I have good hopes that this is indeed going to work. I've already posted another thread about sound coding, and got Toni to help me Guess this will be working in no time. Furthermore, there seems to be plenty of copper time left to handle the system stuff, so this really could be a winner.

Aha ! We're advancing then ! Keep up the good work

[Thorham]

Originally Posted by meynaf

Then you can start from the bmp viewer. At least you won't end up with a black screen

Erm, that bmp viewer actually uses the same hardware coding frame It just doesn't always show a black screen.

Originally Posted by meynaf

You won't hear a lot of sound by playing a single sample anyway (maybe a click). Even one full frame won't give you much.
Also, you should be aware that when writing to AUDxDAT, you'll actually end up playing two samples (high byte first). Just my 2 cents attempt to find out what's wrong

Oh, but I didn't mean hardware sample. Anyway, even with just a handful of hardware samples, you can actually create a proper tone (have done it with audio dma). And as for the two samples being played, the idea is to have the paula only play one sample by changing the sample before the next one gets played. Must admit that I may be getting it wrong at that point.

Originally Posted by meynaf

Aha ! We're advancing then ! Keep up the good work

Thank you I'm still busy writing a new hardware coding frame, because the old one is just too buggy, and quite frankly, I'm amazed it even worked half of the time.

[meynaf]

Originally Posted by Thorham

Erm, that bmp viewer actually uses the same hardware coding frame It just doesn't always show a black screen.

Well, then taking the system over is no big deal. Just save the actual configuration away, then stop the interrupts and setup your new coplist.

Originally Posted by Thorham

Oh, but I didn't mean hardware sample. Anyway, even with just a handful of hardware samples, you can actually create a proper tone (have done it with audio dma). And as for the two samples being played, the idea is to have the paula only play one sample by changing the sample before the next one gets played. Must admit that I may be getting it wrong at that point.

Of course you can make a tone with two samples. But if you write these two samples once, they will be played only once and you won't hear a thing.

With the dma, you'd just loop on those two samples and hear the square signal.

Originally Posted by Thorham

Thank you I'm still busy writing a new hardware coding frame, because the old one is just too buggy, and quite frankly, I'm amazed it even worked half of the time.

If you're stuck in this and need help, don't hesitate to ask. I have no hardware coding frame ready at hand, but one wouldn't be very long to make.

[SKOLMAN_MWS]

VorbisPlayer Tremora OGG decode faster than mp3

http://www.ppa.pl/forum/komentarze/1...player#m245579

http://aminet.net/package/mus/play/VorbisPlayer

[Hewitson]

What happened to this project? It sounds like it was pretty close to completion.

[meynaf]

Originally Posted by SKOLMAN_MWS

VorbisPlayer Tremora OGG decode faster than mp3

http://www.ppa.pl/forum/komentarze/1...player#m245579

http://aminet.net/package/mus/play/VorbisPlayer

But mp3 can play on 68030, where this vorbis player needs 68060. I don't call that "faster than mp3".

Originally Posted by Hewitson

What happened to this project? It sounds like it was pretty close to completion.

It is complete.

[SKOLMAN_MWS]

Originally Posted by meynaf

But mp3 can play on 68030, where this vorbis player needs 68060.

Yes, because VorbisPlayer play only in the full frequency and AHI. I asked if could be done to decode ogg half frequency for 68040 and mono for 68030 and native Paula 14bit without AHI?

[kamelito]

Originally Posted by meynaf

Hello coders,


As you know, there is no support for mpega.library and the author can't be contacted (it seems).

I asked myself if the integer version of the library, which is actually the fastest Amiga implementation of such a decoder (or I think so ), could be optimized, and found out it could.
I re-sourced it and got around 10% speed, enough to play in medium quality setting what I previously played in low.
Now most of the (up to) 160 kbps mp3's can be played at 22.05 medium quality and mono on a 50mhz 68030.

To use it, DeliTracker's mpega player will do nicely.

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).

You will find the actual source (reassembler output, so mostly unreadable) here :
http://meynaf.free.fr/tmp/mpega.lzx
(not in the zone because files don't live long enough there)

Included is the library doc. Unfortunately I don't have the lvo's.

More can surely be done. If someone already did something similar or is interested, you now know where to help...

** Converted from "mpega.fd" by FDI v2.2
** FDI © Oct 29 1997 Karl J. Ots

** $VER: mpega.library 2.0 (21.06.98) (C) 1997-1998 Stéphane TAVENARD

_LVOMPEGA_open EQU -30
_LVOMPEGA_close EQU -36
_LVOMPEGA_decode_frame EQU -42
_LVOMPEGA_seek EQU -48
_LVOMPEGA_time EQU -54
_LVOMPEGA_find_sync EQU -60
_LVOMPEGA_scale EQU -66

[arti040]

Anyone has that library backed up maybe?

EDIT: Nevermind. I found it :-)

[kamelito]

@Meynaf I recall you were looking for this http://aminet.net/package/util/libs/MPEGALibrary_src

[meynaf]

It's been quite a long time i've found this, thanks.