レナート   I'll Break Your Audio   ﻟﻴﻨﺎﺭﺕ

Fri, 13 Nov 2009

On OOM

Building on what Havoc wrote two years ago about the fallacies of OOM safety (Out Of Memory) in user code I'd like to point you to this little mail I just posted to jack-devel which tries to give you the bigger picture. Should be interesting for non-audio folks, too.

Say NO to OOM safety!

posted at: 02:25 | path: /projects | permanent link to this entry | 10 comments

Fri, 06 Nov 2009

Public Service Announcement

Folks! Since quite some time now the kernel exports the DMI machine information below /sys/class/dmi/id/. You may stop now parsing the output of dmidecode thus depending on external tools and privileged code.

For example, to read your BIOS vendor string all you need to do is this:

$ read bv < /sys/class/dmi/id/bios_vendor
$ echo $bv

Which is of course much simpler, and cleaner, and safer than anything involving dmidecode.

Thank you for your time!

posted at: 11:14 | path: /projects | permanent link to this entry | 4 comments

Mon, 19 Oct 2009

Ubuntu doesn't get it

<rant>

So in the past Ubuntu packaged PA in a way that, let's say, was not exactly optimal. I thought they'd gotten around fixing things since then. Turns out they didn't. Seems in their upcoming release they again did some genius thing to make PA on Ubuntu perform worse than it could. The Ubuntu kernel contains all kind of closed-source and other crap to no limits, but backporting a tiny patch that is blessed and merged upstream and in Fedora for ages, that they won't do. Gah.

And it doesn't stop there. This patch is an outright insult. This is disappointing.

Madness. Not good, Ubuntu, really not good! And I'll get all the complaints for this f**up again. Thanks!

/me is disappointed. Ubuntu, you really can do better than this.

</rant>

posted at: 03:13 | path: /projects | permanent link to this entry | 0 comments

Sun, 18 Oct 2009

The Times They Are A-Changin'

Kinda fun watching this video. As it seems the big new features of the Windows 7 audio stack are the ability to move streams while they are live, to do role-based policy routing, and to pause streams during phone calls. Hah! That's so yesterday! A certain sound server I happen to know very well has been supporting this for a longer time already, and you can even buy that logic in various consumer products.

Nice to know that in some areas of the audio stack it's not us who need to play catch-up with them, but they are the ones who need to play catch-up with us.

posted at: 19:33 | path: /projects | permanent link to this entry | 0 comments

Sat, 10 Oct 2009

In The Press II

CIO has an interview with me.

posted at: 16:38 | path: /projects | permanent link to this entry | 0 comments

Wed, 07 Oct 2009

In The Press

LWN covers Paul's and my talk at the Audio MC at LPC, Portland. (Subscribers only for now)

Update: Here's a free subscriber link.

posted at: 20:29 | path: /projects | permanent link to this entry | 1 comments

LPC Audio BoF Notes

Here are some very short notes from the Audio BoF at the Linux Plumbers Conference in Portland two weeks ago. Sorry for the delay!

Biggest issue discussed was audio routing. On embedded devices this gets more complex each day, and there are a lot of open questions on the desktop, too. Different DSP scenarios; how do mixer controls match up with PCM streams and jack sensing? How do we determine which volume control sliders that are in the pipeline we are currently interested in? How does that relate to policy decisions? Format to store audio routing in?

The ALSA scenario subsystem currently being worked on by Liam Girdwood and the folks at SlimLogic and currently on its way to being integrated into ALSA proper hopefully helps us, so that we can strip a lot of complexity related to the routing logic from PulseAudio and move it into a lower level which naturally knows more about the hardware's internal routing.

Does it make sense for some apps to bypass the ALSA userspace layer and to talk to the kernel drivers via ioctl()s directly?i (i.e. thus not depending on ALSA's LISP intepreter, and a lot of other complexities)? Probably yes, but certainly not in the short term future. Salsa? libsydney?

Should the timing deviation estimation/interpolation be moved from PulseAudio into the kernel? Might be a good idea. Particularly interesting when we try to to monitor not only the system and audio clocks, but the video output and particularly the video input (i.e. video4linux) clocks, too. A unified kernel-based timing system has advantages in accuracy, allows better handling of (pseudo-) atomic timing snapshots, and would centralize timing handling not only between different applications (PA and JACK) but also between different subsystems. Problem: current timing stuff in PulseAudio might be a bit too homegrown for moving it 1:1 into the kernel. Also, depends on FP. Needs someone to push this. Apple does the clock handling in the kernel. How does this relate to ALSA's timer API?

Seems Ubuntu is going to kill OSS pretty soon too, following Fedora's lead. Yay!

And that's all I have. Should be the biggest points raised. Ping me if I forgot something.

posted at: 01:36 | path: /projects | permanent link to this entry | 2 comments

Tue, 06 Oct 2009

Latency Control

An often asked question is how to properly talk to PulseAudio from within applications where latency matters. To answer that question once and for all I've written this guide in our Wiki that should light things up a little. If you are interested in audio latency in PA, want to know how to minimize CPU usage and power consumption or how to maximize drop-out safety make sure to read this!

posted at: 20:49 | path: /projects | permanent link to this entry | 0 comments

Mon, 05 Oct 2009

Canonical,

one small note: requiring copyright assignment from contributors, and putting your code in exotic VCSes that only a minority of potential contributors know or are willing to use is not helpful for attracting contributions -- right the contrary, it scares them away. Please fix that!

posted at: 21:17 | path: /projects | permanent link to this entry | 0 comments

Fri, 02 Oct 2009

Conferences

Last week I've been at the Linux Plumbers Conference in Portland. Like last year it kicked ass and proved again being one of the most relevant Linux developer conferences (if not the most relevant one). I ran the Audio MC at the conference which was very well attended. The slides for our four talks in the track are available online. (My own slides are probably a bit too terse for most readers, the interesting stuff was in the talking, not the reading...) Personally, for me the most interesting part was to see to which degree Nokia actually adopted PulseAudio in the N900. While I was aware that Nokia was using it, I wasn't aware that their use is as comprehensive as it turned out it is. And the industry support from other companies is really impressive too. After the main track we had a BoF session, which notes I'll post a bit later. Many thanks to Paul, Jyri, Pierre for their great talks. Unfortunately, Palm, the only manufacturer who is actually already shipping a phone with PulseAudio didn't send anyone to the conference who wanted to talk about that. Let's hope they'll eventually learn that just throwing code over the wall is not how Open Source works. Maybe they'll send someone to next year's LPC in Boston, where I hope to be able to do the Audio MC again.

Right now I am at the BlueZ Summit in Stuttgart. Among other things we have been discussing how to improve Bluetooth Audio support in PulseAudio. I guess one could say thet the Bluetooth support in PulseAudio is already one of its highlights, in fact working better then the support on other OSes (yay, that's an area where Linux Audio really shines!). So up next is better support for allowing PA to receive A2DP audio, i.e. making PA act as if it was a Headset or your hifi. Use case: send music from from your mobile to your desktop's hifi speakers. (Actually this is already support in current BlueZ/PA versions, but not easily accessible). Also Bluetooth headsets tend to support AC3 or MP3 decoding natively these days so we should support that in PA too. Codec handling has been on the TODO list for PA for quite some time, for the SPDIF or HDMI cases, and Bluetooth Audio is another reason why we really should have that.

Next week I'll be at the Maemo Summit in Amsterdam. Nokia kindly invited me. Unfortunately I was a bit too late to get a proper talk accepted. That said, I am sure if enough folks are interested we could do a little ad-hoc BoF and find some place at the venue for it. If you have any questions regarding PA just talk to me. The N900 uses PulseAudio for all things audio so I am quite sure we'll have a lot to talk about.

See you in Amsterdam!

One last thing: Check out Colin's work to improve integration of PulseAudio and KDE!

posted at: 16:57 | path: /projects | permanent link to this entry | 4 comments

Thu, 24 Sep 2009

Plumbers 2009 Audio Bof Thu, 10:00 am

Tomorrow, Thu 24th 10 am, there's going to be an Audio BoF at LPC Portland, Salon E. Don't miss it.

posted at: 01:10 | path: /projects | permanent link to this entry | 1 comments

Tue, 22 Sep 2009

Skype

A quick update on Skype: the next Skype version will include native PulseAudio support. And not only that but they even tag their audio streams properly. This enables PulseAudio to do fancy stuff like automatically pausing your audio playback when you have a phone call. Good job!

In some ways they are now doing a better job with integration in to the modern audio landscape than some Free Software telephony applications!

Unfortunately they didn't fix the biggest bug though: it's still not Free Software!

posted at: 19:51 | path: /projects | permanent link to this entry | 8 comments

More Mutrace

Here's a list of quick updates on my mutrace mutex profiler since my initial announcement two weeks ago:

I added some special support for tracking down use of mutexes in realtime threads. It's a very simple extension that -- if enabled -- checks on each mutex operation wheter it is executed by a realtime thread or not. (--track-rt) The output of a test run of this you can find in this announcement on LAD. Particularly interesting is that you can use this to track down which mutexes are good candidates for priority inheritance.

The mutrace tarball now also includes a companion tool matrace that can be used to track down memory allocation operations in realtime threads. See the same lad announcement as above for example output of this tool.

With help from Boudewijn Rempt I added some compatibility code for profiling C++/Qt apps with mutrace, which he already used for some interesting profiling results on krita.

Finally, after my comments on the locking hotspots in glib's type system, Wim Taymans and Edward Hervey worked on turning the mutex-emulated rwlocks into OS native ones with quite positive results, for more information see this bug.

As soon as my review request is fully processed mutrace will be available in rawhide.

A snapshot tarball of mutrace you may find here (despite the name of the tarball that's just a snapshot, not the real release 0.1), for all those folks who are afraid of git, or don't have a current autoconf/automake/libtool installed.

Oh, and they named a unit after me.

posted at: 19:38 | path: /projects | permanent link to this entry | 1 comments

Tue, 15 Sep 2009

Measuring Lock Contention

When naively profiling multi-threaded applications the time spent waiting for mutexes is not necessarily visible in the generated output. However lock contention can have a big impact on the runtime behaviour of applications. On Linux valgrind's drd can be used to track down mutex contention. Unfortunately running applications under valgrind/drd slows them down massively, often having the effect of itself generating many of the contentions one is trying to track down. Also due to its slowness it is very time consuming work.

To improve the situation if have now written a mutex profiler called mutrace. In contrast to valgrind/drd it does not virtualize the CPU instruction set, making it a lot faster. In fact, the hooks mutrace relies on to profile mutex operations should only minimally influence application runtime. mutrace is not useful for finding synchronizations bugs, it is solely useful for profiling locks.

Now, enough of this introductionary blabla. Let's have a look on the data mutrace can generate for you. As an example we'll look at gedit as a bit of a prototypical Gnome application. Gtk+ and the other Gnome libraries are not really known for their heavy use of multi-threading, and the APIs are generally not thread-safe (for a good reason). However, internally subsytems such as gio do use threading quite extensibly. And as it turns out there are a few hotspots that can be discovered with mutrace:

$ LD_PRELOAD=/home/lennart/projects/mutrace/libmutrace.so gedit
mutrace: 0.1 sucessfully initialized.

gedit is now running and its mutex use is being profiled. For this example I have now opened a file with it, typed a few letters and then quit the program again without saving. As soon as gedit exits mutrace will print the profiling data it gathered to stderr. The full output you can see here. The most interesting part is at the end of the generated output, a breakdown of the most contended mutexes:

mutrace: 10 most contended mutexes:

 Mutex #   Locked  Changed    Cont. tot.Time[ms] avg.Time[ms] max.Time[ms]       Type
      35   368268      407      275      120,822        0,000        0,894     normal
       5   234645      100       21       86,855        0,000        0,494     normal
      26   177324       47        4       98,610        0,001        0,150     normal
      19    55758       53        2       23,931        0,000        0,092     normal
      53      106       73        1        0,769        0,007        0,160     normal
      25    15156       70        1        6,633        0,000        0,019     normal
       4      973       10        1        4,376        0,004        0,174     normal
      75       68       62        0        0,038        0,001        0,004     normal
       9     1663       52        0        1,068        0,001        0,412     normal
       3   136553       41        0       61,408        0,000        0,281     normal
     ...      ...      ...      ...          ...          ...          ...        ...

mutrace: Total runtime 9678,142 ms.

(Sorry, LC_NUMERIC was set to de_DE.UTF-8, so if you can't make sense of all the commas, think s/,/./g!)

For each mutex a line is printed. The 'Locked' column tells how often the mutex was locked during the entire runtime of about 10s. The 'Changed' column tells us how often the owning thread of the mutex changed. The 'Cont.' column tells us how often the lock was already taken when we tried to take it and we had to wait. The fifth column tell us for how long during the entire runtime the lock was locked, the sixth tells us the average lock time, and the seventh column tells us the longest time the lock was held. Finally, the last column tells us what kind of mutex this is (recursive, normal or otherwise).

The most contended lock in the example above is #35. 275 times during the runtime a thread had to wait until another thread released this mutex. All in all more then 120ms of the entire runtime (about 10s) were spent with this lock taken!

In the full output we can now look up which mutex #35 actually is:

Mutex #35 (0x0x7f48c7057d28) first referenced by:
	/home/lennart/projects/mutrace/libmutrace.so(pthread_mutex_lock+0x70) [0x7f48c97dc900]
	/lib64/libglib-2.0.so.0(g_static_rw_lock_writer_lock+0x6a) [0x7f48c674a03a]
	/lib64/libgobject-2.0.so.0(g_type_init_with_debug_flags+0x4b) [0x7f48c6e38ddb]
	/usr/lib64/libgdk-x11-2.0.so.0(gdk_pre_parse_libgtk_only+0x8c) [0x7f48c853171c]
	/usr/lib64/libgtk-x11-2.0.so.0(+0x14b31f) [0x7f48c891831f]
	/lib64/libglib-2.0.so.0(g_option_context_parse+0x90) [0x7f48c67308e0]
	/usr/lib64/libgtk-x11-2.0.so.0(gtk_parse_args+0xa1) [0x7f48c8918021]
	/usr/lib64/libgtk-x11-2.0.so.0(gtk_init_check+0x9) [0x7f48c8918079]
	/usr/lib64/libgtk-x11-2.0.so.0(gtk_init+0x9) [0x7f48c89180a9]
	/usr/bin/gedit(main+0x166) [0x427fc6]
	/lib64/libc.so.6(__libc_start_main+0xfd) [0x7f48c5b42b4d]
	/usr/bin/gedit() [0x4276c9]

As it appears in this Gtk+ program the rwlock type_rw_lock (defined in glib's gobject/gtype.c) is a hotspot. GLib's rwlocks are implemented on top of mutexes, so an obvious attempt in improving this could be to actually make them use the operating system's rwlock primitives.

If a mutex is used often but only ever by the same thread it cannot starve other threads. The 'Changed.' column lists how often a specific mutex changed the owning thread. If the number is high this means the risk of contention is also high. The 'Cont.' column tells you about contention that actually took place.

Due to the way mutrace works we cannot profile mutexes that are used internally in glibc, such as those used for synchronizing stdio and suchlike.

mutrace is implemented entirely in userspace. It uses all kinds of exotic GCC, glibc and kernel features, so you might have a hard time compiling and running it on anything but a very recent Linux distribution. I have tested it on Rawhide but it should work on slightly older distributions, too.

Make sure to build your application with -rdynamic to make the backtraces mutrace generates useful.

As of now, mutrace only profiles mutexes. Adding support for rwlocks should be easy to add though. Patches welcome.

The output mutrace generates can be influenced by various MUTRACE_xxx environment variables. See the sources for more information.

And now, please take mutrace and profile and speed up your application!

You may find the sources in my git repository.

posted at: 00:07 | path: /projects | permanent link to this entry | 26 comments

Mon, 10 Aug 2009

pthread_key_create() is dangerous

If you use pthread_key_create() with a non-NULL destructor parameter (or an equivalent TLS construct) in a library/shared object then you MUST link your library wth -z nodelete (or an equivalent construct).

If you don't, then you'll have a lot of fun (like I just had) debugging segfaults in the TLS destruction logic where functions are called that might not even exist anymore in memory.

Now don't tell me I hadn't told you.

(Oh, and I hope I don't need to mention that all GObject-based libraries should link with -z nodelete anyway, for making sure the type system doesn't break.)

posted at: 22:39 | path: /projects | permanent link to this entry | 7 comments

Sun, 09 Aug 2009

The Highest Man in Spain

Ever wanted to know what's the view like being the highest person in all of Spain? -- No? Hmm, can't help you then. -- Otherwise:

Pico del Teide

That's on the summit of Pico del Teide at 3718m, on Tenerife island. Unless you leave solid ground this is as high as you can get in Spain. 163m lower it's a bit more obvious that the Teide is a volcano:

Pico del Teide

And coming down to the surrounding caldera it's even more obvious:

Pico del Teide

Pico del Teide

Pico del Teide

On a ridge next to the caldera you find the Teide Observatory:

Teide Observatory

The caldera is covered in old lava flows:

Caldera

Caldera

Vulcanism has created various interesting rock formations in the caldera:

Roques

Roques

Tenerife is not just about the Teide and its dusty caldera. In the north of the island you find the Anaga mountain range:

Tenerife North

Neighboring Gran Canaria was where our little trip started and ended, right after the Gran Canaria Desktop Summit. Gran Canaria has no Teide but a very impressive landscape nonetheless:

Roque Nublo

That's the view from the Roque Nublo, the island's most famous landmark. The rock itself is visible here (on the left):

Roque Nublo

posted at: 22:22 | path: /photos | permanent link to this entry | 10 comments

Wed, 05 Aug 2009

Oh Nine Sixteen

As a followup to Oh Nine Fifteen here's a little overview of the changes coming with PulseAudio 0.9.16 which will be part of Fedora 12 (already in Rawhide; I think Ubuntu Karmic (?) will have it too).

A New Mixer Logic

We now try to control more than just a single ALSA mixer element for volume control. This increases the hardware volume range and granularity exposed and should also help minimizing problems by incomplete or incorrect default mixer initialization on the lower levels.

This also adds support for allowing selection of input/output ports for sound cards. This is used to expose changing between Mic vs. Line-In for input source selection and Headphones vs. Speaker for output selection (of course the list of available port is strictly dependant on what you hardware supports). The list of available ports is deliberately kept minimal.

Thanks to Bastien the newest GNOME Volume Control now exposes profile/port switching quite nicely, which he blogged about. This screenshot shows how the port (here called 'Connector') can be selected in the new dialog.

The mixer rework also allows us to handle semi-pro/pro sound cards a bit more flexibly. For example, which profiles/ports are exposed in PulseAudio or how specific mixer elements are handled can now be controlled by editing .ini file like configuration files in /usr/share/pulseaudio/alsa-mixer/. Read this mail for more information about this.

UPnP MediaServer Support

PulseAudio now integrates with Zeeshan's fabulous Rygel UPnP/DLNA MediaServer. If enabled Rygel will automatically expose all local audio devices which are managed by PulseAudio as UPnP/DLNA MediaServer items which your UPnP/DLNA MediaRenderers can now tune into. (Meaning: you can now stream audio from your PC directly to your UPnP DMP (Digital Media Player) device, such as the PS3.) Communication between Rygel and PulseAudio follows our little Media Server Spec on the GNOME Wiki. This nicely complements the RAOP (Apple Airport) support we introduced in PulseAudio 0.9.15. In one of the next versions of PulseAudio/Rygel we hope to add support for PulseAudio becoming a MediaRenderer as well. This will then not only allow you to stream from your PC to your DMP device, but also allows PulseAudio to act as "networked speaker", which can be used by any UPnP/AV/DLNA control point, such as Windows' Media Player.

Hotplug Support Improved

If you select a particular device as the default for a specific application or class of streams, then when unplugging the device PulseAudio moves the stream automatically to another audio device if one exists. New in PulseAudio 0.9.16 is that if you replug the audio device the stream will instantly be moved back, requiring no further user intervention.

Also, PulseAudio now includes some implicit rules for doing the 'right thing' when finding an audio device for an application. For example, unless configured otherwise it will now route telephony applications automatically to Bluetooth headsets if one is connected, in favour of the internal sound card of the computer.

Surround Sound Support for Event Sounds

This is more a new feature of libcanberra than of PulseAudio, but nonetheless: we now support surround for events sounds. This allows us to play full 5.1 login sounds for example, in best THX cinema fashion. We'd love to ship a 5.1 sound for login by default in sound-theme-freedesktop. We'd be very thankful if you would be willing to contribute a sound here, or two! A sound a bit less bombastic than the famous cinema THX effect would probably be a good idea though.

And then there's of course the usual batch of fixes and small improvements. A substantial number of non-user visible changes have been made as well. For example, as HAL is now obsolete PulseAudio now moved to udev for its device discovery needs. We replaced our gdbm support by support for tdb. Also, we stripped all security senstive code from PulseAudio, and ported it to use RealtimeKit instead. For the upcoming distributions that means that PulseAudio will run as real-time process by default, improving drop-out safety.

And for some extra PA eye-candy, have a look on Impulse!

posted at: 02:30 | path: /projects | permanent link to this entry | 0 comments

Wed, 29 Jul 2009

World Domination Accomplished

I hereby officially declare that I have reached my goal of world domination. Emacs 23 (apparently due today) ships with Avahi support out of the box. Obviously, one of the most natural combinations of software thinkable.

After Emacs, there's not much else I could win, or is there?

posted at: 21:03 | path: /projects | permanent link to this entry | 0 comments

Sat, 20 Jun 2009

Yet Another Kit

A while back I was celebrating that arrival of secure realtime scheduling for the desktop. As it appears this was a bit premature then, since (mis-)using cgroups for this turned out to be more problematic and messy than I anticipated.

As a followup I'd now like to point you to this announcement I posted to LAD yesterday, introducing RealtimeKit which should fix the problem for good. It has now entered Rawhide becoming part of the default install (by means of being a dependency of PulseAudio), and I assume the other distros are going to adopt it pretty soon, too.

Read the full announcement.

posted at: 21:29 | path: /projects | permanent link to this entry | 11 comments

Fri, 12 Jun 2009

Linux Plumbers Conference 2009 CFP Ending Soon!

The Call for Papers for the Linux Plumbers Conference (LPC) in September in Portland, Oregon is ending soon, on June 15th 2009. It's a conference about the core infrastructure of Linux systems: the part of the system where userspace and the kernel interface. It's the first conference where the focus is specifically on getting together the kernel people who work on the userspace interfaces and the userspace people who have to deal with kernel interfaces. It's supposed to be a place where all the people doing infrastructure work sit down and talk, so that each other understands better what the requirements and needs of the other are, and where we can work towards fixing the major problems we currently have with our lower-level APIs.

Last year's conference was hugely successful. If you want to read up what happened then, LWN has good coverage.

Like last year, I will be running the Audio conference track of LPC. Audio infrastructure on Linux is still heavily fragmented. Pro, desktop and embedded worlds are very seperate. While we have quite good driver support the user experience is far from perfect, mostly because our infrastructure is so balkanized. Join us at the LPC and help to fix this! If you are doing audio infrastructure work on Linux, make sure to attend and submit a paper!

Sign up soon! Send in your paper quickly!

Plumbers Logo

See you in Portland!

posted at: 16:18 | path: /projects | permanent link to this entry | 0 comments

Thu, 28 May 2009

Living in Berlin? You are a GNOMEr?

If you live in Berlin and are a GNOMEr of some kind then please feel invited top drop by tomorrow (Fri 29) at 4 pm at the Prater Biergarten (Weather permitting outside, otherwise inside). We'll have a little GNOME get-together. For now, we know that at least the Openismus Berlin folks will be there, as will I and presumably one special guest from Finland, and whoever else wants to attend.

Hope to see you tomorrow!

posted at: 23:50 | path: /projects | permanent link to this entry | 0 comments

Thu, 21 May 2009

The Sound of Fedora 11

I learned so much when I read this interview. And so will you!

posted at: 17:03 | path: /projects | permanent link to this entry | 11 comments

Sun, 19 Apr 2009

All About Fragments

In my on-going series Writing Better Audio Applications for Linux, here's another installment: a little explanation how fragments/periods and buffer sizes should be chosen when doing audio playback with traditional audio APIs such as ALSA and OSS. This originates from some emails I exchanged with the Ekiga folks. In the last weeks I kept copying this explanation to various other folks. I guess it would make sense to post this on my blog here too to reach a wider audience. So here it is, mostly unedited:

Yes. You shouldn't misuse the fragments logic of sound devices. It's
like this:

   The latency is defined by the buffer size.
   The wakeup interval is defined by the fragment size.

The buffer fill level will oscillate between 'full buffer' and 'full
buffer minus 1x fragment size minus OS scheduling latency'. Setting
smaller fragment sizes will increase the CPU load and decrease battery
time since you force the CPU to wake up more often. OTOH it increases
drop out safety, since you fill up playback buffer earlier. Choosing
the fragment size is hence something which you should do balancing out
your needs between power consumption and drop-out safety. With modern
processors and a good OS scheduler like the Linux one setting the
fragment size to anything other than half the buffer size does not
make much sense.

Your [Ekiga's ptlib driver that is] ALSA output is configured
to set the the fragment size to the size of your codec audio
frames. And that's a bad idea. Because the codec frame size has not
been chosen based on power consumption or drop-out safety
reasoning. It has been chosen by the codec designers based on
different reasoning, such as latency.

You probably configured your backend this ways because the ALSA
library docs say that it is recommended to write to the sound card in
multiples of the fragment size. However deducing from this that you
hence should configure the fragment size to the codec frame size is
wrong!

The best way to implement playback these days for ALSA is to write as
much as snd_pcm_avail() tells you to each time you wake up due to
POLLOUT on the sound card. If that is not a multiple of your codec
frame size then you need to buffer the the remainder of the decoded
data yourself in system memory.

The ALSA fragment size you should normally set as large as possible
given your latency constraints but that you have at least two
fragments in your buffer size.

I hope this explains a bit how frag_size/buffer_size should be
chosen. If you have questions, just ask.

(Oh, ALSA uses the term 'period' for what I call 'fragment'
above. It's synonymous)

posted at: 01:34 | path: /projects | permanent link to this entry | 7 comments

Sun, 05 Apr 2009

GNOME now esound-free

Andre Klapper just informed me that GNOME is now officially esound-free: all modules have been ported over to libcanberra for event sounds or GStreamer/PulseAudio for everything else. It's time to celebrate!

It's an end of an era. The oldest version of esound in GNOME CVS is 0.2.1, commited on May 11th 1998. It has been shipped with every GNOME release since 1.0 back in 1999. (esound outside of GNOME dates even further back, probably some time in the year 1997 or so). After almost 11 years in GNOME it's all over now. Oh, those were the good times.

If you maintain a module that is not part of GNOME that still uses esound, hurry and update yours as well!

posted at: 20:23 | path: /projects | permanent link to this entry | 14 comments

Sat, 04 Apr 2009

What YOU need to know about Practical Real-Time Programming

Eduardo Lima just added a couple of more videos from one of the best conferences in existence to the OpenBOSSA channel at blip.tv. Humbly as I am I'd like to ask everyone who is interested in real-time and/or audio/video/animation programming to have a peek at this particular one.

That's all.

posted at: 01:38 | path: /projects | permanent link to this entry | 6 comments

Thu, 26 Feb 2009

Device Reservation Spec

The JACK folks and I have agreed on a little specification for device reservation that allows clean hand-over of audio device access from PulseAudio to JACK and back. The specification is generic enough to allow locking/hand-over of other device types as well, not just audio cards. So, in case someone needs to implement a similar kind of locking/handover for any kind of resource here's some prior art you can base your work on. Given that HAL is supposed to go away pretty soon this might be an option for a replacement for HAL's current device locking. The logic is as simple as it can get. Whoever owns a certain service name on the D-Bus session bus owns the device access. For further details, read the spec.

There's even a reference implementation available, which both JACK2 and PulseAudio have now integrated.

Also known as PAX SOUND SERVERIS.

posted at: 18:55 | path: /projects | permanent link to this entry | 17 comments

Wed, 25 Feb 2009

Having fun with bzr

So I wanted to hack proper channel mapping query support into libsndfile, something I have had on my TODO list for years. The first step was to find the source code repository for it. That was easy. Alas the VCS used is bzr. There are some very vocal folks on the Internet who claim that the bzr user interface is stupendously easy to use in contrast to git which apparantly is the very definition of complexity. And if it is stated on the Internet it must be true. I think I mastered git quite well, so yeah, checking out the sources with bzr can't be that difficult for my limited brain capacity.

So let's do what Erik suggests for checking out the sources:

$ bzr get http://www.mega-nerd.com/Bzr/libsndfile-pub/

Calling this I get a nice percentage counter that starts at 0% and ends at, ... uh, 0%. That gives me a real feeling of progress. It takes a while, and then I get an error:

bzr: ERROR: Not a branch: "http://www.mega-nerd.com/Bzr/libsndfile-pub/".

Now that's a useful error message. They even include an all-caps word! I guess that error message is right -- it's not a branch, it is a repository. Or is it not?

So what do we do about this? Maybe get is not actually the right verb. Let's try to play around a bit. Let's use the verb I use to get sources with in git:

$ bzr clone http://www.mega-nerd.com/Bzr/libsndfile-pub/

Hmm, this results in exactly same 0% to 0% progress counter, and the same useless error message.

Now I remember that bzr is actually more inspired by Subversion's UI than by git's, so let's try it the SVN way.

$ bzr checkout http://www.mega-nerd.com/Bzr/libsndfile-pub/

Hmm, and of course, I get exactly the same results again. A counter that counts from 0% to 0% and the same useless error message.

Ok, maybe that error is bzr's standard reply? Let's check this out:

$ bzr waldo http://www.mega-nerd.com/Bzr/libsndfile-pub/
bzr: ERROR: unknown command "waldo"

Apparently not. bzr actually knows more than one error message.

Ok, I admit doing this by trial-and-error is a rather lame approach. RTFM! So let's try this.

$ man bzr-get
No manual entry for bzr-get

Ouch. No man page? How awesome. Ah, wait, maybe they have only a single unreadable mega man page for everything. Let's try this:

$ man bzr

Wow, this actually worked. Seems to list all commands. Now let's look for the help on bzr get:

/bzr get
Pattern not found  (press RETURN)

Hmm, no documentation for their most important command? That's weird! Ok, let's try it again with our git vocabulary:

/bzr clone
Pattern not found  (press RETURN)

Ok, this not funny anymore. Apparently the verbs are listed in alphabetical order. So let's browse to the letter g as in get. However it doesn't exist. There's bzr export, and then the next entry is bzr help (Oh, irony!) -- but no get in-between.

Ok, enough of this shit. Maybe the message wants to tell us that the repo actually doesn't exist (even though it confusingly calls it a "branch"). Let's go back to the original page at Erik's site and read things again. Aha, the "main archive archive can be found at (yes, the directory looks empty, but it isn't): http://www.mega-nerd.com/Bzr/libsndfile-pub/". Hmm, indeed -- that URL looks very empty when it is accessed. How weird though that in bzr a repo is an empty directory!

And at this point I gave up and downloaded the tarball to make my patches against. I have still not managed to check out the sources from the repo. Somehow I get the feeling the actual repo really isn't available anymore under that address.

So why am I blogging about this? Not so much to start another flamefest, to nourish the fanboys, nor because it is so much fun to bash other people's work or simply to piss people off. It's more for two reasons:

Firstly, simply to make the point that folks can claim a thousand times that git's UI sucks and bzr's UI is awesome. It's simply not true. From what I experienced it is not the tiniest bit better. The error messages useless, the documentation incomplete, the interfaces surprising and exactly as redundant as git's. The only effective difference I noticed is that it takes a bit longer to show those error messages with bzr -- the Python tax. To summarize this more positively: git excels as much as bzr does. Both' documentation, their error messages and their user interface are the best in their class. And they have all the best chances for future improvement.

And the second reason of course is that I'd still like to know what the correct way to get the sources is. But for that I should probably ask Erik himself.

posted at: 10:39 | path: /projects | permanent link to this entry | 0 comments

Mon, 23 Feb 2009

This is funny

Uh?

Some folks apparently don't have much respect for my web design skills -- and I always considered myself the Malevich of web design! Pfft!

posted at: 16:52 | path: / | permanent link to this entry | 10 comments

Sat, 21 Feb 2009

Generating Copyright Headers from git History

Here's a little a little tool I wrote that automatically generates copyright headers for source files in a git repository based on the git history.

Run it like this:

~/projects/pulseaudio$ copyright.py src/pulsecore/sink.c src/pulsecore/core-util.c

And it will give you this:

File: src/pulsecore/sink.c
	Copyright 2004, 2006-2009 Lennart Poettering
	Copyright 2006-2007 Pierre Ossman
	Copyright 2008-2009 Marc-Andre Lureau
File: src/pulsecore/core-util.c
	Copyright 2004, 2006-2009 Lennart Poettering
	Copyright 2006-2007 Pierre Ossman
	Copyright 2008 Stelian Ionescu
	Copyright 2009 Jared D. McNeill
	Copyright 2009 Marc-Andre Lureau

This little script could use love from a friendly soul to make it crawl entire source trees and patch in appropriate copyright headers. Anyone up for it?

posted at: 00:16 | path: /projects | permanent link to this entry | 2 comments

Fri, 20 Feb 2009

Tagging Audio Streams

So you are hacking an audio application and the audio data you are generating might eventually end up in PulseAudio before it is played. If that's the case then please make sure to read this!

Here's the quick summary for Gtk+ developers:

PulseAudio can enforce all kinds of policy on sounds. For example, starting in 0.9.15, we will automatically pause your media player while a phone call is going on. To implement this we however need to know what the stream you are sending to PulseAudio should be categorized as: is it music? Is it a movie? Is it game sounds? Is it a phone call stream?

Also, PulseAudio would like to show a nice icon and an application name next to each stream in the volume control. That requires it to be able to deduce this data from the stream.

And here's where you come into the game: please add three lines like the following next to the beginning of your main() function to your Gtk+ application:

...
g_set_application_name(_("Totem Movie Player"));
gtk_window_set_default_icon_name("totem");
g_setenv("PULSE_PROP_media.role", "video", TRUE);
...

If you do this then the PulseAudio client libraries will be able to figure out the rest for you.

There is more meta information (aka "properties") you can set for your application or for your streams that is useful to PulseAudio. In case you want to know more about them or you are looking for equivalent code to the above example for non-Gtk+ applications, make sure to read the mentioned page.

Thank you!

Oh, and even if your app doesn't do audio, calling g_set_application_name() and gtk_window_set_default_icon_name() is always a good idea!

posted at: 22:02 | path: /projects | permanent link to this entry | 15 comments

Wed, 11 Feb 2009

How to Version D-Bus Interfaces Properly and Why Using / as Service Entry Point Sucks

So you are designing a D-Bus interface and want to make it future-proof. Of course, you thought about versioning your stuff. But you wonder how to do that best. Here are a few things I learned about versioning D-Bus APIs which might be of general interest:

Version your interfaces! This one is pretty obvious. No explanation needed. Simply include the interface version in the interface name as suffix. i.e. the initial release should use org.foobar.AwesomeStuff1, and if you do changes you should introduce org.foobar.AwesomeStuff2, and so on, possibly dropping the old interface.

When should you bump the interface version? Generally, I'd recommend only bumping when doing incompatible changes, such as function call signature changes. This of course requires clients to handle the org.freedesktop.DBus.Error.UnknownMethod error properly for each function you add to an existing interface. That said, in a few cases it might make sense to bump the interface version even without breaking compatibility of the calls. (e.g. in case you add something to an interface that is not directly visible in the introspection data)

Version your services! This one is almost as obvious. When you completely rework your D-Bus API introducing a new service name might be a good idea. Best way to do this is by simply bumping the service name. Hence, call your service org.foobar.AwesomeService1 right from the beginning and then bump the version if you reinvent the wheel. And don't forget that you can acquire more than one well-known service name on the bus, so even if you rework everything you can keep compatibilty. (Example: BlueZ 3 to BlueZ 4 switch)

Version your 'entry point' object paths! This one is far from obvious. The reasons why object paths should be versioned are purely technical, not philosophical: for signals sent from a service D-Bus overwrites the originating service name by the unique name (e.g. :1.42) even if you fill in a well-known name (e.g. org.foobar.AwesomeService1). Now, let's say your application registers two well-known service names, let's say two versions of the same service, versioned like mentioned above. And you have two objects -- one on each of the two service names -- that implement a generic interface and share the same object path: for the client there will be no way to figure out to which service name the signals sent from this object path belong. And that's why you should make sure to use versioned and hence different paths for both objects. i.e. start with /org/foobar/AwesomeStuff1 and then bump to /org/foobar/AwesomeStuff2 and so on. (Also see David's comments about this.)

When should you bump the object path version? Probably only when you bump the service name it belongs to. Important is to version the 'entry point' object path. Objects below that don't need explicit versioning.

In summary: For good D-Bus API design you should version all three: D-Bus interfaces, service names and 'entry point' object paths.

And don't forget: nobody gets API design right the first time. So even if you think your D-Bus API is perfect: version things right from the beginning because later on it might turn out you were not quite as bright as you thought you were.

A corollary from the reasoning behind versioning object paths as described above is that using / as entry point object path for your service is a bad idea. It makes it very hard to implement more than one service or service version on a single D-Bus connection. Again: Don't use / as entry point object path. Use something like /org/foobar/AwesomeStuff!

posted at: 19:03 | path: /projects | permanent link to this entry | 6 comments

Tue, 10 Feb 2009

Writing Volume Control UIs is Hard

Writing modern volume control UIs (i.e. 'mixer tools') is much harder to get right than it might appear at first. Because that is the way it is I've put together a rough guide what to keep in mind when writing them for PulseAudio. Originally just intended to be a bit of help for the gnome-volume-control guys I believe this could be an interesting read for other people as well.

It touches a lot of topics: volumes in general, how to present them, what to present, base volumes, flat volumes, what to do about multichannel volumes, controlling clients, controlling cards, handling default devices, saving/restoring volumes/devices, sound event sliders, how to monitor PCM and more.

So make sure to give it at least a quick peek! If you plan to write a volume control for ncurses or KDE (hint, hint!) even more so, it's a must read.

Maybe this might also help illustrating why I think that abstracting volume control interfaces inside of abstraction layers such as Phonon or GStreamer is doomed to fail, and just not even worth the try.

And now, without further ado I give you 'Writing Volume Control UIs'.

posted at: 21:03 | path: /projects | permanent link to this entry | 10 comments

Oh Nine Fifteen

Last week I've released a test version for the upcoming 0.9.15 release of PulseAudio. It's going to be a major one, so here's a little overview what's new from the user's perspective.

Flat Volumes

Based on code originally contributed by Marc-André Lureau we now support Flat Volumes. The idea behind flat volumes has been inspired by how Windows Vista handles volume control: instead of maintaining one volume control per application stream plus one device volume we instead fix the device volume automatically to the "loudest" application stream volume. Sounds confusing? Actually it's right the contrary, it feels pretty natural and easy to use and brings us a big step forward to reduce a bit the number of volume sliders in the entire audio pipeline from the application to what you hear.

The flat volumes logic only applies to devices where we know the actual multiplication factor of the hardware volume slider. That's most devices supported by the ALSA kernel drivers except for a few older devices and some cheap USB hardware that exports invalid dB information.

On-the-fly Reconfiguration of Devices (aka "S/PDIF Support")

PulseAudio will now automatically probe all possible combinations of configurations how to use your sound card for playback and capturing and then allow on-the-fly switching of the configuration. What does that mean? Basically you may now switch beetween "Analog Stereo", "Digital S/PDIF Stereo", "Analog Surround 5.1" (... and so on) on-the-fly without having to reconfigure PA on the configuration file level or even having to stop your streams. This fixes a couple of issues PA had previously, including proper SPDIF support, and per-device configuration of the channel map of devices.

Unfortunately there is no UI for this yet, and hence you need to use pactl/pacmd on the command line to switch between the profiles. Typing list-cards in pacmd will tell you which profiles your card supports.

In a later PA version this functionality will be extended to also allow input connector switching (i.e. microphone vs. line-in) and output connector switching (i.e. internal speakers vs. line-out) on-the-fly.

Native support for 24bit samples

PA now supports 24bit packed samples as well as 24bit stored in the LSBs of 32bit integers natively. Previously these formats were always converted into 32bit MSB samples.

Airport Express Support

Colin Guthrie contributed native Airport Express support. This will make the RAOP audio output of ApEx routers appear like local sound devices (unfortunately sound devices with a very long latency), i.e. any application connecting to PulseAudio can output audio to ApEx devices in a similar way to how iTunes can do it on MacOSX.

Before you ask: it is unlikely that we will ever make PulseAudio be able to act as an ApEx compatible device that takes connections from iTunes (i.e. becoming a RAOP server instead of just an RAOP client). Apple has an unfriendly attitude of dongling their devices to their applications: normally iTunes has to cryptographically authenticate itself to the device and the device to iTunes. iTunes' key has been recovered by the infamous Jon Lech Johansen, but the device key is still unknown. Without that key it is not realistically possible to disguise PA as an ApEx.

Other stuff

There have been some extensive changes to natively support Bluetooth audio devices well by directly accessing BlueZ. This code was originally contributed by the GSoC student João Paulo Rechi Vita. Initially, 0.9.15 was intended to become the version were BT audio just works. Unfortunately the kernel is not really up to that yet, and I am not sure everything will be in place so that 0.9.15 will ship with well working BT support.

There have been a lot of internal changes and API additions. Most of these however are not visible to the user.

posted at: 20:11 | path: /projects | permanent link to this entry | 31 comments

Tue, 27 Jan 2009

Pascal,

replacing integral parts of a system is always a bit of a dilemma. If we replace it only after all the other software/drivers that interface with it is known to work well with it then nobody will bother doing all that compatbility work since they can say "Nobody uses it yet, so why should I bother?" -- and hence the change can never take place.

If we replace it before everything works perfectly well with it, then folks will complain: "Oh my god, it doesn't work with my software/drivers, you suck!" -- like you just did (though in more polite words).

Hence regardless which way we do it we will do it the wrong way. Biting the bullet and doing the change is however still the better, the only path to improvement. With the limited amount of manpower we have pushing things out knowing that there is some software/drivers that don't work well with it is our only option -- especially if the software in question is unfixable by us since it is closed source.

Hence, if we'd do as you wish and not make the distributions adopt PulseAudio right now we can forget about fixing audio on Linux entirely and it will stagnate forever.

As mentioned by J5 this was the same story with D-Bus, HAL, with udev, and other stuff.

And again, folks may claim that PulseAudio is very buggy. While it certainly has bugs, like every software has, most of the issues reported are not things we can or should fix/work-around in PulseAudio, but that are in other layers of the system. In ALSA, in the drivers, in the client applications. However only PA makes them become visible since it depends on a lot more functionality to work properly than any other program before. And quite frankly we use a lot of stuff exactly nobody has used before and that of course was broken due that (in ALSA as one example).

Having said all this. Just pointing to other folks to blame doesn't really solve the problem. I did a lot of testing on different sound chips, making sure PulseAudio works fine on them. Of course it's a limited testing set (six cards right now to be exact, a seventh model currently being sent to me by my employer, Red Hat.). The list of cards that are currently known to be problematic are listed in our Wiki.

I am not saying that the points you make are rubbish. However, please see the big picture before getting vocal about it.

posted at: 19:17 | path: /projects | permanent link to this entry | 24 comments

Sat, 17 Jan 2009

India, Again

Right after my trip to Brazil in November I flew to Bangalore for FOSS.in 2008. It was one amazing conference! After the bold changes they had announced I feared they might be a bit too ... bold. But they were not. FOSS.in worked out very well, it was a great success, and it was good to see a lot of familiar faces again. (Which reminds me: Hey, the four of you from the PulseAudio Workout, could you please drop me a line? I forgot to put down your email addresses.)

After FOSS.in I flew up to Rajasthan for a much too short trip through this marvelous state:

India   India   India   India   India   India  

India   India   India   India   India   India  

India   India   India   India   India   India  

India   India   India   India   India   India   India   India  

India   India   India   India   India   India   India   India  

India   India   India   India   India   India   India   India  

India   India   India   India   India   India   India   India  

India   India   India   India   India   India   India   India  

India   India   India   India   India   India   India  

India   India   India   India   India   India  

Panorama

Panorama

Panorama

Panorama

Panorama

Panorama

That's Pushkar, Jaipur, Fatehpur Sikri and the Taj Mahal (the real one, not the Hotel they bombed).

posted at: 21:37 | path: /photos | permanent link to this entry | 9 comments

Brazil

In November I spent three weeks in Brazil, the country where I grew up two decades ago. Surprisingly little had changed since then. Except maybe that this time I had an DSLR:

Brazil   Brazil   Brazil   Brazil  

Brazil   Brazil   Brazil   Brazil  

Brazil   Brazil   Brazil   Brazil  

Brazil   Brazil   Brazil   Brazil   Brazil   Brazil  

Brazil   Brazil   Brazil   Brazil   Brazil   Brazil  

Brazil   Brazil   Brazil   Brazil   Brazil   Brazil  

That's Rio de Janeiro and the old colonial towns of Ouro Preto, Mariana, São João del Rey, Tiradentes, Congonhas do Campo, Paraty in Minas Gerais and Rio State.

Panorama

Panorama

Once again Ouro Preto, and Copacabana Beach at night.

posted at: 15:12 | path: /photos | permanent link to this entry | 1 comments

Wed, 29 Oct 2008

Automatic Backtrace Generation

Ubuntu has Apport. Fedora has nothing. That sucks big time.

Here's the result of a few minutes of hacking up something similar to Apport based on the awesome (and much underused) Frysk debugging tool kit. It doesn't post any backtraces on any Internet servers and has no fancy UI -- but it automatically dumps a stacktrace of every crashing process on the system to syslog and stores all kinds of data in /tmp/core.*/ for later inspection.

#!/bin/bash
set -e
export PATH=/sbin:/bin:/usr/sbin:/usr/bin
DIR="/tmp/core.$1.$2"
umask 077
mkdir "$DIR"
cat > "$DIR/core"
exec &> "$DIR/dump.log"
set +e
echo "$1" > "$DIR/pid"
echo "$2" > "$DIR/timestamp"
echo "$3" > "$DIR/uid"
echo "$4" > "$DIR/gid"
echo "$5" > "$DIR/signal"
echo "$6" > "$DIR/hostname"
set -x 
fauxv "$DIR/core" > "$DIR/auxv"
fexe "$DIR/core" > "$DIR/exe"
fmaps "$DIR/core" > "$DIR/maps"
PKGS=`/usr/bin/fdebuginfo "$DIR/core" | grep "\-\-\-" | cut -d ' ' -f 1 | sort | uniq | grep '^/'| xargs rpm -qf | sort | uniq`
[ "x$PKGS" != x ] && debuginfo-install -y $PKGS
fstack -rich "$DIR/core" > "$DIR/fstack"
set +x
(
	echo "Application `cat "$DIR/exe"` (pid=$1,uid=$3,gid=$4) crashed with signal $5."
	echo "Stack trace follows:"
	cat "$DIR/fstack"
	echo "Auxiliary vector:"
	cat "$DIR/auxv"
	echo "Maps:"
	cat "$DIR/maps"
	echo "For details check $DIR"
) | logger -p local6.info -t "frysk-core-dump-$1"

Copy that into a file $SOMEWHERE/frysk-core-dump. Then do a chmod +x $SOMEWHERE/frysk-core-dump and a chown root:root $SOMEWHERE/frysk-core-dump. Now, tell the kernel that core dumps should be handed to this script:

# echo "|$SOMEWHERE/frysk-core-dump %p %t %u %g %s %h" > /proc/sys/kernel/core_pattern

Finally, increase RLIMIT_CORE to actually enable core dumps. ulimit -c unlimited is a good idea. This will enable them only for your shell and everything it spawns. In /etc/security/limits.conf you can enable them for all users. I haven't found out yet how to enable them globally in Fedora though, i.e. for every single process that is started after boot including system daemons.

You can test this with running sleep 4711 and then dumping core with C-\. The stacktrace should appear right-away in /var/log/messages.

This script will automatically try to install the debugging symbols for the crashing application via yum. In some cases it hence might take a while until the backtrace appears in syslog.

Don't forget to install Frysk before trying this script!

You can't believe how useful this script is. Something crashed and the backtrace is already waiting for you! It's a bugfixer's wet dream.

I am a bit surprised though that noone else came up with this before me. Or maybe I am just too dumb to use Google properly?

posted at: 23:05 | path: /projects | permanent link to this entry | 15 comments

Wed, 22 Oct 2008

People of the Free World [1]!

GNOME 2.24 supports XDG sound themes. Unfortunately however right now there is only a single sound theme in existence: the sound-theme-freedesktop -- which is pretty basic.

Help us change this! There are many web sites like art.gnome.org which provide a large selection of graphical themes for Gtk+, Metacity, icon sets and so on. We want to see a similarly large selection of sound themes available! And we'd like you to contribute to this!

How do you prepare sound themes? Read the XDG Sound Theming and the XDG Sound Naming specifications. Start with basing your work on the aforementioned sound-theme-freedesktop. And then just go ahead!

Please note that only subset of the sounds listed in the Sound Naming Specification is currently hooked up properly -- i.e. generated when "input feedback" is enabled or triggered by applications. Nonetheless it makes sense to include them in your theme, because eventually they will be hooked up.

When you put a theme together, make sure that you only select sounds that have a sensible Free Software license -- or if you have produced them yourself you pick a good license yourself. GPLv2+, LGPLv2+, CC-BY-SA 3.0 and CC-BY 3.0 are good choices.

Not everyone is as lucky as Richard Hughes and has a mom who is practically an endless source of special effect sounds. If your mom sucks then don't despair! The OLPC team has compiled a huge set of Free sounds that is waiting to be made an XDG sound theme. I am eagerly looking forward to your sound themes that make use of "The Berklee Sampling Archive - Volume 13 - synthesizer - fx (126 samples) spaceships, lasers, explosions, machineguns, glisses" to start a war in space each time you click a button on your screen![1]

Footnotes

[1] Free as in free desktops that is.

[2] OK, to be honest I am not actually that eagerly looking forward to that. Spacewar-at-your-fingertips is pretty lame in comparison to a theme called "Richard's Mom"[3].

[3] You have no idea what all those Hughsie's-Mom-jokes are about? Then listen to the sound files that are shipped with gnome-power-manager!

posted at: 21:21 | path: /projects | permanent link to this entry | 7 comments

Sat, 11 Oct 2008

Berliners!

Berliners, you might want to attend this rally! It's tomorrow (hmm, or actually today considering it's already past midnight), October 11th 2 pm, Alexanderplatz.

posted at: 02:25 | path: / | permanent link to this entry | 1 comments

Fri, 26 Sep 2008

Responses to my Audio API Guide

My Audio API guide got quite a few responses.

The Good

Takashi likes it. And so does David. Which is great because both are key people in the Linux multimedia community.

It made it to LWN. I sincerely and humbly hope this is not going to stay the only news site picking this up. ;-)

The safe ALSA part of the recommendations will most likely be added to the ALSA documentation soon. The GNOME-relevent part I will be adding to the GNOME platform overview.

The Bad

Aaron basically likes it, although he appears disappointed that KDE's and Qt's Phonon wasn't mentioned more positively. Aaron is very fair in his criticism. Nonetheless I don't think it is valid. My guide is not a list of alternatives. It's a list of recommendations. My recommendations. I do believe that my recommendations very much match the mainstream of the opinions of the key people in Linux multimedia and desktop audio. Of course I don't nearly know everyone of the key hackers in Linux multimedia. But I do know most of those who are actively interested in collaboration, whose projects have a lot mindshare and who attend the conferences that matter for Linux desktop audio.

Also see Christian's comments on Aaron's post.

The Ugly

It wasn't my intention to start another GNOME-vs.-KDE flamefest. Unfortunately a lot of people took this as great opportunity to troll at the various blog comment forums. I guess it is inevitable that some of those whose favourite software is not listed on a recommendation guide like this start to clamour about that. It's a pity not everyone who thinks I am treating KDE unfairly criticises that as fairly and reasonable as Aaron. Anyway, I humbly take this as a sign that people do consider this guide to be relevant and much needed. ;-)

posted at: 00:05 | path: /projects | permanent link to this entry | 4 comments


It should be obvious but in case it isn't: the opinions reflected here are my own. They are not the views of my employer, or Ronald McDonald, or anyone else.

Please note that I take the liberty to delete any comments posted here that I deem inappropriate, off-topic, or insulting. And I excercise this liberty quite agressively. So yes, if you comment here, I might censor you. If you don't want to be censored your are welcome to comment on your own blog instead.


Lennart Poettering <mzoybt (at) 0pointer (dot) net>
Syndicated on Planet GNOME, Planet Fedora, planet.freedesktop.org, Planet Debian Upstream. feed RSS 0.91, RSS 2.0
Archives: 2005, 2006, 2007, 2008, 2009

Valid XHTML 1.0 Strict!   Valid CSS!