After coming back from my somewhat extended linux.conf.au trip I spent the whole day grepping through email. Only 263 unprocessed emails left in my inbox. Yay.
PRTPILU
Thanks to the LCA guys, video footage is now available of all talks, including my talk Practical Real-Time Programming in Linux Userspace (Theora, Slides). In my endless modesty I have to recommend: go, watch it, it contains some really good stuff (including me not being able to divide 1 by 1000). Right now, the real-time features of the Linux kernel are seldomly used on the desktop due to a couple of reasons, among them general difficulty and unsafety to use them but predominantly it's probably just unawareness. There are a couple of situations however, where scheduling desktop processes as RT makes a lot of sense (think of video playback, mouse curse feedback, etc.), to decouple the execution (scheduling) latency from the system load. This talk focussed mostly on non-trivial technical stuff and all the limitations RT on Linux still has. To fully grok what's going on you thus need some insight into concurrent programming and stuff.
My plan is to submit a related talk to GUADEC wich will focus more on actually building RT apps for the desktop, in the hope we will eventually be able to ship a desktop with audio and video that never skips, and where user feedback is still snappy and quick even if we do the most complicated IO intensive processing in lots of different processes in the background on slow hardware.
I didn't have time to go through all my slides (which I intended that way and is perfectly OK), so you might want to browse through my slides even if you saw the whole clip. The slides, however, are not particularly verbose.
Rumors
Regarding all those rumors that have been spread while I -- the maintainer of PulseAudio -- was in the middle of the australian outback, fist-fighting with kangaroos near Uluru: I am not really asking anyone to port their apps to the native PulseAudio API right now. While I do think the API is quite powerful and not redundant, I also acknowledge that it is very difficult to use properly (and very easy to misuse), (mostly) due to its fully asynchronous nature. The mysterious libsydney project is supposed to fix this and a lot more. libsydney is mostly the Dukem Nukem Forever of audio APIs right now, but in contrast to DNF I didn't really announce it publicly yet, so it doesn't really count. ;-) Suffice to say, the current situation of audio APIs is a big big mess. We are working on cleaning it up. For now: stick to the well established and least-broken APIs, which boils down to ALSA. Stop using the OSS API now! Don't program against the ESD API (except for event sounds). But, most importantly: please stop misusing the existing APIs. I am doing my best to allow all current APIs to run without hassles on top of PA, but due to the sometimes blatant misues, or even brutal violations of those APIs it is very hard to get that working for all applications (yes, that means you, Adobe, and you, Skype). Don't expect that mmap is available on all audio devices -- it's not, and especially not on PA. Don't use /proc/asound/pcm as an API for enumerating audio devices. It's totally unsuitable for that. Don't hard code device strings. Use default as device string. Don't make assumptions that are not and cannot be true for non-hardware devices. Don't fiddle around with period settings unless you fully grok them and know what you are doing. In short: be a better citizen, write code you don't need to be ashamed of. ALSA has its limitations and my compatibility code certainly as well, but this is not an excuse for working around them by writing code that makes little children cry. If you have a good ALSA backend for your program than this will not only fix your issues with PA, but also with Bluetooth, you will have less code to maintain and also code that is much easier to maintain.
Or even shorter: Fix. Your. Broken. ALSA. Client. Code. Thank you.
Oh, if you have questions regarding PA, just ping me on IRC (if I am around) or write me an email, like everyone else. Mysterious, blogged pseudo invitations to rumored meetings is not the best way to contact me.