{"id":3381,"date":"2011-05-31T07:02:15","date_gmt":"2011-05-31T14:02:15","guid":{"rendered":"http:\/\/multimedia.cx\/eggs\/?p=3381"},"modified":"2011-12-29T10:01:45","modified_gmt":"2011-12-29T18:01:45","slug":"salty-game-music","status":"publish","type":"post","link":"https:\/\/multimedia.cx\/eggs\/salty-game-music\/","title":{"rendered":"Salty Game Music"},"content":{"rendered":"

Have you heard of Google’s Native Client (NaCl) project<\/a>? Probably not. Basically, it allows native code modules to run inside a browser (where ‘browser’ is defined pretty narrowly as ‘Google Chrome’ in this case). Programs are sandboxed so they aren’t a security menace (or so the whitepapers claim) but are allowed to access a variety of APIs including video and audio. The latter API is significant because sound tends to be forgotten in all the hullabaloo surrounding non-Flash web technologies. At any rate, enjoy NaCl while you can because I suspect it won’t be around much longer.<\/p>\n

After my recent work upgrading some old music synthesis programs<\/a> to use more modern audio APIs, I got the idea to try porting the same code to run under NaCl in Chrome (first Nosefart, then Game Music Emu\/GME). In this exercise, I met with very limited success. This blog post documents some of the pitfalls in my excursion.<\/p>\n


\n\"\"
\n<\/center><\/p>\n

Infrastructure<\/strong>
\nPeople who know me know that I’m rather partial — to put it gently — to straight-up C vs. C++. The NaCl SDK is heavily skewed towards C++. However, it does provide a Python tool called init_project.py which can create the skeleton of a project and can do so in C with the '-c'<\/code> option:<\/p>\n

\r\n.\/init_project.py -c -n saltynosefart\r\n<\/pre>\n
This generates something that can be built using a simple ‘make’. When I added Nosefart’s C files, I learned that the project Makefile has places for project-necessary CFLAGS but does not honor them. The problem is that the generated Makefile includes a broader system Makefile that overrides the CFLAGS in the project Makefile. Going into the system Makefile and changing \"CFLAGS =\"<\/code> -> \"CFLAGS +=\"<\/code> solves this problem.<\/p>\n
Still, maybe I’m the first person to attempt building something in Native Client so I’m the first person to notice this?<\/p>\n
Basic Playback<\/strong>
\nAt least the process to create an audio-enabled NaCl app is well-documented.<\/a> Too bad it doesn’t seem to compile as advertised. According to my notes on the matter, I filled in PPP_InitializeModule()<\/code> with the appropriate boilerplate as outlined in the docs but got a linker error concerning get_browser_interface().<\/p>\n
Plan B: C++<\/strong>
\nObviously, the straight C stuff is very much a second-class citizen in this NaCl setup. Fortunately, there is already that fully functional tone generator example program in the limited samples suite. Plan B is to copy that project and edit it until it accepts Nosefart\/GME audio instead of a sine wave.<\/p>\n
The build system assumes all C++ files should have .cc extensions. I have to make some fixes so that it will accept .cpp files (either that, or rename all .cpp to .cc, but that’s not very clean).<\/p>\n
Making Noise<\/strong>
\nYou’ll be happy to know that I did successfully swap out the tone generator for either Nosefart or GME. Nosefart has a slightly fickle API that requires revving the emulator frame by frame and generating a certain number of audio samples. GME’s API is much easier to work with in this situation — just tell it how many samples it needs to generate and give it a pointer to a buffer. I played NES and SNES music play through this ad-hoc browser plugin, and I’m confident all the other supported formats would have worked if I went through the bother of converting the music data files into C headers to be included in the NaCl executable binaries (dynamically loading data via the network promised to be a far more challenging prospect reserved for phase 3 of the project).<\/p>\n
Portable?<\/strong>
\nI wouldn’t say so. I developed it on Linux and things ran fine there. I tried to run the same binaries on the Windows version of Chrome to no avail. It looks like it wasn’t even loading the .nexe files (NaCl executables).<\/p>\n
Thinking About The (Lack Of A) Future<\/strong>
\nAs I was working on this project, I noticed that the online NaCl documentation materialized explicit banners warning that my NaCl binaries compiled for Chrome 11 won’t work for Chrome 12 and that I need to code to the newly-released 0.3 SDK version. Not a fuzzy feeling. I also don’t feel good that I’m working from examples using bleeding edge APIs that feature deprecation as part of their naming convention, e.g., pp::deprecated::ScriptableObject().<\/p>\n
Ever-changing API +<\/strong> minimal API documentation + API that only works in one browser brand +<\/strong> requiring end user to explicitly enable feature = … well, that’s why I didn’t bother to release any showcase pertaining to this little experiment. Would have been neat, but I strongly suspect that this is yet another one of those APIs that Google decides to deprecate<\/a> soon.<\/p>\n
See Also:<\/strong><\/p>\n