After BOSSA in Manaus/Brazil we took a very enjoyable boat trip down the Amazon, to Santarém and particularly Alter do Chão, a ridiculously amazing island paradise with glaring white sand in the middle of the jungle:

The town is located on the Tapajós River:

Up the river you find the Tapajós National Forest:

From there we went on to São Luís, a beautiful old colonial town:

A windy and wet sailing catamaran ride from São Luís you find Alcântara, another old colonial town, now partly in ruins and deserted:

As a short followup on an older blog posting of mine:

So you are using librsvg's rsvg_term() in your code? If so then you are probably misusing it and triggering crashes in PulseAudio related code. The same way everybody should stop using libxml2's xmlCleanupParser() call, stop using rsvg_term()! It's really hard to use it correctly, and uneeded anyway. Also see this bug report.

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.

#nocomments y

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.

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.

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.

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.

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.

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.

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.