PulseAudio

pulseaudio: Exited to see Windows supported in the upcoming v1.0 pre-release snapshot (by Maarten)

pulseaudio: PulseAudio Developers (and those users I like!) can tweet again from our IRC channel \o/ (by Colin)

pulseaudio: PulseAudio 0.9.23 Released! Grab it while it's hot: http://t.co/TWminho (Docs: http://t.co/Qx5ZBCG Changes: http://t.co/KktbFeC)

OK, so it's been about a year since I was last in this sleeply little town on the path to Zermatt and a lot has changed. While last year it felt like I was the lone voice singing the praises of PulseAudio (although there were a few supporters!), but ... [More] this year it feels like everything has gone 180° with pretty much everyone on board! This is a great result for me personally as I've been pretty much the only person working on KDE+PulseAudio integration, so I was very pleased to get this feedback. It's good to know that the hard work and effort you put in is appreciated. It's all too often that the people who appreciate your work are the silent majority (if you do a really good job, they don't know you've done anything as things Just Work™), while the vocal minority are quick to shout and judge and generally flame. So I was off to an lovely start and I got down to hacking. What did I do this year? Well I continued some work on the interface I made last year called "Speaker Setup". I realised just a short while ago that there was no interface in KDE to be able to change the Source Ports (i.e. pick Mic vs. Line In on your laptop) so I set about extending speaker setup to cope with this. I added a Mic VU meter for good measure (mainly to use up the space with something vaguely useful!). I would ultimately like to do more with this UI but this would need more changes in PulseAudio itself (come listen to my talk in Berlin at the Desktop Summit if you want to know more about this!). As well as this, I did some tweaks in Phonon to tidy some things up. Various bits and bobs within Phonon and the KCM had bit rotted a little, so minor tweaking saw that all brought up to speed. I also spent some time hacking on PulseAudio itself, improving some earlier work related to adding Source Output volume controls to PA to take on peer review comments (for those of you unaware, this is capture stream volume control - PA has long supported "per-application" volume control but this only actually applied to outputs. It's not really very common for users to record multiple streams at the same time so support for per-capture stream volumes was never introduced. Now that PA supports Flat Volumes (a feature that always tries to use the hardware volume whenever possible to get the most efficient volume adjustment path), it makes sense to use this for inputs too. It also establishes a degree of symmetry to the API which has always felt a little weird in the past - especially if you are developing a VoIP app (the guys from Skype were a little confused about this disparity for example)). I also spent some time making some minor improvements to pavucontol (shh, don't tell the KDE guys but this is a GTK app!) as this is still my main debug tool when hacking on PA (I mainly improved it to deal more gracefully with errors - like when PA itself crashes and leaves behind the X11 root window's PULSE_SERVER property which results in an invalid argument error from the context with the result that the automatic reconnect mode doesn't work! - but also added some simple keyboard shortcuts that I generally miss when switching windows quickly). I also added support for Source Output volumes to KMix, but this will stay in my private branch until I've committed the PA code as the version check will currently match git master code even if it doesn't yet have the support needed! I also started to look at Arun and Pierre's awesome work to support passthrough. As there is no reliable way to query receivers for the encodings they support (AC3, DTS etc.) we have to provide a way for users to specify this manually. I worked to rejig how PA stores various bits of information in internal databases to allow for arbitrary lengths of data to be stored rather than the fixed size blobs supported currently. This will pave the way to adding a protocol extension to set the formats for which support will have to be added to the Speaker Setup GUI somehow... In addition, I also looked at VLC's PulseAudio output layer. I've known for a while that it's kind of lacking and Rémi from upstream VLC has become rather exasperated about the lack of good documentation we provide. I fully appreciate our docs are lacking (some mails on our mailing list today highlight that internal docs for module development are also severely lacking), but I was able to use what was out there to add what I think is quite robust support to VLC. As VLC is used as a Phonon backend by some distros, I felt this was an important task to work on during this KDE sprint. All in all it was a pleasure to stay here again and meet some now familiar as well as some new people (especially Bart and Trever who are big PA fans!) I look forward to seeing several of them again in Berlin and hopefully next year here in Randa too! Share and Enjoy: [Less]

Good news everyone! Mageia 1 is out!!!! Just as I travel to Randa for the KDE Multimedia Development Sprint, I hear that all the hard work put in by the various contributors (in all their forms: packagers, admins, translators, testers and artists) ... [More] has come to fruition! Go read the official announcement and release notes and then download it! I've not had nearly as much time to contribute as much as I would have liked to this release, due to various personal, work and upstream project commitments, but I know my good friends and colleagues have done a stellar job (and I've helped out when I can). I should say that this shouldn't be expected as a ground breaking release. We're not using Gnome 3 or Systemd yet (both will most likely come in Mageia 2) as this release more signifies the establishing of all the various infrastructure needed to create a distro (build cluster, community management, mirror management etc.) especially the proper cleaning and rebuilding of all of the Mandriva packages thought to be essential or vaguely useful. This was a momentous task and one that I think has been achieved in good time. Onwards and upwards! (to 2!)   Share and Enjoy: [Less]

The Linux Plumbers Conference 2011 in Santa Rosa, CA, USA is coming nearer (Sep. 7-9). Together with Kay Sievers I am running the Boot&Init track, and together with Mark Brown the Audio track. For both tracks we still need proposals. So if you ... [More] haven't submitted anything yet, please consider doing so. And that quickly. i.e. if you can arrange for it, last sunday would be best, since that was actually the final deadline. However, the submission form is still open, so if you submit something really, really quickly we'll ignore the absence of time travel and the calendar for a bit. So, go, submit something. Now. What are we looking for? Well, here's what I just posted on the audio related mailing lists: So, please consider submitting something if you haven't done so yet. We are looking for all kinds of technical talks covering everything audio plumbing related: audio drivers, audio APIs, sound servers, pro audio, consumer audio. If you can propose something audio related -- like talks on media controller routing, on audio for ASOC/Embedded, submit something! If you care for low-latency audio, submit something. If you care about the Linux audio stack in general, submit something. LPC is probably the most relevant technical conference on the general Linux platform, so be sure that if you want your project, your work, your ideas to be heard then this is the right forum for everything related to the Linux stack. And the Audio track covers everything in our Audio Stack, regardless whether it is pro or consumer audio. And here's what I posted to the init related lists: So, please consider submitting something if you haven't done so yet. We are looking for all kinds of technical talks covering everything from the BIOS (i.e. CoreBoot and friends), over boot loaders (i.e. GRUB and friends), to initramfs (i.e. Dracut and friends) and init systems (i.e. systemd and friends). If you have something smart to say about any of these areas or maybe about related tools (i.e. you wrote a fancy new tool to measure boot performance) or fancy boot schemes in your favourite Linux based OS (i.e. the new Meego zero second boot ;-)) then don't hesitate to submit something on the LPC web site, in the Boot&Init track! And now, quickly, go to the LPC website and post your session proposal in the Audio resp. Boot&Init track! Thank you! [Less]

[tl;dr — if you're using GNOME or a GStreamer-based player, not using the Rhythmbox crossfading backend, and want to try to save ~0.5 W of power, jump to end of the post] Lennart pointed to another blog post about actually putting PulseAudio’s ... [More] power-saving capabilities to use on your system. The latter provides a hack-ish way to increase buffering in PulseAudio to the maximum possible, reducing the number of wakeups. I’m going to talk about that a bit. Summarising the basic idea, we want music players to decode a large chunk of data and give it to PA so that we can then fill up ALSA’s hardware buffer, sleep till it’s almost completely consumed, fill it again, sleep, repeat. More details in this post from Lennart. The native GNOME audio/video players don’t talk to PulseAudio directly — they use GStreamer, which has a pulsesink element that actually talks to PulseAudio. We could configure things so that we send a large amount (say 2 seconds’ worth) to PulseAudio, sleep, and then wake up periodically to push out more. Now in the audio player (say Rhythmbox), the user hits next, prev, or pause. We need to effect this change immediately, even though we’ve already sent out 2 seconds of data (it would suck if you hit pause and the actual pause happened 2 seconds later, wouldn’t it?). PulseAudio already solves because it can internally “rewind” the buffer and overwrite it if required. GStreamer can and does take advantage of this by sending pause and other control messages out of band from the data. This all works well for relatively simple GStreamer pipelines. However, if you want to do something more complicated, like Rhythmbox’ crossfading backend, things start to break. PulseAudio doesn’t offer an API to do fades, and since we don’t do rewinds in GStreamer, we need to apply effects such as fades with a latency equal to the amount of buffering we’re asking PulseAudio to do. This makes for unhappy users. Well, all is not as bleak as it seems. There was some discussion on the PA mailing list, and the need for a proper fade API (really, a generic effects API) is clear. There have even been attempts to solve this in GStreamer. But you want to save 0.5 W of power now! Okay, if you’re not using the Rhythmbox crossfading backend (or are okay with disabling it), this will make Rhythmbox, Banshee, pre-3.0 Totem (and really any GNOMEy player that uses gconfaudiosink, which will soon be replaced by gsettingsaudiosink, I guess), you can run this on the command line: gconftool-2 --type string \ --set /system/gstreamer/0.10/default/musicaudiosink \ "pulsesink latency-time=100000 buffer-time=2000000" On my machine, this brings down the number of wakeups per second because of alsa-sink to ~2.7 (corresponding nicely to the ~350ms of hardware buffer that I have). With Totem 3.0, this may or may not work, depending on whether your distribution gives gconfaudiosink a higher rank than pulseaudiosink. This is clearly just a stop-gap till we can get things done the Right Way™ at the system level, so really, if things break, you get to keep the pieces. If you need to, you can undo this change by running the same command without the latency-time=… and buffer-time=… bits. That said, if something does break, do leave a comment below so I can add it to the list of things that we need to test the final solution with. [Less]

D. Jansen has put up a blog story including some power saving results when running PulseAudio on modern HDA drivers. This shows off some work Pierre-Louis Bossart from Intel did on the HDA drivers which now enables the timer-based scheduling code in ... [More] PulseAudio I added quite some time ago to come to its full potential. You can save half a Watt and reduce wakeups while playing audio to 1 wakeup/s. Previously there was little public profiling data available about the benefits PA brings you for low-power devices. Thanks to Dennis' data there's now public data available that hopefully explains why PA is the best choice for low-power devices as well as desktops. Hopefully this cleans up some misconceptions. Pierre-Louis, thanks for your work! Update: Arun Raghavan has posted a follow-up to this. [Less]

Here is a group photo of the attendees at the ASoC and Embedded Linux Audio Conference in Edinburgh :

(Skip to the update)Ok, so with some help from Pierre-Louis from Intel I've managed to get it working and do some performance/power tests. But let me start at the beginning: Recently, pulseaudio not only switched to a more power efficient (and ... [More] otherwise) timing system, as far as I understand a callback API. It also provided the infrastructure to use ALSA devices without causing any interrupts ("period wakeup disabling"), so you CPU can stay longer in standby mode (e.g. "C6 residency"), saving you power and avoiding playback glitches at the same time. See here and here or more background information. With kernel 2.6.38 the first driver (snd-hda-intel) supports this infrastructure out of the box, the snd-hda-intel driver. This combination is what I tested for power efficiency...Read more »(...) -- Click to read the entire post. [Less]