On the features front, Kai Elwert has done a lot of work since July to implement missing features at the DAAP and DACP level to get better support for Remote:

• playlists can now be played from Remote;
• listings are sorted in a way that’s closer to what you get from iTunes;
• sort headers are now generated when requested so Remote can display the A-Z quick access list.

Also, forked-daapd can now remember which speakers were selected before shutdown and attempts to automatically reselect these speakers the next time around. Speakers that were selected will be reselected if they appear at most 5 minutes after startup and the player isn’t running at that time.

On the Squeeze front, a viable snapshot of forked-daapd will release with Squeeze. This snapshot doesn’t have all the Remote improvements listed above, although it’s got the playlist support, can remember the speaker selection and includes bug fixes.

My plan is to provide backports through backports.org once Squeeze is released and for as long as possible after that.

There’s always more in the works, so stay tuned =)

libdispatch is the userspace component of Apple’s Grand Central Dispatch technology, designed to help write applications that really take advantage of multicore processors without having to fiddle directly with threads and locking (and getting it terribly wrong).

To get that working on Linux, Mark wrote a userspace implementation of the pthread workqueues and a kqueue compatibility library (libkqueue). He also packaged the Blocks runtime (libblocksruntime) for Debian so as to build libdispatch with Blocks support. That means code using libdispatch must be built with CLang (or llvm-gcc-4.2) rather than gcc, as getting Blocks support in gcc in the near future looks highly improbable.

On Mac OS X and FreeBSD, a kernel-based implementation of the pthread workqueues is used; we don’t have that for Linux yet. The all-userspace implementation we have at the moment works really well; there are some caveats, though, but that’s no reason for not starting to play with libdispatch right now!

Try it out, it’s great. Thanks again, Mark!

I have also uploaded the ANTLR v3 C runtime (aka libantlr3c) to unstable. It’s currently blocked from migrating to testing, until antlr3 is ready to migrate.

Hopefully, the issues affecting antlr3 3.2 in unstable will be resolved soonish and all of this will migrate to testing and be part of Squeeze.

AirTunes v2 UDP streaming

forked-daapd can now do streaming to multiple AirTunes devices (as well as the local soundcard) and can be controlled from Remote (and, ideally, from anything that speaks DACP).

I’m releasing this early while the paint is still wet and not everything works on the DACP-side of things. Case in point, while playing a song or an album is supported, playing a playlist isn’t. There’s some work needed on this particular feature, and it’ll get there eventually.

There have been a couple of other changes in the codebase in recent weeks too; details after the jump.

Implementing AirTunes v2 has been quite fun and, in addition to releasing the forked-daapd code today, I’ve also taken the time to write down my findings about the protocol so others can experiment with it. This documentation is by no means exhaustive nor complete as far as the protocol goes; if you find out anything I haven’t, let me know so I can update this document.

Let’s review the recent changes in the forked-daapd codebase over the past few weeks.

AirTunes v2

You can now use Remote from your iSomething together with your AirTunes devices and forked-daapd to listen to your library. As mentioned above, playing a playlist is not supported; I have a few things to sort out before this can work and I suspect this will bring changes not only to the DACP interface but also to other parts of the code. So, stay tuned.

forked-daapd supports synchronized playback to multiple AirTunes devices together with the local soundcard if so desired. You can expect the AirTunes devices to be in sync with each other, but the soundcard will usually run in circles around them. It looks like AirTunes plays sound a bit slower than 44.1 kHz; not a big deal, though, as AirTunes will catch up periodically and the desync, while it can be noticeable, isn’t big (ie we’re not talking seconds, not even one full second).

Make sure your network can handle the load, as streaming to a single AirTunes device requires in excess of 1.6 Mbps (1.8 Mbps is actually closer to the real thing).

Local audio output is supported via ALSA and OSS4, although note that the OSS4 code hasn’t been very well tested. I intend to test and debug it fully at a later date, but feel free to beat me to it and send patches.

Also note that, while there is code for FreeBSD in the player/streaming part of forked-daapd, it doesn’t work well at all. The streaming code needs a timer with a higher resolution than kqueue/kevent has to offer, and I haven’t found anything as capable as timerfd. So it’s there, but it’s broken. Read on about FreeBSD support.

Metadata scanning

Several fixes and enhancements have been made to the filescanner so it picks more and better metadata. Format-specific tagnames have been added to work around ffmpeg’s limitations. Using a recent enough ffmpeg version (anything after mid-december 2009) will work best, especially for MP3 files.

SQLite concurrency fixes

The database code has been reworked to handle concurrency on the database. Issues with locked tables (or the whole database) were noticed pretty easily with big libraries when accessing forked-daapd during the library update after startup. On uniprocessor machines, this was even easier to hit.

This, however, comes with new requirements for SQLite3: you’ll now need SQLite3 v3.5.0 at least and it must be built with the unlock notify API enabled. Not all distributions ship SQLite3 with the unlock notify API enabled, so you may need to do a rebuild. Debian, for instance, doesn’t; this is #579266.

A word about FreeBSD support

I’m giving up on FreeBSD support. The streaming code doesn’t work on FreeBSD due to timer issues, and I don’t intend to fix it. I also don’t intend to invest much time in porting future features to FreeBSD; if I can make it work, then fine, otherwise, too bad.

Someone needs to step up if there’s interest in having forked-daapd work on FreeBSD.

And the results weren’t good: some images couldn’t be loaded, and it all seemed to be random.

Disabling optimization in both GNU EFI and rEFIt for the x64 builds helped somewhat, at least it made rEFIt reliable enough to be usable.

Now, with this new release, I started getting error messages, requiring a key press before the menu would be displayed. It’s annoying but it’s also very helpful as I now had an error message to work with, and even if the error message wasn’t reliable, it would still point me to some part of the code. The message was: Invalid argument.

On x64, the use of a call wrapper is mandatory because the EFI x64 calling convention doesn’t match the calling convention of the ELF executables we’re building and later disguising as EFI executables. The call wrapper has always been the prime suspect in this issue, it’d be an obvious candidate for anyone looking at this issue.

Today, digging into the issue with some new data, I realized what the problem was: when using the call wrapper, all arguments need to be of the UINT64 type. That’s the type the call wrapper uses when extracting the arguments from its va_list.

Introduce some more macros on top of the call wrapper, build, test: voila, it’s fixed! That was tricky one.

Let’s sum it up for the search engines: all the arguments to the EFI interface called through uefi_call_wrapper() in GNU EFI need to be cast to UINT64.

rEFIt 0.14-1, available in unstable in a couple hours.

Next, I’ll see if I can reenable optimization in both GNU EFI and rEFIt.

I’ve just realized that I did not post an announce for pommed v1.31 a while back, which was also a maintenance release, adding support for the MacBookPro5,4 (15″ June 2009) and the latest wireless keyboard.

The old key ID is F5D65169, the new key ID is FA1E5292; it’s available from the keyservers or my website.

I have put up a transition document, signed with both keys; if you’ve signed my old key, grab it, verify it and if all is OK on your end, please sign the new key.

You’ll notice that one of the old UIDs did not make it to the new key; that’s because I’m not using that email address and don’t actually intend to use it in the future.

Thanks!

At this point, there won’t be much visible activity on forked-daapd for some time. I’m working on a couple of things, but they take time and they require a lot of new code.

So, for a couple weeks now, I’ve been working on that. I have some code outside forked-daapd that is starting to work well, but it’s not there yet, far from it. Then it’ll have to be integrated into forked-daapd, which means a lot of new code there too.

Bug fixes will still happen in the meantime, and some smaller new features may also appear before the Big Thing™. So if you find or encounter bugs, feel free to report them still. If you have patches or ideas you want to discuss, feel free too.

As I wrote to a couple people by mail already, good things come to those who wait or contribute.

With all that, I’ve updated the Debian packages, given that there won’t be important changes for a while; I hope they’re useful to some of you out there. Note that I’m making an amd64 binary package available alongside the source package; it’s built on a current Debian unstable system, but if that’s not suitable for you, in terms of dependencies or architecture, you can trivially build a suitable binary package from the source package. As a reminder, I have packages of the ANTLRv3 C runtime too. I’ve also added antlr-3.1.3.jar there, in case you need it and can’t find it at the upstream download site.

It’s been a fun ten years, with ups and downs, and I’m looking forward to what’s coming next.

The filescanner for forked-daapd on FreeBSD is now up to par with its Linux counterpart, as much as possible. Contrary to the latter, it will lose some metadata (play count, for instance) when files get moved around, because it’s not possible to track moves and renames accurately. It also performs more rescans than the Linux/inotify implementation. Still, it works just as good.

On a related note, the machine I tried to install FreeBSD 8.0 on and finally ended up installing GNU/kFreeBSD on just seemingly committed suicide. I’m not sure what message it’s trying to send me. It’s previously been my main workstation for the best part of 10 years, so this is a bit sad.

At least I found some bugs in the process and fixed some too:

• 2 bugs in forked-daapd, one of them a crasher,
• a bug in Avahi on kFreeBSD,
• a bug in GRUB2 as used on the kFreeBSD daily d-i images.

Not bad, is it?