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 > Specifics of time()

#161992 - Musturd12 - Fri Aug 22, 2008 8:53 pm

I have some questions about the time() function.

Can someone tell me what the time() function returns? How fast is it (roughly how many clock cycles to run it)? Would it be fast enough to grab a time and every hundredth of a second and subtract from a previous time (as in keep grabbing times until time = time + 100 sort of thing)
If I paused a song and played it again every 100th of a second would it sound distorted? Is there any nice documentation about time()?

Thanks.

#161993 - Griffin - Fri Aug 22, 2008 9:06 pm

Time is correct to one second (if you're talking about the one in time.h that is).

#161994 - Musturd12 - Fri Aug 22, 2008 9:11 pm

Is there anyway to wait for a certain amount of milliseconds?

#161995 - tepples - Fri Aug 22, 2008 9:14 pm

time() returns the number of seconds since midnight on January 1, 1970.

I just looked at the libnds clock code. Currently, the ARM7 updates the UNIX time in shared memory and the ARM9 picks it up from there inside dkarm-eabi's patch to libgloss. (In future libnds, this will apparently change to the ARM9 using the ARM7 as a server through the FIFO.)

If you want to use centiseconds or milliseconds to time game events, try counting in vblank units (16.7 ms) instead.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#161996 - Musturd12 - Fri Aug 22, 2008 9:20 pm

so if I do:
WaitForVBlank();
WaitForVBlank();
WaitForVBlank();
WaitForVBlank();
WaitForVBlank();
WaitForVBlank();

It would wait 100.2 msecs?
Is there anyway I can play an mp3 file while it is waiting for vblank?

#161997 - Griffin - Fri Aug 22, 2008 9:24 pm

The sound hardware (probably) will keep running while you're waiting for the vblank. It may be easier to just have a timer that you increase by 1/60 every frame and use that for synchronising time events.

Last edited by Griffin on Fri Aug 22, 2008 9:25 pm; edited 1 time in total

#161998 - tepples - Fri Aug 22, 2008 9:24 pm

Musturd12 wrote:
so if I do:
WaitForVBlank();
WaitForVBlank();
WaitForVBlank();
WaitForVBlank();
WaitForVBlank();
WaitForVBlank();

It would wait 100.2 msecs?

Yes, plus or minus a few fractions of a millisecond. The DS screen is redrawn 60 times a second, and swiWaitForVBlank() waits for the interrupt that the DS video chip sends at the end of each redraw.

Quote:
Is there anyway I can play an mp3 file while it is waiting for vblank?

Repeat these steps over and over:
  • In the ARM9 program, decode a short piece of the MP3 file.
  • Tell the ARM7 program the address of this short piece.
  • Wait for vertical blank.

A rumored future version of libnds will make step 2 straightforward.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#161999 - Musturd12 - Fri Aug 22, 2008 10:36 pm

Let BPM = 120
1,002,000 VBlanks (16.7 ms) = 1 minute
120 * x = 1,002,000
x = 8350
8350 VBlanks per Beat???

Can someone verify this? (Please! I am killing myself over figuring this out)

And how would I:
Quote:
Tell the ARM7 program the address of this short piece.
?

#162001 - tepples - Fri Aug 22, 2008 11:17 pm

Musturd12 wrote:
1,002,000 VBlanks (16.7 ms) = 1 minute

No. There are 60 vblanks in a second, and 60 seconds in a minute, so 3600 vblanks in a minute.

Quote:
And how would I:
Quote:
Tell the ARM7 program the address of this short piece.
?

First look up circular buffer in Wikipedia. Make a circular buffer long enough to hold about a quarter second of decoded audio (two buffers if you're using stereo), and have the ARM7 write to the sound registers to play it in loop mode.

I just checked for devkitARM and libnds updates today. It appears there is still no standard way to tell the ARM7 the address of this buffer. One can play sounds with playSound(), but they can't loop because a TransferSoundData (defined in <nds/ipc.h>) has no field for looping. In fact, the standard ARM7 code (.../examples/nds/templates/combined/arm7/source/template.c) forces SOUND_ONE_SHOT mode.

So you'll have to write your own code that either passes the address in some part of shared memory (such as the IPC struct) or passes it through the FIFO. You'll have to write code for both the ARM7 and ARM9 (a "combined" project, not an "ARM9-only" project) to do this. Wintermute, the maintainer of devkitARM and libnds, claims that a future version of libnds will get rid of the IPC struct and introduce a standard way of handling FIFO messaging, so you will have to change your buffer playing code once you have updated libnds to this version.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#162003 - Musturd12 - Sat Aug 23, 2008 12:30 am

OK 60 per second.
I'll try to make the code...

#162008 - Cydrak - Sat Aug 23, 2008 2:13 am

tepples wrote:
* In the ARM9 program, decode a short piece of the MP3 file.
* Tell the ARM7 program the address of this short piece.
* Wait for vertical blank.

For the most part, this will work. However, I found it problematic, and I think not as simple as it seems. (Apologies if the following turns out to be too tangential to the discussion.)

MP3 comes in "frames" of around 1000 samples, IIRC. At 44Khz this is about 1/44 sec = 23msec. That's not synchronized with vblank, and probably not with your sound buffer either. It's certainly longer than a DS frame.

So the trouble I ran into (and I don't know if all decoders do this) is that Helix appears to decode entire frames at once. Since the above are out of sync, CPU load can fluctuate rather uncomfortably between vblanks. If the bitrate is high enough, I've noticed it tends to spill over and miss the next vblank.

Naturally, this will make everything else lag. It can even cause skipping, for example if it spills and you hit the *next* swiWaitForVBlank(), right after one just happened. In that case I think you can "lose" whole frames of CPU time... even if you "should" have had enough to begin with!

I've noticed those symptoms in other players too (not that this guarantees I'm doing it right :-), and unfortunately I'm not sure what to suggest. Maybe someone else could chime in? The only solutions that occur to me, short of lower bitrates, are daunting. :/

#162012 - tepples - Sat Aug 23, 2008 6:45 am

The solution depends. Are you trying to use MP3s as music in a game or other app, or are you trying to make an MP3 player app designed just to play MP3s?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#162031 - Musturd12 - Sat Aug 23, 2008 6:30 pm

I'm making a guitar hero clone and I want mp3 custom song support.
So a game, yes.

#162032 - tepples - Sat Aug 23, 2008 6:35 pm

Then you might have to make a transcoder that reduces the complexity of decoding, such as 128 kbps 44 kHz MP3 to 64 kbps 32 kHz MP2. GH for DS has all its songs transcoded to two 28 kHz mono Ogg Vorbis streams if I remember correctly.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#162051 - fluff - Sun Aug 24, 2008 9:00 am

tepples wrote:
Musturd12 wrote:
so if I do:
WaitForVBlank();
WaitForVBlank();
WaitForVBlank();
WaitForVBlank();
WaitForVBlank();
WaitForVBlank();

It would wait 100.2 msecs?

Yes, plus or minus a few fractions of a millisecond.


And minus between 0 and 16.7ms, depending on the active line at the time of the first call.

This may not be relevant to the original question, and I haven't tried using it myself, but isn't there a VLINE reg you can read? Seems to me you could use that to get accuracy down to 16.7ms/256 = 0.065ms.

#162070 - Musturd12 - Sun Aug 24, 2008 9:20 pm

Don't DPG files have mp2 sound?
Could I just look at Moonshell's source and take a little code from there?
Can anyone find a working link to download Moonshell's source?