NSFPlay 2.2

[rainwarrior]

That's not really a bug, there is a setting that stops a track after 3 seconds of silence. You can turn it off, or adjust the silence length, or use a playlist.

[blargg]

If it was set to stop after say 20 seconds of silence, would that cause 20 seconds of audible silence at the end of tracks, or can NSFPlay run ahead internally, notice the long silence, and stop the track only a couple of seconds of actual played silence?

[rainwarrior]

Eh, I don't think that kind of look-ahead is really worth implementing. I don't want to get too fiddly over a fairly innocuous edge case. This is a problem that affects a very small number of NSFs, and there's already a number of solutions available.

1. Turn off the feature.
2. Make the silence length long enough to cover this track.
3. Make an NSFe version with track times.
4. Make an M3U playlist via winamp. (Eventually I want to implement playlist support in the NSFPlay standalone as well.)

I could set the default to 5 seconds, which would immediately eliminate probably 90% of cases where this is happening.

[TmEE]

What kind of buffering strategy is used ? It does not take a lot to cause lot of gaps in the sound on my laptop with a 1.6GHz single core Athlon. Scrolling windows and loading web pages usually causes some hiccuping, sometimes a lot.
On my 3GHz P4 desktop these hiccups happen less often.

[rainwarrior]

If you run it in Winamp it'll be buffered by however winamp is set up, and you can customize winamp's buffering, I believe.

I guess the stand alone version never had any options, though I believe it's relatively deep. Lemme check... looks like 32 blocks of 4096 bytes, so... I guess that's about 3/4 second under normal circumstances? I haven't adjusted it since I took over the project, I'm not sure if it needs to be any longer.

The bigger problem is probably CPU usage. If you're getting a lot of skipping, your computer just isn't keeping up with the audio generation. A deeper buffer probably won't help, it'll just take slightly longer to kick in. I'd actually recommend going to the chip settings pages and turning down the quality on each of them from the maximum to one under the maximum, and see if that helps instead. Alternatively you can bump the thread priority in the task manager so it gets a bigger time slice.

Another option is to use the program to render MP3s, maybe, since they're a bit less CPU-demanding to play back. This is a bit inconvenient, and trades space for size, obviously.

Also, turning off stereo sound will double the buffer length (timewise), so you can try that too.

[koitsu]

I would also suggest trying setting the priority class in Winamp from Normal to High, just to see if that gives the timeslice sharing algorithm in the OS enough of a bump that it keeps the buffer from maxing out.

If your single-core 1.6GHz Athlon is backed by a video chip that has little-to-no hardware acceleration, then rendering and scrolling web pages, etc. is going to heavily CPU-bound. There's also the audio chip aspect too, where it's highly possible mixing is done CPU-side (i.e. in the driver, with no hardware offloading). And all this begins to hurt even more if you're using something like Windows 7.

Honestly what you (TmEE) should be doing is busting out something like perfmon and trying to figure out what is truly taking up all of your CPU time during these types of situations. Or if there's a way to profile NSFPlay/NSFPlug that would be even more ideal. But let's be at least somewhat reasonable here -- things like the Athlon 2650E just aren't going to get attention. 512KB L2 cache, 15W TDP? The intended goal of that CPU is purely something like a palmtop or bare-bones netbook (e.g. today's mobile phones have more capability than this). I'm not saying optimising things for lower-class CPUs should be ignored -- far from it! -- but someone with that hardware will need to step up to the plate to figure out where all the time is going.

[rainwarrior]

Or just turn down the quality settings!

[TmEE]

Lowering the settings did help but not too much. Same problems happen on the standalone player too.
Old NSFplug never had problems (but I guess it was not so accurate either).

As for CPU use, Winamp seems to use up some 10% and overall CPU use rarely maxes out. But seems increasing priority fixed the hiccups. Last time I had to adjust priority was when I was still on a Pentium1... haha

[rainwarrior]

Hmm, that's unfortunate. Well, other than the currently sorta-broken state the FDS is in for the beta 2.3 (I am currently rewriting it), performance shouldn't be significantly worse than older NSFPlay versions. As I said though, I am definitely planning a performance pass eventually, just not a priority until I have done more work on accuracy.

[Knurek]

How does the detect loop feature work?

I can see the player updating the times for subsongs while playing, but it doesn't seem to be saving that even with the 'Save the playtime when detected' option enabled.

Would it be possible to use this for an auto-timing tool? Something similar to gsfopt tool I've been using as a helper with timing GBS files for portable music history.

I'd love to start console music history site as well, and timing 1500+ NSF sets by hand is not something I'm looking forward to very much.

[rainwarrior]

It can't save times back to the NSF because the NSF doesn't have anywhere to put times. I -think- it might save times back to a winamp playlist if you're using one, but I haven't really looked into what the save playtimes features does in detail yet. (Eventually I want NSFPlay to have its own playlist window, but that'll be a future improvement.)

The loop detector basically works by keeping a log of registers written each frame. When it finds a sequence of frames that matches a previous sequence, it thinks that's a loop. I think it needs a little tweaking still, but it won't get that much better than it already is. There is also a silence detector which stops the track when a specified amount of silence is found.

As you may have noticed, there are occasional false positives. A section of music that repeats verbatim will be considered a loop if new material doesn't follow soon enough after. A section of silence too long will be considered the end of track by the silence detector. False negatives also occur frequently enough.

I don't think the loop detector is good enough to use it for automated conversion anyway. You'll have way too many tracks you need to go back and fix the length on. If you want to do it properly you really do need to verify this by hand.

When I eventually get around to creating a playlist tool for NSFPlay, it should be able to save that playlist with the NSF as an NSFe. I will not be working on this for a while though. Currently I think only NotSoFatso has an NSFe playlist editor.

[blargg]

When I wrote a loop detector, I found some music that used fractional frame timing, so that on successive loops the writes might be one frame earlier or later than the previous loop, due to rounding. E.g. if it updated every 1.5 frames, you'd have 1-23-45-67..., and on second loop you might have 12-34-56-7...

[tepples]

If you want a test case of what blargg is talking about, this NSF uses fractional frame timing. Tempos are specified in rows per minute, and the NTSC replayer assumes 3606 frames per minute because I'm anal.

[rainwarrior]

Yep, I've seen that too, it's one of the cases that I file under false negatives. The output may be extremely similar, and probably is conceptually a "loop" to its engine at a high level, but I don't think I'd want to automatically detect such a thing as a loop. I think false positives are a worse problem than false negatives, so I'd rather be a little more restrictive about it.

There's so many edge cases to loop detection. There's also things like, say a channel is muted the first time through, and then the first "loop" it gets turned on with $4015, after that one write the rest of the data will look like an exact loop. Even just patterns that are very subtly different, like one note at the beginning of a phrase of slow music that makes all the difference (but it otherwise identical data), especially for things like VRC7 where the engine doesn't tend to touch the registers every frame.

I think the right idea for dealing with loop detection problems is to put track lengths in the data (e.g. make NSFe files). From my perspective the problem isn't the loop detector, it's the lack of widespread support for NSFe and good tools for making them.

Edit: tepples, yeah I don't really need a test case. It's not a problem I intend to solve.

[koitsu]

More NSFPlay GUI stuff (at least in the Winamp config bits):

The up/down arrows under Options/Settings for adjusting default number of loops, stop song after X seconds of silence, and playtime detection size, are inverted in operation -- clicking Up decrements the number, while clicking Down increments it.