#42352 - Mr Snowflake - Tue May 10, 2005 3:10 pm
This is just a question out of interest, but wouldn't it be possible to write a mp3 software player for the ds. And maybe software movie viewer. I don't know how much processor power it consumes, but if the gba was possible to play (rather poor quality) movies then the ds would be possible to do this a lot better, wouldn't it?
#42354 - zubiac - Tue May 10, 2005 3:38 pm
of course it would be possible but you need something(hardware or card,maybe even Wifi?) to get the actual mp3/movie onto your DS.
I'm sure Nintendo will release a DS enabled "Play Yan" in the near future or mabye MP3/Movie-playback feature will be included in the (rumoured)upcoming PDA software for DS.Just wait till E3 and then we'll know more(I'm PRAYING for PDA software).
and if you can't wait get the "GBA Movie Player" like I did.
It works like a charm on DS,supports <256kb nes/FC games,wav-files,txt-files and the videoquality is NOT bad.And the developers of the GBAMP are constantly working on new features which are easily included via firmware update.
oh and it is just 25 bucks too
_________________
Abusing Cube and DS with all sorts of homebrew and hacks.
#42386 - tepples - Tue May 10, 2005 8:34 pm
| Mr Snowflake wrote: |
| This is just a question out of interest, but wouldn't it be possible to write a mp3 software player for the ds. |
[plug] Try this. [/plug]
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#42432 - Mr Snowflake - Wed May 11, 2005 9:11 am
If I recall correctly this is pretty bad sound quality. And it would be more convenient to just use mp3's instead of converting them back to gsm.
Wat about the cf adapter Darkfader is making. Is it already possible to boot from it? Or maybe boot from a gba flash card. and then switch with the CF thingy, isn't this possible?
#42433 - sasq - Wed May 11, 2005 9:16 am
Take a look at libmad - it should be possible to port (I got it running on GP32) and should have no problem running fullspeed on a 66MHz ARM.
You can at least fit a bunch of MP3:s on a gba flashcard.
#42454 - josath - Wed May 11, 2005 7:26 pm
The Helix MP3 decoder provides MPEG-compliant decoding of MP3 content. The fixed-point decoder is optimized especially for ARM processors
https://datatype.helixcommunity.org/mp3dec.html
For playing a 44.1 KHz, 2 channel, 128 Kbps MP3, it only needs:
26 MHz on an ARM7TDMI or
21 MHz on an ARM9TDMI-REV2
#42496 - tepples - Thu May 12, 2005 2:11 am
| Mr Snowflake wrote: |
| If I recall correctly this is pretty bad sound quality. |
If you find that GSM Player muffles the sound by cutting everything above 9 kHz, then I'm thinking of making a version that adds fake highs. Besides, on the Nintendo DS, the decoder could run twice as fast and in stereo, providing .
| Quote: |
| And it would be more convenient to just use mp3's instead of converting them back to gsm. |
Convenience is the price you have to pay for a decoder that's thought to be patent-free.
| Quote: |
| Wat about the cf adapter Darkfader is making. Is it already possible to boot from it? Or maybe boot from a gba flash card. and then switch with the CF thingy, isn't this possible? |
Yes, you could boot the DS with *Me+flash card and then pak-swap to the CF adapter.
But I find two problems with the Helix decoder: - The quoted "26 MHz" and "21 MHz" figures assume the availability of 60 KB of 32-bit zero-wait-state memory. The GBA has only 32 KB of IWRAM; it'd probably be possible to exploit some VRAM (as recent PocketNES does) but it'd be tricky. The Nintendo DS has only 16 KB of fast instruction memory and 16 KB of fast data memory.
- This copyright license for the decoder doesn't include a patent license for the most essential, most widely recognized patent on encoding and decoding MP3 audio, US Patent 5,579,430 (pdf), which doesn't expire for another 253 fortnights. Its foreign counterparts are also unlikely to expire within the Nintendo DS's commercial lifetime.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#42512 - Darkain - Thu May 12, 2005 8:33 am
| tepples wrote: |
| The quoted "26 MHz" and "21 MHz" figures assume the availability of 60 KB of 32-bit zero-wait-state memory. The GBA has only 32 KB of IWRAM; it'd probably be possible to exploit some VRAM (as recent PocketNES does) but it'd be tricky. The Nintendo DS has only 16 KB of fast instruction memory and 16 KB of fast data memory. [/list] |
the ARM7 on the DS has a dedicated 64kb of IWRAM tho, which helps.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS
#42524 - sonic-nkt - Thu May 12, 2005 3:35 pm
hey.. a perfect video player for the ds would be a program that let the arm7 decode the music and the arm9 the video data... i think good quality movies would be possible then..
#42586 - josath - Fri May 13, 2005 6:40 am
I did a quick crappy port of the tremor ogg vorbis decoder: http://ds.rorexrobots.com/tremor/
#42587 - Darkain - Fri May 13, 2005 6:43 am
several of us have. ;)
does yours run on the ARM7 or ARM9? does yours decompress and then play, or does it stream play?
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS
#42589 - josath - Fri May 13, 2005 6:51 am
runs on the arm9.
and it streams...but only sort of. I just start decompressing the ogg to 0x02104000, then i tell the arm7 to start playing at 0x02104000, and hope that it decompresses faster than it plays. So you can start playing right away. this becomes a problem when i run out of memory.
Ideally, i'd use a small buffer, maybe a few kb, and decompress into that buffer, and keep filling it, and have the arm7 play that buffer on repeat, but i don't really know how to time it correctly. I'm sure i could figure out something with timers...but that involves too much math :P
#42592 - Abcd1234 - Fri May 13, 2005 7:45 am
Sounds like you want a ring buffer. A search turned up this quick tutorial on the topic. Basically, you have a block of memory, a load pointer and a consume pointer. The decoder would feed data into the location at the load pointer, and then increment it, wrapping at the end of the buffer. The ARM7 would read data from the consume pointer and increment it, following behind the load pointer, and also wrapping at the end of the buffer. If the load pointer catches up to the consume pointer, you have a full buffer (so you can stop decoding for a little while), and if the consume pointer catches up to the load pointer, the buffer is empty, and, well, you're in trouble. :)
Using this technique you don't need special timing or anything. Of course, you have to protect the load and consume pointers with a semaphore (which you'd have to hand-roll, though there are probably basic implementations online somewhere), but that's probably the trickiest bit.
#42593 - s4uc3m4n - Fri May 13, 2005 7:45 am
Somebody mentioned the GBA CF Reader (aka Movie Player). Why doesn't somebody rip the encoding and simply make it so it will read more nomal file formats. Is the transfer rate on a CF card to small?
Anybody willing to rewrite the existing OS on the movie player though deserves a huge reward, I can't randomize music and I am stuck with "special file formats" which won't decode DivX movies properly.
Unless there is already something out there I am just not finding.
#42596 - josath - Fri May 13, 2005 9:21 am
yeah ring buffer that's what i wanted to do...problem is, there's no easy way to tell how much the arm7 has read/played so far. so i wouldn't know when my buffer is full. This is because the sound playing is all done in hardware i guess.
#42613 - Abcd1234 - Fri May 13, 2005 3:27 pm
| josath wrote: |
| This is because the sound playing is all done in hardware i guess. |
Oh crap, I see. I hadn't actually looked at the specs on the sound core, so I assumed the ARM7 could feed it directly (I'm actually rather surprised that isn't the case, considering we get a whole other processor for the task... is it certain that there's no other way to use the sound hardware?). Hrm, yeah, in that case, you have no choice but to place the sound core in a loop and have the ARM9 pacing in front of it, decoding audio into a buffer.
I wonder if the SCHANNEL_SOURCE address is updated as the sound is being played back. At least then you could determine if the ARM9 was going to catch up to the sound core.
#42638 - DekuTree64 - Fri May 13, 2005 6:49 pm
Since you set the sound channel frequency with a timer, you can use a normal hardware timer to count samples played.
Although... nobody knows the exact number of cycles per frame for the DS, do they? Like the GBA's 280896 that allows picking nice frequencies for timing off VBlank.
Actually now that I think about it it may just be 2x/4x that... I'll have to run some tests sometime.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#42641 - josath - Fri May 13, 2005 7:04 pm
just tested...schannel_source & schannel_length always return 0 when read :(
#42652 - Darkain - Fri May 13, 2005 7:54 pm
| josath wrote: |
| just tested...schannel_source & schannel_length always return 0 when read :( |
you must not be around #dsdev much... ;)
we discussed this quite a bit last night. SCHANNEL_LENGTH, SCHANNEL_TIMER, and SCHANNEL_SOURCE are all write-only. SCHANNEL_CR is R/W, but the only useful information you can really pull from it is if it is still playing or not. thats about it.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS
#42654 - tepples - Fri May 13, 2005 8:05 pm
2160 ARM7 cycles per scanline and 263 scanlines per frame. Plug 568080 cycles/frame and 33500000 cycles/second into my calculator to get this:
With 16 cycles per fetch and 500-4000 cycles per sample:
| Code: |
Period BufLen Freq
789 720 42458.81
1315 432 25475.29
2367 240 14152.94
3945 144 8491.76 |
With 8 cycles per fetch and 500-4000 cycles per sample:
| Code: |
Period BufLen Freq
526 1080 63688.21
789 720 42458.81
1315 432 25475.29
1578 360 21229.40
2367 240 14152.94
2630 216 12737.64
3945 144 8491.76 |
Do we know the real depth of the Nintendo DS audio FIFOs yet?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#42677 - Chetic - Fri May 13, 2005 11:07 pm
Sorry for the stupid question josath but, why the low sound quality?
#42692 - josath - Sat May 14, 2005 1:25 am
the low quality is due mainly to the low sample rate (11khz), combined with the DS's not so great speakers. It sounds nicer with headphones. CDs are ~44khz, so dropping it to 11khz you lose all the higher frequencies.
The low sample rate, is because right now it's not fast enough. If I raise it to 22khz, it can't decode fast enough. (I may be doing something stupid that is slowing it down alot however)
#42724 - josath - Sat May 14, 2005 7:47 am
just for giggles i did a port of the libmad mp3 decoder...
this time i tried a high quality file (44.1khz, 80kbit, mono). problem is, it's too slow to stream. probably my fault, i'm no good at optimizing.
you have to wait for it to decode more before you hit play. or just hit play, and after a while it will loop around and start playing again.
http://ds.rorexrobots.com/libmad/
#42731 - Chetic - Sat May 14, 2005 12:07 pm
Wow josath, that sounded just as good as if I played it on my computer but without the equalizer on! (connected DS to stereo)
It's like we already have an mp3 player now :p
Wish I could be more help than I am now..