New A-EON Music Card for Classic Amigas

[nicholas]

shouldnt it be actually solved via datatypes. in this case accelerated. if it was sdl should use them rather than statically linking to libs to make it more configuration independent.

Datatypes for all supported audio compression formats + an AHI driver would make it the complete package.  Anything less would seem a bit half-arsed.

[spirantho]

AHI is something we're looking at, definitely.
Datatypes aren't possible though, I'm fairly sure. An audio datatype has to convert its audio to an 8svx block of data, which the sound datatype then processes and plays back itself. The Prisma card plays the sound itself, it never converts the data, so there's no data to pass to the audio datatype superclass. I thought of faking the audio by playing the stream and  just giving it zeroes to play, but the datatype doesn't have control of its playback once it's returned its data so it'd be a bit useless.

[itix]

AHI is something we're looking at, definitely.
Datatypes aren't possible though, I'm fairly sure. An audio datatype has to convert its audio to an 8svx block of data, which the sound datatype then processes and plays back itself. The Prisma card plays the sound itself, it never converts the data, so there's no data to pass to the audio datatype superclass. I thought of faking the audio by playing the stream and  just giving it zeroes to play, but the datatype doesn't have control of its playback once it's returned its data so it'd be a bit useless.

You would have to hack it into sound.datatype. But then, almost nothing is really using datatypes for direct audio playback. Even just loading audio files via datatypes is extremely rare.

[spirantho]

That's what I thought. It'd be a lot of work (especially to make sure there were no unwanted repercussions from hacking a major datatype) and I don't think it'd be worth it.
The only real advantage to using a datatype would be to allow programs like Multiview to run it. Datatypes are useful in some apps for importing data, but that's not an option here because there's no data to import (it just gets played directly). APIs like SDL shouldn't be using datatypes anyway unless it's for importing data - it's a rather inefficient way to actually play data, and it offers no control to the calling application.

If I manage to get the AHI sound driver working (it's not retargetable audio, remember - it's actually a stream player) then of course you could use the mp3 datatype to decode/import and then play it through AHI, but I think it'd be rather easier to just use the chip to play the mp3.

[Oli_hd]

Im interested in a new soundcard, specially as its got hardware MP3 playback but AHI is a must for me else its not really a sound card and more of a MAS player for a Zorro slot and I already have one of those
Cool project though and if AHI support is included Ill be ordering one.

[wawrzon]

so the almost only advantage of this card is that you will be to play your audio collection stored in some compressed format using a dedicated player? at least something like mpga.library should be thought of. or are we facing c64 future wehre everything hast to be statically linked?

[Karlos]

You would have to hack it into sound.datatype. But then, almost nothing is really using datatypes for direct audio playback. Even just loading audio files via datatypes is extremely rare.

The biggest problem with datatypes for this is the fact that they don't really support progressive decoding of stream data. Not sure how the animation.datatype does it, but the rest all seem to rely on decoding the entire stream into whatever format the superclass expects. This simply isn't practical on classic systems when a 5 minute mp3 file would decode into tens of megabytes of audio data.

+1 to the reggae framework.

[itix]

so the almost only advantage of this card is that you will be to play your audio collection stored in some compressed format using a dedicated player? at least something like mpga.library should be thought of. or are we facing c64 future wehre everything hast to be statically linked?

The mpega.library is no use here. It is just a decoder that converts mp3 to a raw bitstream. Audio playback is still done in the player application through AHI or direct Paula.

Only sensible solution is writing a new dedicated player. It is not that much work. Real challenge is writing decoders for the DSP on that sound card. But writing some decent GUI and simple playlist system is piece of cake.

[spirantho]

so the almost only advantage of this card is that you will be to play your audio collection stored in some compressed format using a dedicated player? at least something like mpga.library should be thought of. or are we facing c64 future wehre everything hast to be statically linked?

*shudder*
I hate static linking. What do you think I am, a Linux coder?

Here's what you currently need to do to play an OGG Vorbis file:

PrismaBase = OpenLibrary( "prisma.library", 0L);
Prisma_Init();
Prisma_PlayFile( "GreatMusic.ogg" );
CloseLibrary( PrismaBase);

There are a few extra parameters to PlayFile if you want to use them (volume, balance, buffersize, task priority), but that's pretty much it.
There's also PlayMemory() which I'm going to implement soon, and it's this that'll hook into AHI and any apps such as SCUMM.

[nicholas]

That looks simple enough, consider my request for datatypes withdrawn.

I wonder if Krashan would consider porting Reggae to 68k given a big enough bounty? That's assuming that it isn't reliant on MorphOS specific features.

[spirantho]

That looks simple enough, consider my request for datatypes withdrawn.

That's the idea - keep it simple. The beauty of the Amiga is the way we can use libraries and devices to interface things, so I like to provide as high a level API as possible. No point in having an easy-to-use library system when the library itself makes it a nightmare to use.

[wawrzon]

Only sensible solution is writing a new dedicated player. It is not that much work. Real challenge is writing decoders for the DSP on that sound card. But writing some decent GUI and simple playlist system is piece of cake.

then i dont see an advantage in this kind of device. it is like warpup, only making difference on very few dedicated tasks and everything tat wants to use it must be specifically recompiled against it. why not just buy a standalone $5 mp3 player instead? you can even place it somewhere weithin your amiga if you really must.. otherwise it gets seriously integrated into the system or let it be.

[wawrzon]

+1 to the reggae framework.

I guess ist what it boils down to.

[spirantho]

then i dont see an advantage in this kind of device. it is like warpup, only making difference on very few dedicated tasks and everything tat wants to use it must be specifically recompiled against it. why not just buy a standalone $5 mp3 player instead? you can even place it somewhere weithin your amiga if you really must.. otherwise it gets seriously integrated into the system or let it be.

It depends on how much you listen to compressed audio. But remember that not all compressed audio is music which you put on like a jukebox.
The obvious reason is for listening to music. In that case you can use a standalone $5 MP3 player if you want, but you'll need to connect it to an amp. And it won't have access to your Amiga's hard disk. Or the internet.
There are other reasons, though - many later SDL games/apps use compressed audio for background music. You can't play game background music using a $5 MP3 player. For instance SCUMMVM - it uses CD audio compressed as MP3 or OGG. With this, a major load can be removed off the CPU and it sounds better too, if you were using Paula before.

Of course any app to use it will be specifically recompiled with support for it, but that's always the way when you do anything like this. The fact that nothing supports hardware which hasn't been made yet is no reason not to make the hardware.

[wawrzon]

*shudder*
I hate static linking. What do you think I am, a Linux coder?

Here's what you currently need to do to play an OGG Vorbis file:

PrismaBase = OpenLibrary( "prisma.library", 0L);
Prisma_Init();
Prisma_PlayFile( "GreatMusic.ogg" );
CloseLibrary( PrismaBase);

still this has to be called explicotely, no existing app will take advantage of it.

There are a few extra parameters to PlayFile if you want to use them (volume, balance, buffersize, task priority), but that's pretty much it.
There's also PlayMemory() which I'm going to implement soon, and it's this that'll hook into AHI and any apps such as SCUMM.

Sounds like hacking. If if theres is none then create reasonable abstraction instand to bind your implementation to the particular hardware, that will create another gap among amiga users and another app versions hell fort tue users to fight with..

[wawrzon]

many later SDL games/apps use compressed audio for background music.

Exactly. If such a port has ro be explicitely linked to your library to make use of the hardware then it will likely not work otherwise eben without sound. Independent ports will be needed ans ade to tue whole mess.