Benchmarking music players

Discuss NSF files, FamiTracker, MML tools, or anything else related to NES music.

Moderator: Moderators

Post Reply
User avatar
Memblers
Site Admin
Posts: 3770
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Benchmarking music players

Post by Memblers » Thu Dec 03, 2015 12:38 am

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:

Code: Select all

Individual Features
DJ Tepples
2015 Damian Yerrick

NSF init finished.  719 instructions.  CPU: 2490 cycles  PPU: 21.9 lines
NSF playing... (ESC to quit)
NSF play stopped.

Max CPU: 5561 cycles  Max PPU: 48.92 lines
Average CPU: 1464 cycles  Average PPU: 12.88 lines
1550043 frames played - 430 minute(s), 3 second(s)
Here another rendition of the same test song by tepples, in his Pently 0.05wip version.
viewtopic.php?f=6&t=13589

Code: Select all

Pently demo
DJ Tepples
2015 Damian Yerrick

NSF init finished.  177 instructions.  CPU: 639 cycles  PPU: 5.6 lines
NSF playing... (ESC to quit)
NSF play stopped.

Max CPU: 2649 cycles  Max PPU: 23.31 lines
Average CPU: 825 cycles  Average PPU: 7.26 lines
2072561 frames played - 575 minute(s), 41 second(s)

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

Code: Select all

NSF init finished.  477 instructions.  CPU: 1662 cycles  PPU: 14.6 lines
NSF playing... (ESC to quit)
NSF play stopped.

Max CPU: 5361 cycles  Max PPU: 47.16 lines
Average CPU: 1577 cycles  Average PPU: 13.87 lines
1236767 frames played - 343 minute(s), 47 second(s)

User avatar
rainwarrior
Posts: 7672
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Relative importance of compositional techniques

Post by rainwarrior » Thu Dec 03, 2015 9:37 am

Is your NSF benchmark app publicly available?

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: Relative importance of compositional techniques

Post by thefox » Thu Dec 03, 2015 11:03 am

(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.)
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

User avatar
rainwarrior
Posts: 7672
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Relative importance of compositional techniques

Post by rainwarrior » Thu Dec 03, 2015 11:41 am

That's useful. Thanks.

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: Relative importance of compositional techniques

Post by thefox » Thu Dec 03, 2015 12:51 pm

(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.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

User avatar
Memblers
Site Admin
Posts: 3770
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: Relative importance of compositional techniques

Post by Memblers » Thu Dec 03, 2015 9:39 pm

rainwarrior wrote:Is your NSF benchmark app publicly available?
Sort-of, it's put together sloppily but my post in this thread has it attached:
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.

User avatar
rainwarrior
Posts: 7672
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Relative importance of compositional techniques

Post by rainwarrior » Thu Dec 03, 2015 10:16 pm

Memblers wrote: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.
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).
Memblers wrote: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.
There are a lot of cases where this would be very noticeable.

User avatar
OneCrudeDude
Posts: 274
Joined: Fri Aug 23, 2013 2:14 am

Re: Benchmarking music players

Post by OneCrudeDude » Fri Dec 04, 2015 10:43 pm

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?

User avatar
rainwarrior
Posts: 7672
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Benchmarking music players

Post by rainwarrior » Fri Dec 04, 2015 11:34 pm

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.

User avatar
Memblers
Site Admin
Posts: 3770
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: Benchmarking music players

Post by Memblers » Fri Dec 25, 2015 9:51 pm

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.

Post Reply