Benchmarking music players

I know this isn't too useful, but for the fun of it, I ran a random FamiTracker-generated NSF through my NSF benchmark app, and got this:



Here another rendition of the same test song by tepples, in his Pently 0.05wip version.
http://forums.nesdev.com/viewtopic.php?f=6&t=13589




GGSound by Gradual Games. The song benchmarked is the 3rd track in the included demo, because it uses 4 channels.
http://forums.nesdev.com/viewtopic.php?f=6&t=11655

Is your NSF benchmark app publicly available?

(OT: NDX can also be used for NSF benchmarking -- it will display cur/avg/max in the Debugger window (Timers) when an NSF is playing.)

That's useful. Thanks.

(Maybe this NSF benchmarking discussion should be split off?)

Here's something I always found interesting: Solstice, with one of the more technically complex tunes you can find on NES, only averages around 500-600 cycles in its play routine. Same seems to be true for most other Follin tunes (Silver Surfer, ...).

I find most other games to be in the 1000-2000 cycle range.

Sort-of, it's put together sloppily but my post in this thread has it attached:
http://forums.nesdev.com/viewtopic.php?f=3&t=13322

To use it, the NSF file has to be renamed to "guardian.nsf".. yeah, I know how to use argc and argv since then.
(edit: also, it only plays the starting track #)

I'm sure Nintendulator DX is a better option, but there it is anyways.

Since this is a new thread now, one of the things I was wondering about, is if Famitracker's engine is anything like NT2, the big CPU usage spike is at the beginning of a new pattern. If so, it makes me wondering if staggering the channel processing over a couple frames would help it much. Like having pulse #2 and noise always lag by one frame. Just a thought, maybe it'd be noticeable in some cases, but detrimental, I kinda doubt it.

Long ago when I was writing my SNES NSF player, I was using the background color to see CPU usage of various NSFs, I seem to remember that Jeroen Tel stuff (Robocop 3 in particular) had very consistent CPU usage, like the color bar was barely moving.

Changing a pattern isn't really that expensive by itself. I think Famitracker tends to peak on frames with a lot of active effects, and/or a new note on every row. A lot of patterns happen to begin with a set of new notes across all channels and a bunch of effects on the first row, which would tend to put a spike there (but not specifically because of the pattern change itself).


There are a lot of cases where this would be very noticeable.

Hmm, I always assumed that FT produced music was not very optimized for actual game use, guess this benchmarking tool sorta proves that. I reckon the more advanced FT songs (Extends Levant/HertzDevil, anything by Chibi-Tech) would be impossible to work in an NES game scenario, right?

Just because something sounds busy doesn't mean it's impossible or impractical in a game, or even that it's using too much CPU.

Other than technical problems like nonstandard playback rates (e.g. 240Hz NSFs), or expansion audio, or PCM samples, for the most part the music people are making now could get into a game.

There are a number of constraints that real games have (especially ROM space, RAM space) that commercial-era NES game composers had to make strong sacrifices to meet. People making music in Famitracker aren't trying to meet any of these constraints, which gives them a much wider palette of expression than most game composers had available to them.

The CPU speed of Famitracker isn't really that big an issue. Its RAM usage is a little bit high, but with WRAM it'd be a non-issue. ROM usage of the kind of detailed music a lot of people write now is a concern if you're making a game, but this is a question of how much space you're willing to dedicate to music. There were 2 or 3 NES games with very large soundtracks (64k was about as big as they ever got), but people routinely write much larger single songs in Famitracker. They might actually be able to write something similar in smaller spaces if they were forced to deal with space constraints (they simply haven't had to deal with it via Famitracker), or it might even be sensible to just use larger ROM sizes now. Depends on the game and your project goals.

Coming back the 'staggered channel update' idea, I thought of a variation that should be less noticeable by moving the audible delay to the end of a note. So if the channels are updated in 2 phases, the first phase channels would have (beforehand) added a dummy entry to all the envelopes (at volume 0), and the second phase channels would be processed normally in the next frame. So in the tracker when you have every channel hitting on the same line, the note/instrument/pattern initialization could happen on different frames, while the actual sound of both channels would start on the same frame. You would just have a forced cut-off right before a new note, but only the first phase channels. The more percussive the instrument used, the less noticeable the early cut-off would be.

If anyone wondered why all this, it's to get a lower worst-case CPU usage.