nesdev.com
http://forums.nesdev.com/

Benchmarking music players
http://forums.nesdev.com/viewtopic.php?f=6&t=13580
Page 1 of 1

Author:  Memblers [ Thu Dec 03, 2015 12:38 am ]
Post subject:  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:

Code:
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.
http://forums.nesdev.com/viewtopic.php?f=6&t=13589

Code:
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.
http://forums.nesdev.com/viewtopic.php?f=6&t=11655
Code:
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)

Author:  rainwarrior [ Thu Dec 03, 2015 9:37 am ]
Post subject:  Re: Relative importance of compositional techniques

Is your NSF benchmark app publicly available?

Author:  thefox [ Thu Dec 03, 2015 11:03 am ]
Post subject:  Re: Relative importance of compositional techniques

(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.)

Author:  rainwarrior [ Thu Dec 03, 2015 11:41 am ]
Post subject:  Re: Relative importance of compositional techniques

That's useful. Thanks.

Author:  thefox [ Thu Dec 03, 2015 12:51 pm ]
Post subject:  Re: Relative importance of compositional techniques

(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.

Author:  Memblers [ Thu Dec 03, 2015 9:39 pm ]
Post subject:  Re: Relative importance of compositional techniques

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:
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.

Author:  rainwarrior [ Thu Dec 03, 2015 10:16 pm ]
Post subject:  Re: Relative importance of compositional techniques

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.

Author:  OneCrudeDude [ Fri Dec 04, 2015 10:43 pm ]
Post subject:  Re: Benchmarking music players

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?

Author:  rainwarrior [ Fri Dec 04, 2015 11:34 pm ]
Post subject:  Re: Benchmarking music players

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.

Author:  Memblers [ Fri Dec 25, 2015 9:51 pm ]
Post subject:  Re: Benchmarking music players

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.

Page 1 of 1 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/