DN-Famitracker generated *.nsf strange behavior
Closed this issue · 28 comments
Hi, Fabio. I need to ask you about NSF, maybe you can help me.
Classic versions of Famitracker and 0cc-Famitracker (https://github.com/HertzDevil/0CC-FamiTracker)
generate standart *.nsf-file, NTSC-headered.
If you play it on emulator in PAL or Dendy mode - tempo will slowing down, and this is absolutely normal.
But new version of DN-famitracker (https://github.com/Dn-Programming-Core-Management/Dn-FamiTracker)
does something strange. It also generates standard.nsf-file, NTSC headered, but it:
- plays same tempo on NTSC/PAL/Dendy (Mesen)
- have old-style behavior described above (nestopia, fceux)
- crackling on puNES at PAL/Dendy.
Maybe you know what's happened in the new NSF-export algorhytms or it's general DN-Famitracker bug?
nsf_test.zip
This is certainly a DN-Famitracker issue.
Hi Eugene, thanks to this report I discovered the existence of some bugs in the NSF player and I discovered the existence of the NSF2 format. This led me to rewrite the player (but maintaining the "emulated" program interface because I really like it). This commit 3dea96c is the first substantial patch of this work which will be followed by a few others until full NSF2 support is completed. The behavior of this issue, even if it was due to a bug in the DN-Famitracker convinced me to rewrite the core of the player, the crackling was due to incorrect design of the player.. Now the crackling doesn't happen even with the buggy nsf generated by the DN-Famitracker, it will simply play at the same tempo on NTSC/PAL/Dendy simply because that's the frequency set in the nsf. If you like, could you test this first patch? It should work fine but I wouldn't mind a few more tests.
Hi Fabio! Do I need to check exactly the new NSF2 format?
Do you have any idea what methodology to test it with? (header flags etc)
By the way, that bug was confirmed by DN-Famitracker devs, and fixed with 0.5.0.2 release.
Maybe you know also where to get the complete NSF2 music archives?
In reality there are few NSF2 files around, the ones I used for the implementation I found here https://github.com/bbbradsmith/nes-audio-tests, but since you also use the classic NSF files a lot, if you find any that doesn't work well with the new version, please let us know here.
Hi Eugene, with the commit a4a9ab6 I changed the management of the NSF play speed a bit. If NSF supports multiple regions (https://www.nesdev.org/wiki/NSF#Header_Overview https://www.nesdev.org/wiki/NSFe#INFO and https://www.nesdev.org/wiki/NSFe#regn) I automatically select the most suitable speed based on the emulator's "Setting->General->Mode" value. If set to "Auto" I select the preferred speed indicated by the NSF itself (now you can see the supported regions and the preferred one in the emulator log when the file is loaded) otherwise if "Setting->General->Mode" is set to one of the three classic modes I select the most suitable speed (which obviously will depend on the regions supported by the NSF). So during the play you may notice a different tempo. I also modified the player so that it always indicates the playback speed (to indicate it I use the corresponding region)
Strange behavior, NSF player is slow as hell now, even on desktop core i5-2500 CPU. I use win-d3d9-x64 build.
I've tested standard NTSC-headered NSF1, no additional chips, but I'm hearing very slow and stuttering music.
Regular *.NES games works okay.
But did you notice this behavior only in the latest commit?
Yes, I tested the latest commit without trying the old one
Can you try this version? https://github.com/punesemu/puNES/actions/runs/7748203304
It have same problems unfortunately.
Ca you also try with this version? https://github.com/punesemu/puNES/actions/runs/7718251835
And can you send me your punes.cfg?
OK, I was able to reproduce the problem, I couldn't because I was trying the 32bit version, only the 64bit version is affected.
And can you send me your punes.cfg?
It happens even on fresh default *.cfg.
BTW, i've downloaded Mr.Norbert1994's NSF archive, cool thing:
https://forums.nesdev.org/viewtopic.php?t=23674
Strange behavior, NSF player is slow as hell now, even on desktop core i5-2500 CPU. I use win-d3d9-x64 build.
I've tested standard NTSC-headered NSF1, no additional chips, but I'm hearing very slow and stuttering music.
Regular *.NES games works okay.
Fixed with b2fcc93.
BTW, i've downloaded Mr.Norbert1994's NSF archive, cool thing:
https://forums.nesdev.org/viewtopic.php?t=23674
Thanks so much for the information!!
New build is much better than old-slow. Still not as fast as old player, but nice anyway.
Even the old laptop for shit-control-testing (intel U5400,1.20 GHz dual-core, no HT) occasionally stutters, desktop is fullspeed now.
So, NSF-player still eats a little bit more resources than a even VRC6 NES game, but the result is already good enough for any modern hardware.
If you're interesting performance research on the shit-control hardware: Looking at task manager - the VRC6 game eats more resources, but runs perfect, while NSF eats a little less cpu power, but does occasionally stuttering sound.
I made some NSF1 and NSF2 files (NTSC, PAL, and Both headered) via DN-Famitracker 0.5.0.2 using FTM music sources.
All music work correct i guess.
Just out of curiosity, can you test if this version works better on your old hardware? punes.zip
No, this version have the same performance.
And with this version? punes.zip
Hi again Fabio. It's even slower than the last one. The GUI rendering is slower. I don't think there's any point in bothering with it.
I've noticed a pattern on all builds. The sound stuttering occurs when the "joystick icon" is refreshed.
So, the slowdowns triggered by GUI
Okay, for now I'll leave things as they are. Thank you very much for your tests.
It's not true, I haven't given up 😄. Can you try this version? punes.zip
Fixed two small bugs punes.zip.
Another small change punes.zip.
It got a lot faster. There is no more slowdowns even on tracks with VRC6.
I guess the problem was related to the GUI-renderer
Yes, the problem was due to the refresh of some parts of the GUI. This is the result of your tests ccbdbab.
As always, thanks for your time.
Thanks Fabio for improving the punes. Such problems are quite difficult to detect without having old hardware.