レナート   Profession: Audio Terrorist   ﻟﻴﻨﺎﺭﺕ

The slides for my talk about the audio infrastructure of Linux mobile devices at BOSSA 2010 in Manaus/Brazil are now available online. They are terse (as usual), and the most interesting stuff is probably in what I said, and not so much in what I wrote in those slides. But nonetheless I believe this might still be quite interesting for attendees as well as non-attendees.

The talk focuses on the audio architecture of the Nokia N900 and the Palm Pre, and of course particularly their use of PulseAudio for all things audio. I analyzed and compared their patch sets to figure out what their priorities are, what we should move into PulseAudio mainline, and what should better be left in their private patch sets.

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

In recent versions PulseAudio integrates the numerous mixer elements ALSA exposes into one single powerful slider which tries to make the best of the granularity and range of the hardware and extends that in software so that we can provide an equally powerful slider on all systems. That means if your hardware only supports a limited volume range (many integrated USB speakers for example cannot be completely muted with the hardware volume slider), limited granularity (some hardware sliders only have 8 steps or so), or no per-channel volumes (many sound cards have a single slider that covers all channels), then PulseAudio tries its best to make use of the next hardware volume slider in the pipeline to compensate for that, and so on, finally falling back to software for everything that cannot be done in hardware. This is explained in more detail here.

Now this algorithm depends on that we know the actual attenuation factors (factors like that are usually written in units of dB which is why I will call this the "dB data" from now on) of the hardware volume controls. Thankfully ALSA includes that information in its driver interfaces. However for some hardware this data is not reliable. For example, one of my own cards (a Terratec Aureon 5.1 MkII USB) contains invalid dB data in its USB descriptor and ALSA passes that on to PulseAudio. The effect of that is that the PulseAudio volume control behaves very weirdly for this card, in a way that the volume "jumps" and changes in unexpected ways (or doesn't change at all in some ranges!) when you slowly move the slider, or that the volume is completely muted over large ranges of the slider where it should not be. Also this breaks the flat volume logic in PulseAudo, to the result that playing one stream (let's say a music stream) and then adding a second one (let's say an event sound) might incorrectly attenuate the first one (i.e. whenever you play an event sound the music changes in volume).

Incorrect dB data is not a new problem. However PulseAudio is the first application that actually depends on the correctness of this data. Previously the dB info was shown as auxiliary information in some volume controls, and only noticed and understood by very few, technical people. It was not used for further calculations.

Now, the reasons I am writing this blog posting are firstly to inform you about this type of bug and the results it has on the logic PulseAudio implements, and secondly (and more importantly) to point you to this little Wiki page I wrote that explains how to verify if this is indeed a problem on your card (in case you are experiencing any of the symptoms mentioned above) and secondly what to do to improve the situation, and how to get correct dB data that can be included as quirk in your driver.

Thank you for your attention.

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

Horizontal panoramas are so 2009 -- which is why I now give you the vertical panorama:

Now if I wasn't too stupid to hold my camera steady shooting upwards, this could actually have been a really good picture.

posted at: 02:31 | path: /photos | permanent link to this entry | 8 comments

While tracking down some surround sound related bugs I was missing a speaker setup and testing utility. So I decided to do something about it and I present you gnome-speaker-setup:

The tool should be very robust and even deal with the weirdest channel mappings. OTOH the artwork is not really good and appropriate. But I hope it still shows some resemblance to other UIs of this type. If you are an artist wand want to contribute better artwork make sure to go through the Gnome Art Requests page, and more specifically this particular request.

This (or something like it) will hopefully and eventually end up in some way or another in gnome-media. Until that day comes I'll maintain this tool independently.

To compile this you need a recent Vala and libcanberra 0.23.

posted at: 00:58 | path: /projects | permanent link to this entry | 17 comments

Here's the seventh and final part of my ongoing series.

One of the grandest sights in Delhi is Humayun's tomb, a predecessor of the greatest mausoleum of them all, the Taj Mahal:

A little bit further down a view on the garden:

From a different corner:

We'll finish with our last panorama that shows the courtyard the Jama Masjid of Old Delhi:

That's all panoramas from this trip. Thanks for your interest.

posted at: 21:43 | path: /photos | permanent link to this entry | 2 comments

Here's the sixth part of my ongoing series.

Leaving Jodhpur we continued our journey to Jaisalmer, a sand castle of a town in the Thar desert:

In the vicinity of Jaisalmer you'll find cliche sand dunes like you'd expect from a grown-up desert:

Our next station after a long, cold and dusty train ride was Delhi. The principal mosque of Old Delhi is the Jama Masjid:

That's all for now, tomorrow I'll post the rest of my panoramas from this trip, all from Delhi.

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

Here's the fourth part of my ongoing series.

After Udaipur the next stop on our trip was Jodhpur, the blue city. Which is called that way due of the blue colour of many of its houses:

On a hill next to Mehrangarh Fort, one of the biggest Forts in India (the big sand castle on the hill in the panorama above), you find the Jaswant Thada, a memorial of the Maharajas of Jodhpur:

Inside the fort you'll find highly decorated courtyards:

That's all for Jodhpur, tomorrow I'll post more panoramas, from other stops of our trip.

posted at: 18:43 | path: /photos | permanent link to this entry | 0 comments

Here's the fourth part of my ongoing series.

After Hampi we went to Bangalore to attend foss.in. (Fantastic conference, btw. The concerts at the venue are unparalleled.) From there we flew up to Udaipur, in Rajasthan. Udaipur is (among other things) famous for being the place where the central scenes of Octopussy were filmed. Octopussy's famous white palace is on Jagniwas Island in Lake Pichola:

This panorama was taken from another island in the lake, Jagmandir Island, which is visible in the following shot on the left:

Udaipur's scenery, seen from the Maharaja's City Palace down onto Pichola Lake:

That's all for Udaipur, tomorrow I'll post more panoramas, from other stops of our trip.

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

It's easy to get lost in /sys and not much fun typing long udevadm info command lines all the time. Today, when I had enough of that I sat down and spent an hour to write a little UI for exploring the udev/sysfs tree: udev-browse. I wrote it for my own use, but I am quite sure I am not the only one who wants a little bit simpler access to the device tree. So here you go.

And since everybody loves screenshots here you go:

Two usability hints: if you run udev-browse from a directory in /sys udev-browse will automatically present the device of that path on startup. And if you know the name of a device you can just type it into the device listbox (which is focussed by default). The usual Gtk+ live search will then find you the right entry right-away. It's pretty nifty.

It's written in Vala with minimal dependencies.

I want to keep the maintainership burden for this minimal. So no tarballs, no releases, and I won't reply to your emails regarding this tool, unless they include a good, clean, git formatted patch. Thank you for your understanding.

Anyone wants to package this for Fedora? I'd be very thankful if someone would pick it up.

Have fun.

posted at: 02:19 | path: /projects | permanent link to this entry | 9 comments

Here's the third part of my ongoing series.

Still in Hampi here's another 360 from the Hills in Hampi down to the Achyutaraya Temple:

A little further down, before dawn, here's a shot from the rocky path leading up the hill:

Our last picture for today is a view down from Hemakuta Hill which is covered with old temples and other structures. In the middle you'll see the large Virupaksha Temple which is still in full use. In that temple you'll find an amazing camera obscura, a physics teacher's dream that projects the temple tower onto a wall (projection, subject, more interesting in reality. Really.)

That's all for Hampi, tomorrow I'll post more panoramas, from other stops of our trip.

posted at: 23:47 | path: /photos | permanent link to this entry | 3 comments

Everyone and his dog seem to call libxml2's xmlCleanupParser() at inappropriate places. For example Empathy does it, and Abiword does it too. Google Code Search seems to reveal at least Inkscape and Dia do it as well.

So, please, if your project links against libxml2 verify that it calls xmlCleanupParser() only once, and right before exiting! And if it calls it more often or somewhere else, then please fix that!

For more information see my post on fedora-devel.

Thanks for your time.

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

Here's the second part of my ongoing series.

Climbing down the hills, on the banks of the Tungabhadra river you find people washing laundry and bathing, and coracles waiting to be used for a trip through the river.

The greatest of the ancient temples in Hampi is the Vitthala Temple:

Set in in lush green scenery you find the Achyutaraya Temple, which you already might have seen, from above, in yesterday's series:

That's it for today, tomorrow I'll post more panoramas, both from Hampi and other stops of our trip.

posted at: 19:05 | path: /photos | permanent link to this entry | 2 comments

Yes, I won't spare you my panorama shots from my recent trip to India. After arriving in Goa Badami was our next stop. It's a very pretty little town in northern Karnataka, and here's a panorama shot from the entrance of the town's famous caves:

Next step was one of the most amazing places on earth, Hampi in central Karnataka. It is definitely one of the greatest sights I have ever seen, and I guess I can say I have seen quite a few in my life. A vast landscape of hills covered in boulders, lush mango and banana plantations, rice fields, dotted with age-old temples and impressive ruins. Locals crossing the river in coracles that look like they belong in a time centuries ago. Women washing colourful laundry in the river, pilgrims wading across the river in their black clothes. An India that delivers every bit of that promise it makes to its visitors. The ruins rival the grand sites in Greece and the landscape sometimes looks like a Crysis in-game scene.

Taken from one of the hills in Hampi this is the sunset:

And then, the next day at dawn make your way up the hills again and you can get an even greater view on the whole scenery:

That's it for today, tomorrow I'll post more panoramas, both from Hampi and other stops of our trip.

Also, if you haven't seen them yet, don't miss my panoramas from my India trip the year before.

posted at: 20:56 | path: /photos | permanent link to this entry | 6 comments

  

India is a weird and beautiful country. And I am too lazy to retouch my photos.

posted at: 16:33 | path: /photos | permanent link to this entry | 3 comments

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

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 | 5 comments

<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

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

CIO has an interview with me.

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

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

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

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

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

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

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

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

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

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 | 27 comments

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

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:

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:

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

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

The caldera is covered in old lava flows:

Vulcanism has created various interesting rock formations in the caldera:

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

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:

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

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

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

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

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

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!

See you in Portland!

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

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

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

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

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

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

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