2015-12 Addendum: See SoundPusher for an update to (and new name for) this project.
As far as I’m aware there very few real-time 5.1 (Dolby Digital / AC-3) encoders for the Mac that integrate into the default CoreAudio HAL (and can thus be used by any application); I’ve only stumbled upon ac3jack, which builds on the multi-platform JACK Audio Connection Kit.
I thought it’d be interesting to learn something about CoreAudio and low-latency coding and thus decided to write such a system. Currently, this is split into 3 components:
- CoreAudio AudioCodec for transforming LPCM into encoded AC-3. I’m using libavcodec as the encoder for this.
- Audio driver presenting a virtual sound output to the system, and forwards that data as a provided sound input. The idea is to select the virtual output as default / system output, and then encode from the virtual input into the compressed format and forward that to a physical optical output.
In 10.8 “Mountain Lion” you can write these sorts of plug-ins as sandboxed user-space components, which is quite neat (but not well documented at the moment).
- A normal application / menu extra that takes raw sound from the virtual sound input, passes that to the AC-3 audio encoder, and then forwards the resulting stream to a physical digital output port.
The encoder seems to work; I’m currently working on the driver and then comes the user-space connector / configuration application.
Fun times! 😀
As MacPorts is rather unhappy with Xcode 4.3 (understandably, with all those changed paths), I invested a fair amount of effort to get it recompile rTorrent (which I’d been running in a screen-session on my Mac mini). I got it work (xcode-select + setting the Developer-folder in /opt/local/etc/macports.conf to either “/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain” or “/”), but while searching around, I also came across Transmission‘s headless daemon and web-interface.
So, here’s how I built and configured the headless daemon on OS X (with Xcode 4.3):
- Get the source-package, e.g. transmission-2.50.tar.bz2
- Copy the source of libevent2 into “third-party/libevent” (“mv ../libevent-2.0.17-stable third-party/libevent” inside the Transmission-directory).
- Build via “xcodebuild -project Transmission.xcodeproj -target transmission-daemon -configuration Release”.
- Run the daemon so it creates its initial config in “~/Library/Application Support/transmission-daemon”.
- Edit the configuration in settings.json (whitelist, watchdir, ports, speeds, …).
- If you want to use the web-interface, copy its files: “cp -R web ~/Library/Application Support/transmission-daemon/”
- Re-start the daemon.
This worked well for me and I’m quite impressed with both the web-interface and Transmission itself.
Here’s an update to WowPlot that supports Patch 4.2 Combat Logs with extended actor flags.
A further update with Lion-specific features (fullscreen, auto-saving, …) is in the works as well.
No longer includes
No longer includes
Binaries compiled as universal x86_64 and i386 (no more ppc)
I had some itching coding fingers again and thus added support for the new World of Warcraft Patch 4.0.1 changes to WowPlot. As usual, the direct download is here and the source is over at bitbucket.
If a log from 4.0.1 causes trouble, get in touch.
I finally got around to a) updating my old WordPress-installation (after finding out spam-bots had already created custom folders on my installation) and b) uploading all my public code to bitbucket (as Mercurial repositories).
That includes my wavelet image compression library, its Mac OS X previewing GUI as well as WowPlot (including some fairly decent Objective-C WoWCombatLog.txt parsing). I converted most of those repositories from darcs (which in the case of my wavelet lib took about 3h to convert from darcs1 to darcs2 format), but on first glance they look alright.
While solid-state drives (SSDs) seem to be all the rage in net-/laptops at the moment, most of their advantages (mostly negligible access times) also make sense for a desktop system, whereas their disadvantages (price / small size) are not as constricting as you can have multiple physical discs in a desktop system.
I’ve bought a 64GB SLC SSD drive in a 3.5″ SATA version for my Mac Pro and use it solely as an OS and applications drive, while my home-directory (where the bulk of my data obviously sits) is still on a normal, spacious hard-drive. The speed-up (in spite of Mac OS X’s already quite fast boot / application start-up times) is very noticeable.
The OS migration from the HDD to the SDD was very painless. I used Carbon Copy Cloner to copy everything but my username’s home directory, rebooted from the SSD, logged in as the user with administration privileges (which your everyday user account shouldn’t have) and changed the home-directory for my non-admin user (under System Preferences – Accounts – Right-Click on the account – Advanced Options – Home Directory).
Almost all applications (baring Xcode) cold-start approximately half-way through the first Dock-icon bounce and World of Warcraft flies with this setup. 🙂
If I didn’t need more than 64GB total space on my MacBook Pro, I’d also fit it with such an SSD drive without hesitation. But as it is, I need more space. Alas, when the next laptop is on the horizon I can definitely see myself shelling out for an SSD upgrade. Maybe mainboards should come with something like 64GB of on-board flash for use as operating system and application drive…