vgmrips

The forum about vgm files
It is currently 2017-11-22, 18:28:06

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: 2017-11-16, 3:17:44 

Staff Staff
Programmers Programmers
Offline
User avatar

Joined: 2012-04-22, 4:03:45
Posts: 207
Location: New York, NY, USA
Good evening, all! In my recent efforts to clean up broken code in my JS web VGM player, I've chosen to also play around with Electron and Node.js. I recently worked on a project to port my web player to Electron and Node.js in a desktop app format, and so far I like its results. The bonus side effects I've gotten from it include fixing my broken JS QSound emulation and adding passable OKIM6295 emulation, so now all Capcom CPS-1 and CPS-2 tracks should play properly!

No full app distribution just yet, so get the code at https://github.com/vgm/node-vgmplay and do whatever it is you do to get Node stuff working (the readme also has some instructions). Needs Node.js and Electron; works on macOS, should work on Windows and Linux, but I haven't tested it on those yet.


Top
 Profile  
 
 Post subject:
PostPosted: 2017-11-16, 11:52:50 

Staff Staff
Programmers Programmers
Contributors Contributors
Ball Fondlers Ball Fondlers
Offline
User avatar

Joined: 2014-01-28, 5:51:54
Posts: 518
What is this for?


Top
 Profile  
 
 Post subject:
PostPosted: 2017-11-16, 17:33:16 

Staff Staff
Programmers Programmers
Offline
User avatar

Joined: 2012-04-22, 4:03:45
Posts: 207
Location: New York, NY, USA
vampirefrog wrote:
What is this for?


If you mean what OS it's for, it should work on any platform Electron works on. Eventually I'll have pre-made binaries but in the meantime the source is available.

If you mean what chips it's for, it currently does all VGM 1.50, OKIM6295, and QSound.

If you mean what's its purpose, I already said it's a desktop app version of my web player, complete with cores written directly in JS rather than compiled from VGMPlay using Emscripten.

If you mean why did I make it, I mainly did it to have a version of my web app that was more desktop oriented and to get used to the ins and outs of Node.js and Electron. I'm also going to be testing new JS cores on this first from now on, then publish them to my web player.


Top
 Profile  
 
 Post subject:
PostPosted: 2017-11-16, 23:50:35 

Contributors Contributors
Offline
User avatar

Joined: 2015-02-22, 3:40:22
Posts: 97
Quote:
If you mean what's its purpose, I already said it's a desktop app version of my web player, complete with cores written directly in JS rather than compiled from VGMPlay using Emscripten.


Oh, nice work! When you have binaries I’ll definitely try it out.


Top
 Profile  
 
 Post subject:
PostPosted: 2017-11-17, 9:05:09 

Staff Staff
Programmers Programmers
Offline
User avatar

Joined: 2012-04-22, 4:03:45
Posts: 207
Location: New York, NY, USA
Update: HuC6280 (PC-Engine/Turbografx-16) playback is restored! Now this version of the player officially surpasses the capabilities of the web version.


Top
 Profile  
 
 Post subject:
PostPosted: 2017-11-17, 12:57:50 

Staff Staff
Programmers Programmers
Contributors Contributors
Ball Fondlers Ball Fondlers
Offline
User avatar

Joined: 2014-01-28, 5:51:54
Posts: 518
We need an actual web player on the site. Currently the pre-rendered mp3s take up 100GB and I'd like to eliminate that. Someone needs to maintain an emscripten version of vgmplay and fix bugs as they come along.

I don't know what the point of a JS player is. In order to be more convincing, you'd need to benchmark your VGM player and compare it to an emscripten version of vgmplay and see the difference in performance, filesize, accuracy and so on and so forth. In your JS player you also have to implement data block decompression, streams, error handling and who knows what else, besides emulating all the 30+ chips. But the biggest benchmark is that vgmplay exists and works 100% and your JS player is quite behind it. And when new features and chips will be added to vgmplay/libvgm, you'll have to re-translate them into JS, and you'd have to keep up with all the commits. Whereas if you just create a set of build scripts for emscripten, those would be a lot lower maintenance and a lot more useful.

I also remember when someone managed to make a web version of vgmplay, the one I used for project2612. The problem with that is that the guy didn't hang out on the site and we don't know how available he is for bugfixes.

Also, what's the point of using a JS player on the desktop when you already have vgmplay?

If you think a native JS version of, say, one sound chip, would exceed an emscripten compiled version, then perhaps we can make a sort of hybrid build where the JS chip is used alongside all the other chips, which aren't translated to JS yet. Perhaps make the VGM file player core (reading the VGM commands, GD3, header, decompression, streams, error handling) in JS, then import the chips code with emscripten, with the exception of the chips that are translated to JS and give better performance.

To benchmark your code you'd need to do some exaggerated comparisons, such as: creating 100 instances of the chip and measuring memory leakage and CPU time. Running each version of the chip code with the same VGM file for an hour (in rendering time, not CPU time), and measuring the CPU time of each version.

But anyway, for the site we just need a working JS version of vgmplay, and we need it to work, even if it is a bit big or slow.


Top
 Profile  
 
 Post subject:
PostPosted: 2017-11-17, 15:17:45 
Offline

Joined: 2017-07-17, 23:28:35
Posts: 21
Maybe you mean this one? https://www.wothke.ch/webvgm/

On recent Chrome versions this doesn't run as good as it used too. But it ate one core of my CPU completely, now, and with older Chrome versions it was 80% as well. I hope this is a bug or my I5 750 which is getting pretty old, and not the performance loss you get by using Emscripten. Some things converted get the same speed, others will get a huge loss. I think people won't use the webplayer that much if it would eat their core and the fans will start making noise.

Another approach would be to generate the mp3 data live on the server and stream it to the user. Plenty of time for generation considering playback speed. And keep the most played packs in mp3. Of course I have no idea what load it would mean on the particular CPUs in the server(s)....


Top
 Profile  
 
 Post subject:
PostPosted: 2017-11-17, 16:37:05 

Staff Staff
Programmers Programmers
Contributors Contributors
Ball Fondlers Ball Fondlers
Offline
User avatar

Joined: 2014-01-28, 5:51:54
Posts: 518
niekniek wrote:
Maybe you mean this one? https://www.wothke.ch/webvgm/

On recent Chrome versions this doesn't run as good as it used too. But it ate one core of my CPU completely, now, and with older Chrome versions it was 80% as well. I hope this is a bug or my I5 750 which is getting pretty old, and not the performance loss you get by using Emscripten. Some things converted get the same speed, others will get a huge loss. I think people won't use the webplayer that much if it would eat their core and the fans will start making noise.

Another approach would be to generate the mp3 data live on the server and stream it to the user. Plenty of time for generation considering playback speed. And keep the most played packs in mp3. Of course I have no idea what load it would mean on the particular CPUs in the server(s)....


Yes, wothke's VGM player is what is used on Project2612.

The performance issue is why we need someone to maintain it and optimize it all the time.

We're already using mp3's generated on the server, that's why it's taking up 100GB currently.


Top
 Profile  
 
 Post subject:
PostPosted: 2017-11-17, 19:18:35 

Contributors Contributors
Staff Staff
Offline
User avatar

Joined: 2013-07-17, 23:32:39
Posts: 222
Doubt you'd be able to make a VGM player with emscripten/asmjs that will work well on mobile devices. Maybe webassembly now that it's been "approved".


Top
 Profile  
 
 Post subject:
PostPosted: 2017-11-17, 20:18:20 
Offline

Joined: 2017-07-17, 23:28:35
Posts: 21
vampirefrog wrote:
niekniek wrote:
Another approach would be to generate the mp3 data live on the server and stream it to the user. Plenty of time for generation considering playback speed. And keep the most played packs in mp3. Of course I have no idea what load it would mean on the particular CPUs in the server(s)....


We're already using mp3's generated on the server, that's why it's taking up 100GB currently.


You don't get my point, what I mean is generate the MP3 files on demand, so only the VGM files are hosted. Less diskspace required, more CPU power. As I said, no idea if this is feasible...


Top
 Profile  
 
 Post subject:
PostPosted: 2017-11-18, 0:59:54 

Staff Staff
Programmers Programmers
Contributors Contributors
Ball Fondlers Ball Fondlers
Offline
User avatar

Joined: 2014-01-28, 5:51:54
Posts: 518
ctr wrote:
Doubt you'd be able to make a VGM player with emscripten/asmjs that will work well on mobile devices. Maybe webassembly now that it's been "approved".


Oh ye of little faith.


Top
 Profile  
 
 Post subject:
PostPosted: 2017-11-18, 1:06:41 

Staff Staff
Programmers Programmers
Contributors Contributors
Ball Fondlers Ball Fondlers
Offline
User avatar

Joined: 2014-01-28, 5:51:54
Posts: 518
niekniek wrote:
vampirefrog wrote:
niekniek wrote:
Another approach would be to generate the mp3 data live on the server and stream it to the user. Plenty of time for generation considering playback speed. And keep the most played packs in mp3. Of course I have no idea what load it would mean on the particular CPUs in the server(s)....


We're already using mp3's generated on the server, that's why it's taking up 100GB currently.


You don't get my point, what I mean is generate the MP3 files on demand, so only the VGM files are hosted. Less diskspace required, more CPU power. As I said, no idea if this is feasible...


It's a shared server so no.


Top
 Profile  
 
 Post subject:
PostPosted: 2017-11-18, 12:25:31 

Musicians Musicians
Contributors Contributors
Offline

Joined: 2012-09-29, 11:45:48
Posts: 212
Location: Australia
niekniek wrote:
Another approach would be to generate the mp3 data live on the server and stream it to the user.


Actually I would prefer audio data to be generated on the user's machine instead. Whether in real-time or in-memory. vgm2wav then play the result (enjoy doing that with long songs unless someone does a vgm2ogg :P)

_________________
-dj.tuBIG/MaliceX


Top
 Profile  
 
 Post subject:
PostPosted: 2017-11-18, 14:01:04 

Staff Staff
Programmers Programmers
Contributors Contributors
Ball Fondlers Ball Fondlers
Offline
User avatar

Joined: 2014-01-28, 5:51:54
Posts: 518
Real-time is the way to go. I believe the most CPU time is taken by more complex chips, such as the FM stuff. Perhaps the real challenge is optimizing the YM chips for JS.

Also, for anyone wondering how memory allocation and garbage collection comes into all this, basically Emscripten allocates a big Uint8Array at the start, which is the Heap, and that remains allocated all the time (until you reload the page). The JS allocator or garbage collector is never used. It is possible to avoid it entirely by this method. It probably has its own allocation code which manages the heap. That is why it has good performance, because it managed to bypass the GC. Either way, the less you use the 'new' operator in JS the better. This is why I said we need actual benchmarks for this. Emscripten code could be even faster than porting the code to JS. I would suggest comparing the existing JS cores that neologix has collected to their emscripten compiled versions by having them render the exact same data. It is also possible to do profiling with Chrome (F12 -> Performance), and you can actually see the GC working.


Top
 Profile  
 
 Post subject:
PostPosted: 2017-11-18, 22:10:15 

Contributors Contributors
Offline
User avatar

Joined: 2015-02-22, 3:40:22
Posts: 97
vampirefrog wrote:
Also, what's the point of using a JS player on the desktop when you already have vgmplay?


Hmm, cross-platform player with a nice Electron UI, media library and album art, or a command line player which I need to compile manually… I know which I’d pick ;).

Telling a friend who’s on MacOS and not so computer savvy to listen to VGMs right now kind of amounts to a no-go, basically.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group