Making Spotify, Wine and PulseAudio Play Together

In what has now become a series on this marvellous blog, we’re diving into how to make PulseAudio play nice with Spotify running under Wine. After yesterday’s article about getting any sound through PulseAudio at all, the next issue that surfaced was that the output from Spotify running under Wine were just garbled noise. This worked with the previous ALSA or OSS setup, but with PulseAudio everything went haywire!

Luckily the massive wisdom of teh intarwebs came to the rescue again, this time through an almost three year old post by Paul Betts: “Make Wine and PulseAudio Get Along“.

The solution is to first use padsp winecfg to configure padsp for a specific process, then use padsp to redirect any access to /dev/dsp while the provided application runs.

First run:

padsp winecfg

Then add padsp to your spotify startup script (or if you do this manually, just .. remember to type it. OK?):

padsp wine "C:\program files\spotify\spotify.exe"

Restart Spotify and enjoy the massive collection of great music!

Missing Devices or Sound Card in Pulse Audio

After getting the missing sound control panel in Ubuntu back yesterday, the next problem that turned up was that no actual applications would play any sound – other than the annoying beep! beep! beep!

The reason is that after the pulseaudio configuration has been installed, pulseaudio it self may be missing all it device drivers and other packages.

The solution for this issue can be found at the page for PulseAudio at the Ubuntu Wiki.

Install the missing PulseAudio packages through APT:

sudo apt-get install libasound2-plugins "pulseaudio-*" paman padevchooser paprefs pavucontrol pavumeter

Restart the application that needs sound support and everything should work. If you’re still not getting any sound, check the PulseAudio device configuration (by default installed under Applications, Sound and Video, PulseAudio Device Chooser) and that your device shows up there (mine didn’t before installing the above packages).

Adding SVN Revision to a Configuration File

After a while you realize that the best way to serve almost-never-changing content is to give the content an expire date way ahead in the future. The allows your server and your network pipes to do more sensible stuff than delivering the same old versions of files again and again and again and again.

A problem does however surface when you want to update the files and make the visiting user request the new version instead of the old. The trick here is to change the URL for the resource, so that the browser requests the new file. You can do this by appending a version number to the file and either rewriting it behind the scenes to the original file, or by appending a timestamp (or some other item) to the URL as a GET value. The web server ignores this for regular files, but as it identifies a new unique resource, the web browser has to request it again and use the new and improved ™ file.

Using the timestamp of the file is a bit cumbersome and requires you to hit the disk one additional time each time you’re going to show an URL to one of the almost-static resources, but luckily we already have an identifier describing which version the file is in: the SVN revision number (.. if you use subversion, that is). You could use the SVN revision for each file by itself, but we usually decide that the global version number for SVN is good enough. This means that each time you update the live code base through svn up or something like that (remember to block .svn directories and their files if you run your production directory from a SVN branch. This can be discussed over and over, but I’m growing more and more fond of actually doing just that..). To avoid having to call svnversion each time, it’s useful to be able to insert the current revision number into the configuration file for the application (or a header file / bootstrap file).

Here’s an example of how you can insert the current SVN revision into a config file for a PHP application.

  1. Create a backup of the current configuration file.
  2. Update the current revision through svn up.
  3. Retrieve the current revision number from svnversion.
  4. Insert the revision number using sed into a temporary copy of the configuration file.
  5. Move the new configuration file into place as the current configuration file.
  6. Party like it’s 1999!

This assumes that you use an array named $config in your configuration file. I suggest that you name it something else, but for simplicity I’m going with that here. First, create a $config[‘svn’] entry in your config file. If you have some other naming scheme, you’re going to have to change the relevant parts below.

#!/bin/bash
cp ./config/config.php ./config/config.backup.php
svn up
VERSION=`svnversion .`
echo $VERSION
sed "s/config\['svn'\] = '[0-9M]*';/config\['svn'\] = '$VERSION';/" < ./config/config.php > ./config/config.fixed.php
mv ./config/config.fixed.php ./config/config.php

Save this into a file named upgrade.sh, make it executable by doing chmod u+x upgrade.sh and run it by typing ./upgrade.sh.

And this is where you put your hands above your head and wave them about. When you’re done with that, you can refer to your current SVN revision using $config[‘svn’] in your PHP application (preferrably in your template or where you build the URLs to your static resources). Simply append ?v=$config[‘svn’] to your current filenames. When you have a new version available, run ./upgrade.sh (or whatever name you gave the script) again and let your users enjoy the new experience.