LibS3MPlay v.1.0

[PH3NOM]

LibS3MPlay is an S3M audio decoder, running completely on the ARM cpu of the Dreamcast.
This means 0 SH4 cpu cycles are used in the decoding process.

The decoder was coded by Dan Potter, I have simply implemented a front-end interface for the library.

For anyone interested the source is uploaded here:

libs3mplay.tar.gz

LibS3MPlay - A DC S3M Player on the AICA

(23.44 KiB) Downloaded 72 times

[Chilly Willy]

Nifty! We're one step closer to better AICA utilization.

[Ayla]

Could you put the sources on sourceforge / github please? I really don't trust megaupload.

[Christuserloeser]

Running entirely on the ARM ? - How is this possible? I thought the ARM can't do anything.... Is there an OGG or MP3 player for the ARM ? Could it be used for anything else ? - i.e. GBA emulation (similar if not identical? ARM CPU), Z80 emulation or something like that.

[Chilly Willy]

Running entirely on the ARM ? - How is this possible? I thought the ARM can't do anything.... Is there an OGG or MP3 player for the ARM ? Could it be used for anything else ? - i.e. GBA emulation (similar if not identical? ARM CPU), Z80 emulation or something like that.

This is a tracker format (S3M) very much like mod/it/xm. The ARM is only processing the note events, not doing any decoding or mixing. That's all done by the AICA sound chip.

[BlueCrab]

Running entirely on the ARM ? - How is this possible? I thought the ARM can't do anything.... Is there an OGG or MP3 player for the ARM ? Could it be used for anything else ? - i.e. GBA emulation (similar if not identical? ARM CPU), Z80 emulation or something like that.

Don't count on anything complicated running on the ARM at a decent speed. The way that part of the system is designed is rather... poorly, to say the least.

Some people have had some non-trivial stuff running on the ARM, like an S3M decoder (as in the 2ndmix example of KOS, and this stuff). I believe Quzar had a small emulator running on the ARM as well.

[RyoDC]

The way that part of the system is designed is rather... poorly, to say the least.

Crab, why is it so? It's because engineers of sega placed less memory then it must have, or its connection map developed to poor, that some possibilities left unused?

[BlueCrab]

The first major problem is that the ARM has no cache. The second issue comes from that problem: namely, while anything else is accessing the ARM's memory space, the ARM basically has to sit there and deadwait.

[RyoDC]

Omg, processor with no cashe. It's something terrific.

[nymus]

I think expectations for the dreamcast audio subsystem are sometimes too high just because it is programmable. There are many systems e.g. the Gameboy Advance which are built on cache-less CPUs.

Remember that the sound subsystem (AICA) by itself is intended to be like a dedicated sound card (not a co-processor) so calling it poorly designed might be a little unfair especially when you consider that such programmability doesn't exist even in current systems which still use fixed-function hardware/DSPs with the main CPU handling most decoding/streaming/management.

Is there a system out today that can upload a program and audio data to its sound core and then let the sound hardware do everything by itself!? Apparently, even Creative's X-Fi doesn't operate independently. Dreamcast is relatively more advanced in this respect.

There are mp3 players released for the gameboy advance so it is not inconceivable to have a full blown codec working independently on the AICA.

There are certain qualities of dreamcast's hardware that do require software design that is different from conventional systems but when its strengths are exploited, there can be amazing results.

[Ayla]

There are mp3 players released for the gameboy advance so it is not inconceivable to have a full blown codec working independently on the AICA.

There are certain qualities of dreamcast's hardware that do require software design that is different from conventional systems but when its strengths are exploited, there can be amazing results.

The comparison with the GBA is not fair, as it doesn't have the same CPU. The GBA has an ARM7TDMI while the AICA has an ARM7DI, and this makes all the difference. The DI is much slower at doing certain operations (like 32b => 64b multiplication), that's the first reason why MP3 decoding is not possible here.
The second reason is that everybody who used it report the ARM co-processor to be slow as hell. I remember Heliophobe theorized it at 3MIPS, I measured it at 2.7MIPS. Maybe it'd be possible to make it faster by disactivating the DSP but I would'nt bet on that.
Finally, it may be possible to offload some parts of the decoding process to the DSP (e.g. Huffman decoding, dequantization). But that one really is a weird piece of hardware, that still has to be used on a homebrew; and I'm not sure that it's even possible.

[Ayla]

Could you put the sources on sourceforge / github please? I really don't trust megaupload.

Told you

[PH3NOM]

Could you put the sources on sourceforge / github please? I really don't trust megaupload.

Told you

Yeah good call

First post updated with an attachment to the source code....