Tag Archives: EAST

Avahi on your N800

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-n800.html

I’d love to see proper Avahi support in the Nokia N800 (just think of proper
file manager integration of announced WebDAV shares!), but until now Nokia
doesn’t ship Avahi in Maemo. However, there’s now a simple way to install at
least basic Avahi support on the N800. The INdT includes Avahi in their Canola builds. Hence: just install
Canola and your N800 will register itself via mDNS on your network.

In related news: I am happy to see that Avahi has apparently been included in the just announced GNOME Embedded Platform.


Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/foms-lca-recap.html

Finally, here’s my linux.conf.au 2007 and FOMS 2007
recap. Maybe a little bit late, but better late then never.

FOMS was a very well organized conference with a packed schedule
and a lot of high-profile attendees. To my surprise PulseAudio has been accepted by the
attendees without any opposition (at least none was expressed
aloud). After a few “discussions” on a few mailing lists (including
GNOME MLs) and some personal emails I got, I had thought that more
people were in opposition of the idea of having a userspace sound
daemon for the desktop. Apparently, I was overly pessimistic. Good
news, that!

During the FOMS conference we discussed the problems audio on Linux
currently has. One of the major issues still is that we’re lacking a
cross-platform PCM audio API everyone agrees on. ALSA is Linux-specific
and complicated to use. The only real contender is PortAudio. However,
PortAudio has its share of problems and hasn’t reach wide adoption
yet. Right now most larger software projects implement an audio
abstraction layer of some kind, and mostly in a very dirty, simplistic
and limited fasion. MPlayer does, Xine does it, Flash does
it. Everyone does it, and it sucks. (Note: this is only a very short
overview why audio on Linux sucks right now. For a longer one, please
have a look on the first 15mins of my PulseAudio talk at LCA, linked

Several people were asking why not to make the PulseAudio API the
new “standard” PCM API for Linux. Due to several reasons that would be a
bad idea. First of all, the PulseAudio API cannot be used on anything
else but PulseAudio. While PulseAudio has been ported to Win32, Vista
already has a userspace desktop sound server, hence running PulseAudio
on top of that doesn’t make much sense. Thus the API is not exactly
cross-platform. Secondly, I – as the guy who designed it – am not
happy with the current PulseAudio API. While it is very powerful it is
also very difficult to use and easy to misuse, mostly due to its fully
asynchronous nature. In addition it is also not the exactly smallest
API around.

So, what could be done about this? We agreed on a – maybe –
controversional solution: defining yet another abstracted PCM audio
API. Yes, fixing the problem that we have too many conflicting,
competing sound systems by defining yet another API sounds like a
paradoxon, but I do believe this is the right path to follow. Why?
Because none of the currently available solutions is suitable for all
application areas we have on Linux. Either the current APIs are not
portable, or they are horribly difficult to use properly, or have a
strange license, or are too simple in their functionality. MacOSX
managed to establish a single audio API (CoreAudio) that makes almost
everyone happy on that system – and we should be able to do same for
Linux. Secondly, none of the current APIs has been designed with
network sound servers in mind. However, proper networking support
reflects back into the API, and in a non-trivial way. An API which
works fine in networked environment needs to eliminate roundtrips
where possible, be open for time interpolation and have a flexible
buffering (besides other minor things). Thirdly none of the current
APIs offers enough functionality to properly support all the needs of
modern desktop sound systems, such as per-stream volumes, stream names
and notifications about external state changes.

During FOMS and LCA, Mikko Leppanen (from Nokia), Jean-Marc Valin
(from Xiph) and I sat down and designed a draft API for the
functionality we would like to see in this API. For the time being we
dubbed it libsydney, after the city where we started this
project. I plan to make this the only supported audio API for
PulseAudio, eventually. Thus, if you will code against PulseAudio you
will get cross-platform support for free. In addition, because
PulseAudio is now being integrated into the major distributions (at
least Ubuntu and Fedora), this library will be made available on most
systems through the backdoor.

So, what will this new API offer? Firstly, the buffering model is
much more powerful than of any current sound API. The buffering model
mostly follows PulseAudio’s internal buffering model which
(theoretically) can offer zero-latency streaming and has been
pioneered by Jim Gettys’ AF sound server. It allows you to seek around
in the playback buffer very flexibly. This is very useful to allow
very fast reaction to the user’s playback control commands while still
allowing large buffers, which are good to deal with high network
lag. In addition it is very handy for the programmer, such as when
implementing streaming clients where packets may arrive
out-of-order. The API will emulate this buffering model on top of
traditional audio devices, and when used on top of PulseAudio it will use
its native implementation. The API will also clearly define which
sound formats are guaranteed to be available, thus making it a lot
easier to code without thinking of different hardware supporting
different formats all the time. Of course, the API will be easier to
use than PulseAudio’s current API. It will be very portable, scaling
from FPU-less architectures to pro-audio machines with a massive
number of synchronised channels. There are several modes available to
deal with XRUNs semi-automatically, one of them guaranteeing that the
time axis stays linear and monotonical in all events.

The list of features of this new API is much longer, however,
enough of these grand plans! We didn’t write any real code for this
yet. To make sure that this project is not another one of those which
are announced grandiosely without ever producing any code I will stop
listing features here now. We will eventually publish a first draft of
our C API for public discussion. Stay tuned.

Side-by-side with libsydney I discussed an abstract API
for desktop event sounds with Mikko (i.e. those annoying “bing” sounds
when you click a button and the like). Dubbed libcanberra
(named after the city which one of the developers visited after
Sydney), this will hopefully be for the PulseAudio sample cache API
what libsydney is for the PulseAudio streaming API: a total

As a by-product of the libsydney discussion Jean-Marc
coded a
fast C resampling library
supporting both floating point and fixed
point and being licensed under BSD. (In contrast to
libsamplerate which is GPL and floating-point-only, but which
probably has better quality). PulseAudio will make use of this new
library, as will libsydney. And I sincerly hope that ALSA,
GStreamer and other projects replace their crappy home-grown
resamplers with this one!

For PulseAudio I was looking for a CODEC which we could use to
encode audio if we have to transfer it over the network. Such a CODEC
would need to have low CPU requirements and allow low-latency
operation, while providing hifi audio. Compression ratio is not such a
high requirement. Unfortunately, as it seems no such CODEC exists,
especially not a “Free” one. However, the Xiph people recommended to
hack up a special version of FLAC for this task. FLAC is fast, has
(obviously) good quality and if hacked up could provide low-latency
encoding. However, FLAC doesn’t compress that well. Current PulseAudio
thin-client installations require 170kB network bandwidth for each
client if hifi audio is used. Encoding this in FLAC this could cut
this in half. Not perfect, but better than nothing.

So, that was FOMS! FOMS is a definitely highly recommended
conference. If you have the chance to attend next year, don’t miss it!
I’ve never been to a more productive, packed conference in my life!

At LCA I met fellow Avahi coder Trent Lloyd for the first time. Our
talk about Avahi went very well. During my flights to and back from
.au I hacked up avahi-ui
which I also announced during that talk. Also, in related news,
tedp started to work on an implementation of NAT-PMP
(aka “reverse firewall piercing”; both client and server) for
inclusion in Avahi. This will hopefully make the upcoming Wide-Area
DNS support in Avahi much more useful.

linux.conf.au was a very exciting conference. As a speaker
you’re treated like a rock star, with stuff like the speakers dinner,
the speakers adventure (climbing on top of Sydney’s AMP tower) and
the penguin dinner. Heck, the organizers even picked me up at the
airport, something I really didn’t expect when I landed in Sydney,
which however is quite nice after a 27h flight.

Two talks I particularly enjoyed at LCA:

And just for the sake of completeness, here are the links to my presentations:

Ok, that’s it for now. Thanks go to Silvia Pfeiffer, the rest of
the FOMS team and the Seven Team for organizing these two amazing

One last followup

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/iq-light-final.html

A small, final followup on the blog stories about the mexican style IQ Light:

After some unsuccessful experimenting with materials like Polystyrene
(cracks too easily), I settled on 0.3mm white Polypropylene which is both easy
to work with and easy to find. The light becomes a little bit blue-greyish
cold. I bought Ibico PolyOpaque
report covers
for this purpose, which you can get at German Staples stores.
You can get it in 25, 50 or 100 DIN-A4 packs. Because only two full-size
pieces can be cut from a single A4 sheet and you need 30 pieces you need at
least 15 sheets for a single full-size lamp. I built 10 lamps in various sizes from
this material and it seems to work pretty well.

Have fun!

Das Leben der Anderen

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/leben-der-anderen.html

German movies are usually not my thing – I don’t like the topics, I don’t
like the scripting, I don’t like the acting, I don’t like the actors, I don’t
like the drama and I don’t like the humor. (Ok, they usually lack humor entirely, so there’s not much not to like of the humor.)

However, there’s now a notable exception: Das Leben der Anderen (The Lives of
) is a very good film, one that I really like. It’s an absorbing drama, the scripting is good and the acting is fine. There’s a good reason that
it has won the European Movie Award (Best Film) and is one of the top
contenders for next years’ Oscar (at least the foreign language one).

If you get the chance to see this movie, do it! It’s worth it.

Interlocking Quadrilaterals

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/iqlamp-stencil.html

As promised, here’s
a stencil drawing of the Mexican-style IQ Lamp: .ps, .svg, .pdf. (1:1, DIN A4/ISO 216 paper size)

Fake IQ Light from Mexico - Stencil

30 of these are needed to assemble one mexican style lamp, as depicted below.
The material to cut these patterns from needs to be a thin (less than .5 mm
thick) plastic (or maybe cardboard) which needs to be flexible – but not too
flexible, and not glossy. It might be advisable to use energy-saving light
bulbs for this lamp. They are entirely hidden inside the lamp and might be good
to avoid overheating of the plastic. Assembling
, Video, Instructable. Please note
that assembling the mexican-style IQ light needs a quite a bit manual force
because all pieces are bent a little, in contrast to the original danish
design which appears to be assembled without any force. (at least the video
clip suggests that.) For mounting a cable/lamp socket you might need to cut a
small hole in one of the plastic sheets, to put the cable through.

Once again the photo:

Fake IQ Light from Mexico

Have fun!

Chasing A Light

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/chasing-light.html

Last friday I posted a little Lazyweb experiment,
a hunt for information about a certain kind of lamp sold by a street dealer in
Mexico City. A quick followup on the results:

Surprinsingly many people responded, mostly by email, and partly by blog comment.
As it appears I am not the only one who’s looking for this specific type of
lamp. Furthermore, a non-trivial set of Planet Gnome readers actually already
owns one of these devices. Apparently counterfeit versions of this lamp are
sold all around the world by street dealers and on markets.

The lamp seems to be a modified version of the “IQ Light”, a self
assembly lighting system made up of interlocking quadrilaterals
. It is
a scandinavian design, by Holger Strøm, 1973. It is nowadays
exclusively distributed by Bald & Bang,
Denmark. The lighting system has a very interesting web site of its own, which even includes an
assembling these lamps. The Bald & Bang web site has a
very stylish video which also shows how to assemble an IQ lamp.

Fake IQ Light from Mexico

While my mexican specimen and the official design are very similar, they
differ: the mexican design looks – in a way – “tighter” and … better (at
least in my humble opinion). For comparison, please have a look on the photo I took from the mexican version which is shown
above, and on the many photos returned by Google
, or the one from the IQ Light homepage. It
appears as if the basic geometrical form used by the mexican design is somehow
more narrow than the official danish one.

So, where can one buy one of those lamps? Fake and real ones are sold on
, every
now an then
. The Museum
Store of the New York MoMA
sells the original version for super-cheap $160.
If you search with Google you’ll find many more offers like this one, but all
of them are not exactly cheap – for a bunch of thin plastic sheets. All these
shops sell the danish version of the design, noone was able to point me to a shop
where the modified, “mexican” version is sold.

Given the hefty price tag and the fact that the fake, mexican version looks
better then the original one, I will now build my own lamps, based on the
mexican design. For that I will disassamble my specimen (at least partially)
and create a paper stencil of the basic plastic pattern. I hope to put this up
for download as a .ps file some time next week, since many people
asked for instructions for building these lamps. Presumably the original
design is protected by copyright, hence I will not publish a step-by-step guide
how to build your own fake version. But thankfully this is not even necessary, since the vendor already published a HOWTO and a video for this, online.

Thank you very much for your numerous responses!

avahi-autoipd Released and ‘State of the Lemur’

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-0.6.14.html

A few minutes ago I released Avahi 0.6.14
which besides other, minor fixes and cleanups includes a new component avahi-autoipd.
This new daemon is an implementation of IPv4LL (aka RFC3927, aka
APIPA), a method for acquiring link-local IP addresses (those from the range
169.254/16) without a central server, such as DHCP.

Yes, there are already plenty Free implementations of this protocol
available. However, this one tries to do it right and integrates well with the
rest of Avahi. For a longer rationale for adding this tool to our distribution
instead of relying on externals tools, please read this
mailing list thread

It is my hope that this tool is quickly adopted by the popular
distributions, which will allow Linux to finally catch up with technology that
has been available in Windows systems since Win98 times. If you’re a
distributor please follow these
which describe how to integrate this new tool into your distribution

Because avahi-autoipd acts as dhclient plug-in by default,
and only activates itself as last resort for acquiring an IP address I hope
that it will get much less in the way of the user than previous implementations
of this technology for Linux.

State of the Lemur

Almost 22 months after my first SVN commit to the flexmdns (which was the
name I chose for my mDNS implementation when I first started to work on it)
source code repository, 18 months after Trent and I decided to join our two
projects under the name “Avahi” and 12 months after the release of Avahi 0.1,
it’s time for a little “State of the Lemur” post.

To make it short: Avahi is ubiquitous in the Free Software world. 😉

All major (Debian, Ubuntu, Fedora, Gentoo, Mandriva, OpenSUSE) and many
minor distributions have it. A quick Google-based poll I did a few weeks ago
shows that it is part of at least 19 different
, including a range of embedded ones. The list of applications
making native use
of the Avahi client API is growing, currently bearing 31
items. That list does not include the legacy HOWL applications and the
applications that use our Bonjour compatibility API which can run on top of
Avahi, hence the real number of applications that can make use of Avahi is
slightly higher. The first commercial hardware appliances which include Avahi are
slowly appearing on the market. I know of at least three such products, one
being Bubba.

If you package Avahi for a distribution, add Avahi support to an
application, or build a hardware appliance with Avahi, please make sure to add
an item to the respective lists linked above, it’s a Wiki. Thank you!
(Anonymous registration without Mail address required, though)

Launchpad is Evil

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/launchpad-stole-my-name.html

I always think twice before entering my name in any web form or posting to a
mailing list. Is the web site/list respectable? Do the owners of the web site
have any commercial interest in my name (spam, marketing, …)? Would I ever
regret that my name can be found with Google in context with this web
site/mailing list? If I enter my name is it used for collecting data about me?
Is there any reasonable privacy policy?

Often enough I refrain from entering my name after deciding that the answers
to these questions are unsatisfactory. I like to be in control of my name. If I
am not confident that I remain in control I don’t enter my name to any

Recently it came to my attention that Canonical decided to create an account (!) for me in their
commercial, proprietary bug tracker called “Launchpad”. I never asked for one!
I never even considered having one, because their service clearly is nothing
that would pass the tests mentioned above. They are a commercial service, my
account data is apparently “content” for them, they don’t seem to have any
privacy policy. (At least I couldn’t find any, the navigation is pretty

Canonical’s nimbus of being “the good guys” doesn’t hinder them to
incorporate data from free sources (apparently they got my data from the Debian
BTS) and make a commercial service of it, without even asking the original
contributors if that would be OK with them, or if it is OK to incorporate their
name or personal profile in the service. Apparently Canonical is not much
better than a common spam harvester: generating personal profiles for
business, without consent of the “victim”.

If anyone from Canonical reads this: It is not OK for me to use my name as
“content” for your commercial, proprietary service. Please remove any
reference to my name from your “account” database. I don’t want to have a
Launchpad account. I don’t plan to use Launchpad. Let me decide if I ever want to
join! Thank you very much.

Update: I especially dislike the fact that they created an account for me in
a service where Hitler apparently already has six (!) accounts. I am very sure
that I don’t want to be part of that community.

MSI S270 Laptop Linux Kernel Driver

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/s270-kernel.html

Earlier this year I worked on reverse engineering the
brightness control of my MSI
S270 laptop
. Turning this work into a proper kernel driver was still left
to be done. Until yesterday… The result of yesterday’s work are two kernel patches I already posted
for upstream inclusion.

If you want to test these drivers, download the latest kernel patches:

  1. acpi-ec-transaction.patch
  2. acpi-s270.patch

The two patches apply to kernel 2.6.17. After patching activate “MSI S270
Laptop Extras” under “Device Drivers”/”Misc devices” and recompile and install.
After loading the s270 module, you now have a backlight class driver
exposing its innards in /sys/class/backlight/s270bl/. For
changing the screen brightness issue as root:

echo 8 > /sys/class/backlight/s270bl/brightness

This will set the screen brightness to maximum. The integer range is 0..8.

In addition to this backlight class driver we export a platform driver which
allows reading the current state of the WLAN/Bluetooth subsystem. The platform
drivers also allows toggling the automatic brightness control feature:

cat /sys/devices/platform/s270pf/wlan                 # Show WLAN status
cat /sys/devices/platform/s270pf/bluetooth            # Show Bluetooth status
echo 1 > /sys/devices/platform/s270pf/auto_brightness # Enable automatic brightness control

If the driver refuses to load (returning ENODEV) and you are sure you have
an MSI S270 the machine is probably not recognized correctly by its DMI data.
In that case you can pass force=1 to the driver which will force the
driver load even when the DMI data doesn’t match. YMMV. If everything works
correctly please make sure to send me the output of dmidecode, so that
I can add the DMI data to the list of known laptops in the driver.

There might even be a chance that this driver works on other MSI laptop
models, too (such as S260). YMMV. But don’t come running when the driver causes
your machine to explode! MSI laptops such as the S270 or S260 are often sold as
OEM hardware under different brands (such as Cytron/TCM/Medion/Tchibo MD96100
or “SAM2000”), so if your laptop looks remotely like this one and dmidecode |
yields at least a single line, and you are adventurous
than you might want to test this driver on it. And don’t forget to send me your
dmidecode output if it works for you!

Unfortunately HAL (at least in my version 0.5.7) doesn’t support the generic
backlight device class yet, which means no gnome-power-manager support
for now.

Although this driver is based on reverse engineered data it should be
legally safe even in the US. After I did my initial work on the S270 controls
MSI supplied me with a register table of their ACPI Embedded Controller
(which is what this driver interfaces with) and one of their engineers even
tested my work.

Last but not least I created a mailing list for
discussion of Linux on the MSI S270
. Please join if you run Linux on one of
these machines! I will announce future driver work for the S270 there.

Apple Bonjour adopts the Apache License 2.0

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/bonjour-apache-license.html

Yesterday Apple Bonjour has
under the Apache License 2.0, replacing the old much criticized (because
non-free) APSL licensing.

What does this mean for Avahi? First of all
although the Apache
is much better than the APSL it still isn’t GPL
compatible (at least in the eyes of the FSF), which effectively means that
Bonjour still cannot be used by more than 66% of the Free Software
projects available. Secondly Avahi is more powerful in most areas than Bonjour
ever was. (In fact, there is only a single feature where Bonjour surpasses us:
writable “Wide Area DNS-SD”). Avahi uses all the “hot” Free technologies like
D-Bus and a has much better integration in the Linux networking subsystem. Avahi is more secure (chroot()…)
Avahi is compatible API- and ABI-wise with Bonjour, but not the other way
round. Avahi is now part of every major Linux distribution.

Avahi is actively developed. The aforementioned Wide Area DNS-SD is currently
being worked on by Federico Lucifredi. Since I will write my master thesis
about mDNS scalability a lot of additional development will be done for Avahi
in the next month.

In short: Avahi is here to stay. Apple’s move to the Apache license is too little, too late.

Update: the Bonjour client libraries are BSD licensed, so the 66% argument doesn’t hold.

ZeroConf in Ubuntu

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/zeroconf-ubuntu.html

(Disclaimer: I am not an Ubuntu user myself. But I happen to be the lead developer of Avahi.)

It came to my attention that Ubuntu is
enable Zeroconf/Avahi in default installations. I would like to point out a few

The “No Open Ports” policy: This policy (or at least the
way many people interprete it) seems to be thought out by someone who
doesn’t have much experience with TCP/IP networking. While it might make sense
to enforce this for application-level protocols like HTTP or FTP it doesn’t
make sense to apply it to transport-level protocols such as DHCP, DNS or in
this case mDNS (the underlying protocol of Zeroconf/Avahi/Bonjour):

  • Even the simplest DNS lookup requires the opening of an UDP port for a
    short period of time to be able to recieve the response. This is usually not
    visible to the administrator, because the time is too short to show up in
    netstat -uln, but nonetheless it is an open port. (UDP is not
    session-based (like TCP is) so incoming packets are accepted regardless where
    they come from)
  • DHCP clients listen on UDP port 68 during their entire lifetime (which in
    most cases is the same as the uptime of the machine). DHCP may be misused for
    much worse things than mDNS. Evildoers can forge DHCP packets to change IP
    addresses and routing of machines. This is definitely something that cannot be
    done with mDNS.

All three protocols, DNS, DHCP and mDNS, require a little bit of trust in
the local LAN. They (usually) don’t come with any sort of authentication and
they all are very easy to forge. The impact of forged mDNS packets is clearly
less dangerous than forged DHCP or DNS packets. Why? Because mDNS doesn’t
allow you to change the IP address or routing setup (which forged DHCP allows)
and because it cannot be used to spoof host names outside the .local
domain (which forged DNS allows).

Enforcing the “No Open ports” policy everywhere in Ubuntu would require that
both DNS and DHCP are disabled by default. However, as everybody probably
agrees, this would be ridiculous because a standard Ubuntu installation
couldn’t even be used for the most basic things like web browsing.

Oh, and BTW: DNS lookups are usually done by an NSS plugin which is loaded
by the libc into every process which uses gethostbyname() (the function for doing host name resolutions). So, in
effect every single process that uses this function has an open port for a
short time. And the DNS client code runs with user priviliges, so an exploit
really hurts. dhclient (the DHCP client) runs as root during the entire
runtime, so an exploit of it hurts even more. Avahi in contrast runs as its own user and

It is not my intention to force anyone to use my
. However, enforcing the “No Open Ports” policy unconditionally is
not a good idea. Currently Ubuntu makes exceptions for DHCP/DNS and so
it should for mDNS.

I do agree that publishing all kinds of local services with Avahi in a
default install is indeed problematic. However, if the “No Open Ports” policy
is enforced on all other application-level software, there shouldn’t be any
application that would want to register a service with Avahi.

Starting Avahi “on-demand” is not an option either, because it offers useful
services even when no local application is accessing is. Most notably this is
host name resolution for the local host name. (Hey, yeah, Zeroconf is more than
just stealing music.)

Remember: Zeroconf is about
Zero Configuration. Requiring the user to toggle some obscure
configuration option before he can use Zeroconf would make it a paradox.
Zeroconf was designed to make things “just work”. If it isn’t enabled by
default it is impossible to reach that goal.

Oh, and I enabled commmenting in my blog, if anyone wants to flame me on this…

Photos from Vilanova/Barcelona

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/photos/barcelona.html

I finally found the time to sort my photos from Vilanova i la Geltrú and Barcelona.

My Windows of Barcelona series:

Windows of Barcelona

A few other nice shots:

Photo #361
Photo #371
Photo #366
Photo #381
Photo #386

Photo #222
Photo #210
Photo #125
Photo #137
Photo #5

Photo #311
Photo #301
Photo #317
Photo #281
Photo #269

Photo #268
Photo #89
Photo #49
Photo #35
Photo #95

These are:
1st row: Casa Milà; dito; dito; dito; dito;
2nd row: Palau de la Música Catalana; dito; Mies van der Rohe Pavilion; dito; Vilanova Lighthouse;
3rd row: Sagrada Família; dito; dito; Hospital de Sant Pau; dito;
4th row: Sagrada Família, seen from Sant Pau; City Center/Barri Gòtic; dito; dito; Plaça Reial

A panoramic view of Barcelona photographed from the Montjuic towards the north:

Barcelona Panorama

Those “thunderclouds” on the right side of the image are actually a
result of not using the same exposure settings on all photos that are
part of the panorama. Which is a mistake I didn’t repeat with my
second panoramic view, which again shows Barcelona from the Montjuic, but this time towards the east:

Barcelona Panorama 2

Dont miss the the entire album!

Polypaudio 0.9.0 released

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/polypaudio-0.9.0.html

We are proud to announce Polypaudio
. This is a major step ahead since we decided to freeze the
current API. From now on we will maintain API compability (or at least
try to). To emphasize this starting with this release the shared
library sonames are properly versioned. While Polypaudio 0.9.0 is not
API/ABI compatible with 0.8 it is protocol compatible.

Other notable changes beyond bug fixing, bug fixing and bug fixing
are: a new Open Sound System /dev/dsp wrapper named
padsp and a module module-volume-restore have been

padsp works more or less like that ESOUND tool known as
esddsp. However, it is much cleaner in design and thus works
with many more applications than the original tool. Proper locking is
implemented which allows it to work in multithreaded applications. In
addition to mere /dev/dsp emulation it wraps
/dev/sndstat and /dev/mixer. Proper synchronization
primitives are also available, which enables lip-sync movie playback
using padsp on mplayer. Other applications that are
known to work properly with padsp are aumix,
libao, XMMS, sox. There are some things
padsp doesn’t support (yet): that’s most notably recording,
and mmap() wrapping. Recording will be added in a later
version. mmap() support is available in esddsp but
not in padsp. I am reluctant to add support for this, because
it cannot work properly when it comes to playback latency
handling. However, latency handling this the primary reasoning for
using mmap(). In addition the hack that is included in
esddsp works only for Quake2 and Quake3, both being Free
Software now. It probably makes more sense to fix those two games than
implementing a really dirty hack in padsp. Remember that you
can always use the original esddsp tools since Polypaudio
offers full protocol compatibility with ESOUND.

module-volume-restore is a small module that stores the
volume of all playback streams and restores them when the applications
which created them creates a new stream. If this module is loaded,
Polypaudio will make sure that you Gaim sounds are always played at
low volume, while your XMMS music is always played at full volume.

Besides the new release of Polypaudio itself we released a bunch of
other packages to work with the new release:

  • gst-polyp
    , a Polypaudio plugin for GStreamer 0.10. The
    plugin is quite sophisticated. In fact it is probably the only
    sink/source plugin for GStreamer that reaches the functionality of the
    ALSA plugin that is shipped with upstream. It implements the
    GstPropertyProbe and GstImplementsInterface
    interfaces, which allow gnome-volume-meter and other
    GStreamer tools to control the volume of a Polypaudio server. The sink
    element listens for GST_EVENT_TAG events, and can thus use
    ID3 tags and other meta data to name the playback stream in the
    Polypaudio server. This is useful to identify the stream in the Polypaudio
    Volume Control
    . In short: Polypaudio 0.9.0 now offers first class
    integration into GStreamer.
  • libao-polyp
    , a simple plugin for libao, which is used for audio playback by tools like ogg123 and Gaim, besides others.
  • xmms-polyp
    , an output plugin for XMMS. As special feature it uses the
    currently played song name for naming the audio stream in
  • Polypaudio Manager 0.9.0, updated for Polypaudio 0.9.0
  • Polypaudio Volume Control 0.9.0, updated for Polypaudio 0.9.0
  • Polypaudio Volume Meter 0.9.0, updated for Polypaudio 0.9.0

A screenshot showing most of this in action:

Polypaudio Screenshot.

This screenshot shows: the Polypaudio Manager, the Polypaudio
Volume Control, the Polypaudio Volume Meter, the XMMS plugin, the
GStreamer plugin used by Rhythmbox and gstreamer-properties,
pacat playing some noise from /dev/urandom,
padsp used on MPlayer. (This screenshot actually shows some
post-0.9.0 work, like the icons used by the application windows)

Polypaudio 0.8 Released

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/polypaudio-0.8.html

The reports of Polypaudio’s death are greatly exaggerated.

We are proud to announce the release of Polypaudio
0.8, our networked sound daemon for Linux, other Unix-like operating
systems, and Microsoft Windows. Since the last official release, 0.7,
more than a year has passed. In the meantime Polypaudio experienced
major improvements. Major contributions have been made by both Pierre
Ossman and me. Pierre is being payed by Cendio AB to work on
Polypaudio. Cendio distributes Polypaudio along with their ThinLinc Terminal

Some of the major changes:

  • New playback buffer model that allows applications to freely seek in
    the server side playback buffer (both with relative and absolute indexes) and to synchronize
    multiple streams together, in a way that the playback times are guaranteed to
    stay synchronized even in the case of a buffer underrun. (Lennart)
  • Ported to Microsoft Windows and Sun Solaris (Pierre)
  • Many inner loops (like sample type conversions) have been ported
    to liboil, which
    enables us to take advantage of modern SIMD instruction sets, like MMX or SSE/SSE2. (Lennart)
  • Support for channel maps which allow applications to assign
    specific speaker positions to logical channels. This enables support
    for “surround sound”. In addition we now support seperate volumes for
    all channels. (Lennart)
  • Support for hardware volume control for drivers that support
    it. (Lennart, Pierre)
  • Local users may now be authenticated just by the membership in a
    UNIX group, without the need to exchange authentication cookies. (Lennart)
  • A new driver module module-detect which detects
    automatically what local output devices are available and loads the
    needed drivers. Supports ALSA, OSS, Solaris and Win32 devices. (Lennart, Pierre)
  • Two new modules implementing RTP/SDP/SAP based multicast audio
    streaming. Useful for streaming music to multiple PCs with speakers
    simultaneously. Or for implementing a simple “always-on” conferencing
    solution for the LAN. Or for sharing a single MIC/LINE-IN jack on the
    LAN. (Lennart)
  • Two new modules for connecting Polypaudio to a JACK audio server
  • A new Zeroconf (mDNS/DNS-SD) publisher module. (Lennart)
  • A new module to control the volume of an output sink with a LIRC supported infrared remote
    control, and another one for doing so with a multimeda keyboard. (Lennart)
  • Support for resolving remote host names asynchronously using libasyncns. (Lennart)
  • A simple proof-of-concept HTTP module, which dumps the current daemon status to HTML. (Lennart)
  • Add proper validity checking of passed parameter to every single
    API functions. (Lennart)
  • Last but not least, the documentation has been beefed up a lot and
    is no longer just a simple doxygen-based API documentation (Pierre, Lennart)

Sounds good, doesn’t it? But that’s not all!

We’re really excited about this new Polypaudio release. However,
there are more very exciting, good news in the Polypaudio world. Pierre
implemented a Polypaudio plugin for alsa-libs. This means you
may now use any ALSA-aware application to access a Polypaudio sound
server! The patch has already merged upstream, and will probably
appear in the next official release of alsa-plugins.

Due to the massive internal changes we had to make a lot of modifications to
the public API. Hence applications which currently make use of the Polypaudio
0.7 API need to be updated. The patches or packages I maintain will be updated
in the next weeks one-by-one. (That is: xmms-polyp, the MPlayer patch, the
libao patch, the GStreamer patch and the PortAudio patch)

A side note: I wonder what this new release means for Polypaudio in
Debian. I’ve never been informed by the Debian maintainers of
Polypaudio that it has been uploaded to Debian, and never of the
removal either. In fact I never exchanged a single line with those who
were the Debian maintainers of Polypaudio. Is this the intended way
how the Debian project wants its developers to communicate with
upstream? I doubt that!

How does Polypaudio compare to ESOUND?

Polypaudio does everything what ESOUND does, and much more. It is a
fully compatible drop-in replacement. With a small script you can make
it command line compatible (including autospawning). ESOUND clients
may connect to our daemon just like they did to the original ESOUND
daemon, since we implemented a compatibility module for the ESOUND

Support for other well known networked audio protocols (such as
NAS) should be easy to add – if there is a need.

For a full list of the features that Polypaudio has over ESOUND,
see Polypaudio’s

How does Polypaudio compare to ALSA‘s dmix?

Some people might ask whether there still is a need for a sound
server in times where ALSA’s dmix plugin is available. The
answer is: yes!

Firstly, Polypaudio is networked, which dmix is
not. However, there are many reasons why Polypaudio is useful on
non-networked systems as well. Polypaudio is portable, it is available
not just for Linux but for FreeBSD, Solaris and even Microsoft
Windows. Polypaudio is extensible, there is broad range of additional
available which allow the user to use Polypaudio in many
exciting ways ALSA doesn’t offer. In Polypaudio streams, devices and
other server internals can be monitored and introspected freely. The
volume of the multiple streams may be manipulated independently of
each other, which allows new exciting applications like a work-alike
of the new per-application mixer tool featured in upcoming Windows
Vista. In multi-user systems, Polypaudio offers a secure and safe way
to allow multiple users to access the sound device
simultaneously. Polypaudio may be accessed through the ESOUND and the
ALSA APIs. In addition, ALSA dmix is still not supported properly by
many ALSA clients, and is difficult to setup.

A side node: dmix forks off its own simple sound daemon
anyway, hence there is no big difference to using Polypaudio with the
ALSA plugin in auto-spawning mode. (Though admittedly, those ALSA
clients that don’t work properly with dmix, won’t do so with our ALSA
plugin as well since they actually use the ALSA API incorrectly.)

How does Polypaudio compare to JACK?

Everytime people discuss sound servers on Unix/Linux and which way
is the right to go for desktops, JACK gets mentioned and suggested by some as a
replacement for ESOUND for the desktop. However, this is not
practical. JACK is not intended to be a desktop sound server, instead
it is designed for professional audio in mind. Its semantics are
different from other sound servers: e.g. it uses exclusively floating
point samples, doesn’t deal directly with interleaved channels and
maintains a server global time-line which may be stopped and seeked
around. All that translates badly to desktop usages. JACK is really
nice software, but just not designed for the normal desktop user,
who’s not working on professional audio production.

Since we think that JACK is really a nice piece of work, we added
two new modules to Polypaudio which can be used to hook it up to a
JACK server.

Get Polypaudio 0.8, while it is hot!

BTW: We’re looking for a logo for Polypaudio. Feel free to send us your suggestions!

Update: The Debian rant is unjust to Jeff Waugh. In fact, he had informed me that he prepared Debian packages of Polypaudio. I just never realized that he had actually uploaded them to Debian. What still stands, however, is that I’ve not been informed or asked about the removal.

Avahi Gains Compatibility Layers for Apple Bonjour and HOWL

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-compat.html

A short while ago I checked in to SVN two API/ABI compatibility
modules which implement the HOWL and the Apple
Bonjour (dns_sd.h)
DNS-SD/mDNS APIs on top of Avahi’s
native API. Effectively this means that you can run *all*
Zeroconf-enabled software that is available for free operating systems
seamlessly on top of Avahi. Or at least the software that uses the
limited subset of API functions we support. Missing functions will be
implemented on an on-demand basis. Gnome-VFS/Nautilus works
perfectly, as does Gobby, which are the only real-world applications
we tested until now.

The list of supported/unsupported functions is available from SVN for HOWL and for

The compatibility layers are actually pretty interesting pieces of code: for
compatibility with the way HOWL/Bonjour integrates with event loops we had to
hook up the timeout and I/O watches D-BUS depends on to a single file
descriptor. This involves all kinds of ugly things like threading and
“creative” ways to use the event loop abstraction Avahi provides. Some might
call this “cracktastic”, but it actually works pretty well.

The compatibility layers are not intended to be long term solutions. For
every session object we create a background thread that polls for events and a
DBUS session object. This is an utter waste of resources, especially on
dns_sd.h where every basic operation uses a session object of its own.
In addition, our compatibility layers are incomplete. We do not offer the full
set of functions or the full semantics. Our compatibility is just good enough
to make most Zeroconf-aware programs work with Avahi right now.

We consider neither dns_sd.h nor the HOWL API a “well designed”
API and encourage people to port their programs to our more powerful native
API. To stress this the two modules will warn the user about their usage and
write a warning line to STDERR and syslog. Hopefully this will annoy
people sufficiently that Avahi adoption speeds up a little.

To our own surprise we actually support at least one API function more than each of the
reference implementations! From dns_sd.h we support
DNSServiceEnumerateDomains() which is actually unsupported by
Apple Bonjour on POSIX/Linux systems. The documented HOWL function
sw_ipv4_address_decompose() is actually a NOOP in the
reference implementation, but isn’t in our compatibility layer.

Since dns_sd.h is the only file licensed under a BSD license in the otherwise APSL-licensed
mDNSResponder distribution, we were able to copy it into our sources untouched.

Here’s a screenshot of
Nautilus and Gobby
running on top of Avahi through the HOWL compatibility

Avahi 0.1 Looming

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-0.1.html

Avahi 0.1 is due in
the next few days. The last missing piece is a simplifying C wrapper around the
DBUS API. Though Avahi is currently pre-0.1 it is already quite complete and
mature. To put it with Ross Burton: “… this doesnt count as 0.1 because it
has docs, man pages *and* works

Unfortunately python-dbus has quite a few bugs which make it very difficult
to code with. e.g. it doesn’t handle sending empty arrays, fails to send byte
values and so on. It is difficult to work around all these issues, therefore
the Avahi client tools will not work with an unpatched python-dbus. You need to
apply this
(applying to 0.35.2) to fix at least the byte value bug to get
them working.