gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Interleaving two CPU-intensive task

#131210 - Noda - Tue Jun 12, 2007 12:43 pm

Hello,

I'm currently working on simulatneous decoding of 2 mp3, streamed from fat, on the arm9.

The tests I made on the decoded showed that it is logically possible to do so (229% realtime for a 44k 320kbps stereo mp3, around 400% at 128kbps bitrate, for an mp3 played from ram)

The engine is already built, with a nice streaming system (based on an example posted on this forum) and working nicely when only 1 mp3 is played at a time.

But I have problem for interleaving the 2 mp3 decoding, I don't know what could be the best way to do it (as there's no threads on the DS)...

One issue could also be reading from fat (I hope it's fast enough, as decoding 2 320kbps would require a 80KB/s read speed, and 2 128kbps a 32KB/s read speed...).

I don't think the CPU time is the issue (and if it was the case I could eventually decode the second mp3 on the arm7), but I tried adjusting the buffer size and the mp3 decoded audio filling methods, with no concluant results.

My system is made of 5 buffers for each mp3:

- the current audio buffer, which is played by the NDS sound hardware, X 2 for stereo

- the decoded audio buffer, which is where the mp3 decoded data goes, it's made of 2 buffers (for swapping), when one buffer is feeding the NDS audio buffer, the second is getting filled by decoding mp3 frames, and I swap them when it needs (again, X2 for stereo)

- the read buffer (encoded mp3 data), contains the mp3 streamed from fat. Its refill is currently triggered when it does not contains enough data to decode a mp3 frame, and could possibly a source of issue.


One other thing which is bothering me is the display & command system, which is done in the current version in the VBL handler: currently it's just made of some printf and basic command checks, but when a little more complicated display will be added, I fear that this solution will causes some problems, as it might not be interrupt-friendly...


I would like to have your ideas, opinions/suggestions concerning all this system, as I run out of ideas for now :(

#131215 - DVSoftware - Tue Jun 12, 2007 1:45 pm

why don't you decode one mp3 on arm7?

#131217 - Noda - Tue Jun 12, 2007 2:07 pm

because arm7 can't go over 128kbps birates...

#131220 - Sunray - Tue Jun 12, 2007 2:27 pm

Reading 80 KiB/s should not be a problem. I got around 1 MiB/s when I tried. :)

Edit: Why would anyone want to stream two MP3s simultaneously?

Last edited by Sunray on Tue Jun 12, 2007 7:02 pm; edited 1 time in total

#131229 - DekuTree64 - Tue Jun 12, 2007 6:54 pm

Maybe have ARM7 handle the source data streaming? You could use the two 16KB shared RAM banks, loading into one while ARM9 decodes the other, so you don't get any stalling.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

#131238 - DVSoftware - Tue Jun 12, 2007 10:50 pm

Quote:
Edit: Why would anyone want to stream two MP3s simultaneously?


I will probably need something like that for my game, where one track is guitar, and other track is all other... but i probably can go away with recording normal song and song without guitar, and then read both files, and just switch pointer to data when needed... still undecided... i don't know if i can process it realtime to reduce guitar

#131242 - tepples - Tue Jun 12, 2007 11:06 pm

MP3 is decoded in frames. You can decode one frame of the backing track and one frame of the guitar track, making sure to use two different decoder state structures. Or you can do it like Beatmania and Guitar Freaks do it: an MP3 background music and hardware-decoded ADPCM guitar samples.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#131246 - Noda - Tue Jun 12, 2007 11:40 pm

Sunray wrote:

Edit: Why would anyone want to stream two MP3s simultaneously?


For example, to make a DJ app... ;-)

I tried to alternatively decode mp3 frames, but there was still problems as buffers didn't get filled on time :/ I think I'm lacking CPU power here, but I tried with 2 80kbps mp3 (1 = 559% realtime!) and there's still problems...

Maybe I need to rethink my whole system, as my tests proved the bottleneck is not the libfat...

#131252 - kusma - Wed Jun 13, 2007 1:10 am

Noda wrote:
tried with 2 80kbps mp3 (1 = 559% realtime!) and there's still problems...

Are you sure your profiling data are accurate?

#131265 - Noda - Wed Jun 13, 2007 9:57 am

Yes, this results are accurate, but it only takes into account mp3 frame decoding.

So in fact this is a little less with fat, arm7 streaming & desinterleaving added. I'll try do to some other tests with that factors added.