OGG stream using ARM-based sound co-processor

Freeze · Post by **Freeze** » Tue Mar 08, 2005 2:19 pm

Hey guys,

buddy of mine is working on something Dreamcast related but the project came to an early stop. He's looking for a piece of code to play OGG vorbis stream using a ARM-based sound co-processor. Whichout it, the normal OGG playback support uses way too much resources.

Any ideas?

technoman · Post by **technoman** » Tue Mar 08, 2005 4:33 pm

sorry but it's in french.... :

http://forum.aceboard.net/4752-519-9118-0-Arm7.htm

BlackAura · Post by **BlackAura** » Tue Mar 08, 2005 6:45 pm

I think you're going to have trouble with that. The ARM is slow. Really slow. In theory, it's clocked at around 45MHz. It has no cache, and shares it's memory with the sound hardware itself. Thus, there are some serious bus contention issues, and the sound hardware frequently gets exclusive access to SRAM. SRAM is also very slow. In effect, the ARM runs at nothing like 45MHz. It's very, very slow. I don't think you're going to be able to decode a Vorbis stream on it.

If you want to get the music playback completely out of the way, you could use CDDA instead, assuming you have enough room on the CD. If you want to distribute it over the 'net, you can pack up the soundtrack as Ogg Vorbis files (or whatever other format).

Other than that, all I can really do is suggest some ways to bring the CPU usage of the decoder down. For Vorbis, you can decrease the bitrate down to around 80Kbps. It still sounds OK (unless you have your DC connected to a proper speaker system you won't notice the difference), but doesn't use quite as much CPU time for decoding. You could try a codec that uses fewer resources to decode. MP3 is the obvious one, but that might not be appropriate (patent issues, the fact that the only decoder available with KOS is GPLed). AAC might be a better bet, if you can port FAAD over, and it sound a lot better than MP3, but you still might have patent issues if you ever wanted to sell it. The only other alternative that comes to mind is MP2, which isn't that great, but doesn't require much CPU time to decode at all.

az_bont · Post by **az_bont** » Tue Mar 08, 2005 7:11 pm

BlackAura wrote:The only other alternative that comes to mind is MP2, which isn't that great, but doesn't require much CPU time to decode at all.

Musepack (MPC/MP+) is now being used in a couple of homebrew games for the PC. It has been designed to achieve transparency at the lowest possible bitrate, beating other codecs like WMA, Vorbis, AAC and MP3 at bitrates of 128kbps and above. However, as a consequence of this, it does not perform as well with low-bitrate encodes.

Although it is based on MP2, it has been heavily optimized and stripped of any patented code, whilst still requiring very little CPU time to decode.

midiclub · Post by **midiclub** » Wed Mar 09, 2005 12:44 pm

oh kewl, i didn't even know i'm registered for this forum.. but i apparently i am.

so, the buddy freeze speaks of should be me.

ARM7 built into the sound DSP runs at about 20 MHz if i remember correctly. i have seen a player to use the ARM on dreamcast - i just lost it soewhere. it claimed to be usually able to play 96kbit oggvorbis stream, which is quite enough - though one could experiment with encding settings to hit optimal quality where performance still suffices.

i know it was just libtremor compiled and stuff, however i just want a readymade player (not necessarily a perfect one) and not bother, i have to little time and too much to do.

Freeze · Post by **Freeze** » Wed Mar 09, 2005 2:29 pm

Thanks for all your replies guys!

But I doubt CDDA would be helpful because if it would make it's way on a compilation CD this wouldn't work out too good.

Shapyi · Post by **Shapyi** » Fri Mar 11, 2005 9:20 am

Thought SRAM was Static RAM and it was a lot faster than the other types of RAM. I thought cache was just SRAM on the CPU chip.

Post by **BlueCrab** » Fri Mar 11, 2005 6:11 pm

SRAM, in this case, means Sound RAM. Putting a letter in front of RAM is usually quite ambiguous, and this is one of those situations.

bramenjam · Post by **bramenjam** » Sun Mar 13, 2005 1:01 am

You could always use ADPCM compression. It's not patented, uses almost no power to decompress, but it doesn't compress as good as mp3 or ogg, so the files are still rather big. (ADPCM compression was also use in Beats of Rage.)

Rand Linden · Post by **Rand Linden** » Sun Mar 13, 2005 2:07 am

AFAIK, some types of ADPCM are infact patented -- either the algorithm, the filter coefficients, or both.

ADPCM was likely used in BOR because the DC can decode it in hardware without additional overhead.

Also, ADPCM isn't usually anywhere close to the space savings of OGG or MP3.

The DC's ARM is quite (read: incredibly) slow -- even doing fairly simple tasks can be a huge PITA.

Complex tasks are likely to be a tremendous time sink, as well as (generally) very difficult to achieve an acceptable solution.

Rand.