I’ve been working on a project that uses GStreamer to play back audio files in an automatically-determined order. My implementation uses a playbin, which is nice and easy to use. I had some issues getting it to continue playback on reaching the end of a file, though.
According to the documentation for the about-to-finish signal,
This signal is emitted when the current uri is about to finish. You can set the uri and suburi to make sure that playback continues.
This signal is emitted from the context of a GStreamer streaming thread.
Because I wanted to avoid blocking a streaming thread under the theory that doing so might interrupt playback (the logic in determining what to play next hits external resources so may take some time), my program simply forwarded that message out to be handled in the application’s main thread by posting a message to the pipeline’s bus.
Now, this approach appeared to work, except it didn’t start playing the next URI, and the pipeline never changed state- it was simply wedged. Turns out that you must assign to the uri property from the same thread, otherwise it doesn’t do anything.
Fortunately, it turns out that blocking that streaming thread while waiting for data isn’t an issue (determined by experiment by simply blocking the thread for a while before setting the uri.
Because I had quite the time finding it when I wanted to submit a patch to newlib, there’s a git mirror of the canonical CVS repository for newlib, which all the patches I saw on the mailing list were based off of. Maybe somebody else looking for it will find this note useful:
I updated the site’s SSL certificate to no longer be self-signed. This means that if you use the site over HTTPS, you won’t need to manually accept the certificate, since it is now signed by StartSSL. If you’re interested in doing similar, Ars Technica have a decent walk through the process (though they target nginx for configuration, which may not be useful to those running other web servers).
For convenience, you can follow this link to switch to the HTTPS site.
Somebody had asked me about the schematics for my divergence meter project. All the design files are in the mercurial repository on Bitbucket, but here’s a high-resolution capture of the schematic for those unable or unwilling to use Eagle to view the schematic: dm-rev1.1.png. Be advised that this version of the schematic does not reflect the current design, as I have not updated it with a FET driver per my last post on this project.
On the actual project front, I haven’t been able to test the FET driver bodge yet. Maybe next weekend..
I just enabled SSL on this site in a fit of paranoia. It shouldn’t cause any problems, but please let me know if you notice something that’s broken. Normal browsing shouldn’t be affected, but site login is forced to SSL. My (self-signed) certificate has SHA1 fingerprint 6c:e4:77:91:e8:59:f8:d1:fd:ea:cf:87:6b:af:ce:3b:19:be:fa:b5.
Working on mkg3a upgrades for libpng more, I was getting unusual crashes with the gnuwin32 libpng binaries (access violations when calling png_read_int()). It turned out that the libpng dll was built against an incompatible C runtime, so I had to build static libraries. With the official libpng source distribution (and zlib), building static libraries was reasonably easy. Using the MSVC make tool in the libpng source tree, I first had to build zlib. The default build (for some reason) doesn’t build the module containing _inflate_fast, so I had to add inffast.obj to the OBJS in zlib/win32/Makefile.msc (this manifested as an unexported symbol error when linking a program against zlib). Building it then was easy, using nmake in the Visual Studio toolkit:
zlib-1.2.5> nmake -f win32/Makefile.msc
With zlib built, copy zlib.h and zlib.lib out of the source directory and into wherever it will be used.
For libpng, we first have to modify the makefile, since the one included uses unusual options. Change CFLAGS to read CFLAGS=/nologo /MT /W3 -I..zlib for some sane options. The include path also needs to be updated to point to your zlib.h. In my case, that makes it -I..include. The rest of the procedure for building libpng is very similar to that for zlib:
lpng158> nmake -f scripts/Makefile.msc
Building against libpng then requires png.h, pngconf.h, pnglibconf.h and png.lib. To build against these libraries, I simply put the include files in an ‘include’ directory, the .lib files in a ‘lib’ directory, and pointed cmake at it.
Warnings about runtime libraries when linking a program against these static libraries is an indication that you’ll probably see random crashes, since it means theses static libraries are using a different version of the runtime libraries than the rest of your program. I was this problem manifested as random heap corruption. Changing CFLAGS (in the makefiles) to match your target configuration as set in Visual Studio and rebuilding these libraries will handle that problem.
I very rarely use the work ‘beautiful’, but in the case of this song, I think it’s apt. Kimi no shiranai monogatari by Supercell, the closing theme for Bakemonogatari (which is well worth watching in its own right, hosting some other catchymusic as well as having a unique visual style).
(Turn on captions and up the video quality for great justice)
A delicious sound, and I also like the allusion to Tanabata (in referring to the Summer Triangle). Taken in the context of Bakemonogatari, the power of the lyrics is only increased.