#177425 - hacker013 - Fri Jun 01, 2012 10:15 am
Heyhey everyone ^^,
I needed mp3 playback and with help from Elhobbs (he did most of the work) I got it working with the latest devkitARM release (r40). I made an example with it so everybody can use it :P.
Download, specs and other info
~Hacker013
_________________
Website / Blog
Let the nds be with you.
Last edited by hacker013 on Wed Aug 14, 2013 2:14 pm; edited 4 times in total
#177427 - fincs - Fri Jun 01, 2012 10:49 am
By the way, the latest devkitARM is r40, not r38.
#177428 - hacker013 - Fri Jun 01, 2012 10:53 am
Thx ^^ I fixed that misinformation :P Now it should be correct :3
_________________
Website / Blog
Let the nds be with you.
#177435 - sverx - Mon Jun 04, 2012 1:26 pm
Are you sure the 'AS_StereoDesinterleave' asm function really works? It seems to me it's copying only the data for left channel... :|
_________________
libXM7|NDS programming tutorial (Italiano)|Waimanu DS / GBA|A DS Homebrewer's Diary
#177436 - elhobbs - Tue Jun 05, 2012 2:04 am
you are not wrong.
#177442 - sverx - Wed Jun 06, 2012 1:07 pm
...and it's using 1 hw channel only, so I guess this needs some fixing to be able to play stereo mp3s... maybe it's working with mono mp3s?
_________________
libXM7|NDS programming tutorial (Italiano)|Waimanu DS / GBA|A DS Homebrewer's Diary
#177443 - elhobbs - Wed Jun 06, 2012 1:19 pm
when I originally put this together for cquake I planned on stereo output, but I did not have enough memory for buffers for both channels. so, I dropped one channel which works fine for cquake. So, it currently requires stereo mp3 files, but only plays one channel. I had planned on fixing it, but I never got around to it.
#177444 - sverx - Wed Jun 06, 2012 3:25 pm
#177445 - sverx - Sat Jun 09, 2012 12:21 pm
I made it by myself... but I wonder why it's so 'jumpy'... I hope you get what I mean (there's a very short silence every some milliseconds...)
Isn't a 33MHz ARM processor powerful enough to decode a 96Kbps 22MHz -stereo- MP3? I can't believe it, really! What's inside my old 128 MB usb key MP3 player then? It can play 192Kbps 44MHz stereo MP3s whith no problem at all, and it came for free why a one year subscription to a magazine!!!
Anybody cares to explain to me what I'm not getting by my own? Thanks! :)
_________________
libXM7|NDS programming tutorial (Italiano)|Waimanu DS / GBA|A DS Homebrewer's Diary
#177446 - elhobbs - Sat Jun 09, 2012 4:21 pm
I do not know anything about your mp3 player, but there are a lot of reasons why it may be more suitable as a mp3 player. The ds is decoding everything in software with no hardware decode support. Also the ds does not have the fastest file access speeds - this is also very dependent on the sd card you are using.
#177447 - sverx - Sat Jun 09, 2012 10:01 pm
Sorry, I really didn't mean to ask if somebody knew what's inside my MP3 player... I was just wondering how a 33MHz processor can't be fast enough to do what -to me- seems not a very though work, decode an MP3.
I have to research a bit about what exactly is involded into that task, because my knowledge is quite limited... I just know it should be a sort of a huffman-compressed FFT of an audio frame but maybe I'm underestimating it completely...
(file access shouldn't be the problem, anyway, since I can stream wav files with absolutely no problem...)
_________________
libXM7|NDS programming tutorial (Italiano)|Waimanu DS / GBA|A DS Homebrewer's Diary
#177448 - elhobbs - Sat Jun 09, 2012 11:12 pm
I have not had the problem you described. At higher encoding speeds I had trouble with skipping in cquake. I suspect it was because cquake was using too much CPU time and was not allowing the file buffer to fill on time.
#177449 - elhobbs - Sun Jun 10, 2012 2:31 am
Are you using an emulator or a real ds? This does not work particularly well in emulators.
#177453 - sverx - Mon Jun 11, 2012 9:14 am
No, I am testing it on my DS Lite... btw I think I really need to re-check the code because I hardly believe that it's just my "stereo de-interleave" code that slow things so badly... :|
_________________
libXM7|NDS programming tutorial (Italiano)|Waimanu DS / GBA|A DS Homebrewer's Diary
#177454 - sverx - Mon Jun 11, 2012 10:07 am
mmm... I am wondering, since there's a malloc() on ARM7 code, if this is allocating the buffer into Main RAM or into WRAM?
The latter would be a better idea (there are 64+ KBytes of 0-wait-state 32bit bus access memory there...)
_________________
libXM7|NDS programming tutorial (Italiano)|Waimanu DS / GBA|A DS Homebrewer's Diary
#177455 - elhobbs - Mon Jun 11, 2012 10:42 am
Arm7 malloc does not allocate from the 4MB main ram. That needs to be done from the arm9. However, the sound hardware requires that the memory region it plays from be in main memory. The decode buffer is in the arm7 memory region. The deinterleave moves the samples from the decode buffer to the play buffer. In any case the helix code (and the memory the it allocates) uses most of the memory available on the arm7. In fact if you do not optimize the arm7 code for size it fails to initialize the mp3 decoder at runtime.
#177456 - sverx - Mon Jun 11, 2012 10:57 am
I see. I was also checking the map file and searching this forum and realized everything on ARM7 is on WRAM (iwram), I mean code, variables, stack and heap. And I realize why it needs -Os so badly :|
So maybe it's really deinterleave function fault, since it's reading from WRAM and writing non-sequentially to (slow) Main RAM. I might need to optimize it so that it doesn't write one halfword per channel each time... :|
| Code: |
ldmia r0!, {r4-r11}
strh r4, [r1], #2
lsr r4,#16
strh r4, [r2], #2
subs r3, #1
beq _done
... and so on...
|
_________________
libXM7|NDS programming tutorial (Italiano)|Waimanu DS / GBA|A DS Homebrewer's Diary
#177457 - elhobbs - Mon Jun 11, 2012 3:08 pm
there is a cpuusage.xls file in the helix/fixpt/docs directory. It indicates that higher speeds and bit rates could be possible. But, the specs are for zero-wait state memory. Even in this case it looks like it would take nearly all of the cpu time on the arm7. once you add in the rest of the stuff on the arm7 - interrupts, touchscreen/controls, etc. you are looking at a maxed out arm7. in this case you probably need to do something about the vblank waits in the arm7 main loop - there may be no spare time to wait!
I am not sure that high bit rates and/or stereo are worth the effort for a game. unless maybe the music is reacting to the player/situation. even then you would need to be using headphones as the speakers on the ds are fairly low quality. As a stand-alone music player it might make sense - in that case you would be better off moving everything to the arm9.
#177459 - sverx - Mon Jun 11, 2012 3:33 pm
Interesting table... to see how much the CPU is occupied I should compare the value in MHz in the table with the CPU speed, right? Like ARM7TDMI 26MHz for a 44.1KHz 128Kbps MP3 makes 26/33.5 = 78% CPU time...
Then, I didn't notice the decoding isn't driven by a CPU timer interrupt but from the 'main' vblanking loop... this of course can make everything go wrong... but I would rather expect a different side effect: not sort of a silence but sort of "jumpyness", like when a records skips, since the audio channels are used in REPEAT mode... :|
(btw I'm not personally planning to do anything with it, I'm just doing it for fun :) )
_________________
libXM7|NDS programming tutorial (Italiano)|Waimanu DS / GBA|A DS Homebrewer's Diary
#177460 - PypeBros - Mon Jun 11, 2012 4:16 pm
| sverx wrote: |
mmm... I am wondering, since there's a malloc() on ARM7 code, if this is allocating the buffer into Main RAM or into WRAM?
The latter would be a better idea (there are 64+ KBytes of 0-wait-state 32bit bus access memory there...) |
I suppose just iprintf("%p",malloc(100)) could tell, no?
(please disregard : I just hadn't clicked "page 2" ^^" )
_________________
SEDS: Sprite Edition on DS :: modplayer
#177462 - elhobbs - Mon Jun 11, 2012 5:34 pm
| sverx wrote: |
Then, I didn't notice the decoding isn't driven by a CPU timer interrupt but from the 'main' vblanking loop... this of course can make everything go wrong... but I would rather expect a different side effect: not sort of a silence but sort of "jumpyness", like when a records skips, since the audio channels are used in REPEAT mode... :|
(btw I'm not personally planning to do anything with it, I'm just doing it for fun :) ) |
the problems you are experiencing are from the changes you have made. the sample as provided does not have audio glitches. processing in the main loop is fine - it is syncronizing with a timer - and everything works fine as long as you encode the mp3 properly. If you use too high of a bit rate or frequency then it will starting skipping.
#177463 - sverx - Tue Jun 12, 2012 9:01 am
| elhobbs wrote: |
| the problems you are experiencing are from the changes you have made. |
true, I realized the same yesterday evening when I heard that the unexpected effect is on right audio channel only :| I'll double check my code...
_________________
libXM7|NDS programming tutorial (Italiano)|Waimanu DS / GBA|A DS Homebrewer's Diary
#177464 - Tomwi - Wed Jun 13, 2012 10:38 am
| Quote: |
when I originally put this together for cquake I planned on stereo output, but I did not have enough memory for buffers for both channels. so, I dropped one channel which works fine for cquake. So, it currently requires stereo mp3 files, but only plays one channel. I had planned on fixing it, but I never got around to it.
|
I've made a 16 bit (a 8bit too, but that won't be useful here) deinterleave which may be useful for you. It can split to two buffers (one big buffer cut in two, first part is left, second part is right). If I'm not mistaken it could speed up things on the arm7 (every sample will pass the deinterleave function:D)
Because I had to optimize for speed, it will deinterleave 4n samples (you can feed it for example 5 samples, but it will deinterleave just 4 for you + just as your deinterleave it needs word alignment for the interleaved buffer (but also for the outbuffer)).
https://github.com/Tomwi/soundStream/blob/master/source/deinterleave.s (contains the 8bit deinterleave as well)
or
| Code: |
.equ BUF_BYTES, 8192*2
.global _deInterleave
.hidden _deInterleave
.type _deInterleave, %function
.arm
.align 2
_deInterleave:
cmp r2, #4
bxlt lr @ nothing to split
bic r2, r2, #3
push {r4-r9}
add r3, r1, #BUF_BYTES
mvn r8, #0
lsl r8,#16
.split:
ldmia r0!,{r4-r7}
@ split left
bic r9, r4, r8
orr r9, r9, r5, lsl #16
@ split left
bic ip, r6, r8
orr ip, ip, r7, lsl #16
@ store left
stmia r1!,{r9,ip}
@ split right
and r9, r5, r8
orr r9, r9, r4, lsr #16
@ split right
and ip, r7, r8
orr ip, ip, r6, lsr #16
@ store right
stmia r3!,{r9,ip}
subs r2,#4
bne .split
pop {r4-r9}
bx lr |
Tomwi
#177465 - sverx - Wed Jun 13, 2012 10:53 am
OK, I finally found the problem. I didn't see the desinterleave asm function wasn't the only code that was copying data from the interleaved buffer... :|
So, here's it: http://wcms.teleion.it/users/cgq/nds/MP3ExampleSource.rar - and it's stereo now :)
Tomwi: thanks :) You can try replacing the original code with yours and see if there's an interesting improvement :)
_________________
libXM7|NDS programming tutorial (Italiano)|Waimanu DS / GBA|A DS Homebrewer's Diary
#177489 - sverx - Mon Jul 02, 2012 2:26 pm
I've been running some tests lately, and I also wrote my considerations (and rants ;) ) into this blog post.
_________________
libXM7|NDS programming tutorial (Italiano)|Waimanu DS / GBA|A DS Homebrewer's Diary
#177490 - elhobbs - Mon Jul 02, 2012 6:03 pm
did you confirm that cpu decode was actually the issue? I was very limited with cquake in regards to buffer sizes - I had very little main ram to spare. it is quite possible that larger read and decode buffers code allow higher encoding speeds to play correctly. I never tried - nor did I try to measure cpu usage.
#177492 - sverx - Tue Jul 03, 2012 8:53 am
well, from what I've seen I would say: yes, it seems that you hit an hard limit when you ask the ARM7 too much work (a 44.1KHz stereo MP3 encoded at 128Kbps and higher bitrates, for instance).
BTW it's also true that I didn't run any test using larger buffers... even if I personally believe it won't change that much.
_________________
libXM7|NDS programming tutorial (Italiano)|Waimanu DS / GBA|A DS Homebrewer's Diary