232
I Use This!
Low Activity

News

Analyzed about 10 hours ago. based on code collected 1 day ago.
Posted over 13 years ago
pulseaudio: Want to know how to build & run PA from git without messing up your system? Here is a handy guide http://is.gd/fuhm8 (by Colin)
Posted over 13 years ago
A few budding developers have asked me recently about this and to make life easy, I decided to write up this guide! There are some gotchas to look out for so please read carefully! Are we ready? OK, lets being! The shell output shown below will ... [More] include my machine's name, "jimmy". My bash prompt also shows the current git branch thanks to the git-prompt package in Mandriva (you can enable it manually by following this guide). Note that for various reasons I wont go into in this guide, the development version of PA is currently 0.9.19, this is despite the current released version being 0.9.21. Its due to how the git tree is organised, and I'm hoping to fix this soon. Edit: Git master is now tracking PA 1.0 (not for any specific milestone of 1.0, but just because a 3-point version number is kinda annoying. Essential the version policy is now decided and all should be working fine now. There may still be a 0.9.23 based of the current stable-queue branch, but the next release from master will be 1.0. May the Source Be With You The first job is to clone our code repository. You first have to pick where you want to keep your development version. In the example below I've decided to use a folder under my home directory called "padev" [colin@jimmy ~]$ git clone git://git.0pointer.de/pulseaudio.git padev Cloning into padev... remote: Counting objects: 39578, done. remote: Compressing objects: 100% (6760/6760), done. remote: Total 39578 (delta 32779), reused 39578 (delta 32779) Receiving objects: 100% (39578/39578), 14.56 MiB | 1.97 MiB/s, done. Resolving deltas: 100% (32779/32779), done. [colin@jimmy ~]$ Now you should have a ~/padev/ folder containing the code. Compile Time Now it's time to compile the code, but before we do this, we have to prepare the checkout for compilation. Handily there is a script provided to make this easy for us. [colin@jimmy ~]$ cd padev/ [colin@jimmy padev (master)]$ ./bootstrap.sh -V + case $(uname) in ++ uname ... + make clean make: *** No rule to make target `clean'.  Stop. [colin@jimmy padev (master)]$ There is an error about not being able to "make clean" here but you can safely ignore that. Next we'll create a build directory. This is not mandatory, but it helps keep temporary build files etc. separate from the code in the checkout (there are special git commands to delete such files but all the same, I feel this is cleaner). After creating the build directory, we change to it and run the configure script. [colin@jimmy padev (master)]$ mkdir build [colin@jimmy padev (master)]$ cd build/ [colin@jimmy build (master)]$ ../configure --prefix=$(pwd) checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes ... config.status: executing po/stamp-it commands ---{ pulseaudio 0.9.19-562-g395da }--- prefix:                        /home/colin/padev/build sysconfdir:                    ${prefix}/etc localstatedir:                 ${prefix}/var System Runtime Path:           ${prefix}/var/run/pulse System State Path:             ${prefix}/var/lib/pulse System Config Path:            ${prefix}/var/lib/pulse Compiler:                      gcc -std=gnu99 CFLAGS:                        -g -O2 -Wall -W -Wextra -pipe -Wno-long-long -Winline -Wvla -Wno-overlength-strings -Wunsafe-loop-optimizations -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security -Wmissing-include-dirs -Wformat-nonliteral -Wold-style-definition -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wcast-align -Wstrict-aliasing=2 -Wwrite-strings -Wno-unused-parameter -ffast-math -Wp,-D_FORTIFY_SOURCE=2 -fno-common -fdiagnostics-show-option -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include Have X11:                      yes Enable OSS Output:             yes Enable OSS Wrapper:            yes Enable CoreAudio:              no Enable Alsa:                   yes Enable Solaris:                no Enable GLib 2.0:               yes Enable Gtk+ 2.0:               yes Enable GConf:                  yes Enable Avahi:                  yes Enable Jack:                   yes Enable Async DNS:              yes Enable LIRC:                   yes Enable DBUS:                   yes Enable HAL:                    yes Enable udev:                   yes Enable HAL->udev compat:       no Enable BlueZ:                  yes Enable TCP Wrappers:           yes Enable libsamplerate:          yes Enable IPv6:                   yes Enable OpenSSL (for Airtunes): yes Enable tdb:                    yes Enable gdbm:                   no Enable simple database:        no Enable fftw:                   yes System User:                   pulse System Group:                  pulse Access Group:                  pulse-access Enable per-user EsounD socket: yes Force preopen:                 no Preopened modules:             all [colin@jimmy build (master)]$ You should pay particular attention to the --prefix argument passed to configure. Rather than "installing" this version of PulseAudio, we'll just run it from the source tree. This is both quicker and saves any potential conflict with your system-installed PulseAudio packages. You should also pay attention to the table at the end which lists the available support. In order for automatic card detection to work properly with your build, you really should ensure that udev support in particular is available. If it does not print a "yes" line in the output then you probably do not have the "udev-devel" package for your distro installed. Let's Build OK, so you're ready to build! But not quite. Due to an upstream bug, the translations for .desktop files are not written if the destination folder does not exist, so let's create it manually [colin@jimmy build (master)]$ mkdir -p src/daemon [colin@jimmy build (master)]$ OK, with all the prep work done, we really do build it. [colin@jimmy build (master)]$ make echo 0.9.19-562-g395da > ../.version-t && mv ../.version-t ../.version make  all-recursive ... file=`echo zh_TW | sed 's,.*/,,'`.gmo \ && rm -f $file && /usr/bin/msgfmt -o $file ../../po/zh_TW.po make[2]: Leaving directory `/home/colin/padev/build/po' make[2]: Entering directory `/home/colin/padev/build' make[2]: Leaving directory `/home/colin/padev/build' make[1]: Leaving directory `/home/colin/padev/build' [colin@jimmy build (master)]$ Now that it's built successfully we can run it, but we'll do a little bit of preparation first. As ALSA currently lacks UCM (Use Case Management) (although this is due to be added soon), PulseAudio supports a fairly robust "probing" system to determine how your sound hardware works. In order to run these probes it has to know where to look for the "mixer profile" definitions. As we are running from the build tree, we'll cheat a little and use a symlink so that our development build can find the files. [colin@jimmy build (master)]$ mkdir -p share/pulseaudio [colin@jimmy build (master)]$ ln -s ../../../src/modules/alsa/mixer share/pulseaudio/alsa-mixer [colin@jimmy build (master)]$ In order to run some test tools, we also need to manually create some symlinks that are normally done as part of the install process. [colin@jimmy build (master)]$ ln -s pacat src/paplay [colin@jimmy build (master)]$ ln -s pacat src/parec [colin@jimmy build (master)]$ Run, Forest, Run! Now that things are built and some symlinks are in place, we can run our nice shiny development version. You should first ensure that the system-installed PulseAudio daemon is not running. In order to do this, you should disable autospawn by doing: echo "autospawn=no" >> ~/.pulse/client.conf Once this is done, you should reboot. PulseAudio will likely still start when you log in to X11 by virtue of the start-pulseaudio-x11 script that is run at login, but some systems that rely on PA autospawn may not initialise correctly (e.g. under KDE knotify and kmix may start in 'ALSA mode'. This is generally not a problem, but you should be aware of the consequences. So if your system PA has been run, simply execute: pulseaudio -k To kill the currently running daemon. You can then start your development version via: [colin@jimmy build (master)]$ src/pulseaudio -n -F src/default.pa -p $(pwd)/src/.libs/ -vvvv W: main.c: Couldn't canonicalize binary path, cannot self execute. I: main.c: setrlimit(RLIMIT_NICE, (31, 31)) failed: Operation not permitted I: main.c: setrlimit(RLIMIT_RTPRIO, (9, 9)) failed: Operation not permitted D: core-rtclock.c: Timer slack is set to 50 us. D: core-util.c: RealtimeKit worked. I: core-util.c: Successfully gained nice level -11. I: main.c: This is PulseAudio 0.9.19-562-g395da ... This will produce a lot of debug output, so you should leave that terminal running. The command line arguments are as follows: "-n" says "do not process the (system) default.pa". This is generally only needed if you have a ~/.pulse/default.pa file, but it does no harm to include it always. "-F src/default.pa" says to "process the script src/default.pa" and "-p $(pwd)/src/.libs" tells PA where to look for it's modules (i.e. from your build tree). Note that the state files saved by PulseAudio in ~/.pulse/ folder will very likely NOT conflict with your system PA's files. This is because our development PA build does not know the right path to look for /var/lib/dbus/machine-id. Because of this, the prefix used on files will default to the host name of your machine, not the string of apparently random numbers and letters that you may see in there already. If you cross reference, the output from cat /var/lib/dbus/machine-id will show the same number as used here. We do this to ensure we can have separate preferences for different machines when your home directory is shared over e.g. NFS - the machine-id is more stable than the hostname which is why we prefer that as a prefix. Running a Client App So now that everything is running, you should be able to run a client application. As the build tree comes with some utilities you can run them directly from there: [colin@jimmy build (master)]$ src/paplay -vv /usr/share/sounds/ia_ora-startup.wav Opening a playback stream with sample specification 's16le 2ch 22050Hz' and channel map 'front-left,front-right'. Connection established. Stream successfully created. Buffer metrics: maxlength=4194304, tlength=176400, prebuf=174640, minreq=1764 Using sample spec 's16le 2ch 22050Hz', channel map 'front-left,front-right'. Connected to device alsa_output.pci-0000_00_1b.0.analog-stereo (0, not suspended). Stream started. Stream underrun. Playback stream drained.: 1007045 usec. Draining connection to server. If, however you want to run a more advanced client application, then you need to employ a little hack to tell your system to use your development version of libpulse. This is quite trivial: [colin@jimmy build (master)]$ export LD_LIBRARY_PATH=$(pwd)/src/.libs [colin@jimmy build (master)]$ mplayer /path/to/your/fav.mp3 ... Easy eh? That's all you need to do to run PulseAudio from git. You can now easily try out patches, write your own modules and help contribute! Happy hacking. Some notes on Overlinking So, just before I sign off, I thought it was best to mention overlinking. PulseAudio itself uses a shared library that is used by both client and server. This library is "libpulsecommon-0.9.x.so". Client applications should NOT link to this file directly - instead libpulse will load it in for you. This can lead to some strange results. e.g. consider the following output: [colin@jimmy ~]$ ldd `which paplay` | grep pulse libpulse.so.0 => /usr/lib64/libpulse.so.0 (0x00007f5bd9fc7000) libpulsecommon-0.9.21.so => /usr/lib64/libpulsecommon-0.9.21.so (0x00007f5bd9d76000) [colin@jimmy ~]$ ldd `which mplayer` | grep pulse libpulse.so.0 => /usr/lib64/libpulse.so.0 (0x00007f617c1f4000) libpulsecommon-0.9.21.so => /usr/lib64/libpulsecommon-0.9.21.so (0x00007f6175f08000) This looks more or less the same right? Not quite. Compare this to: [colin@jimmy ~]$ objdump -p `which paplay` | grep pulse NEEDED libpulse.so.0 NEEDED libpulsecommon-0.9.21.so required from libpulse.so.0: [colin@jimmy ~]$ objdump -p `which mplayer` | grep pulse NEEDED libpulse.so.0 required from libpulse.so.0: So what you can see here is that my paplay really does need both, but mplayer actually only does not directly need libpulsecommon-0.9.21.so. But what does this mean to you when running things? Well, due to the fact that PulseAudio has this kind of circular dependancy internally, we cannot use the --no-undefined or --as-needed build options. This means that the PulseAudio package is Over linked. This is why the paplay utility needs libpulsecommond-0.9.21.so directly, unlike mplayer, which does not. So if you try and use the above guide and ultimately run the system provided paplay utility, you'll find you run into problems. This is because the system libpulsecommon-0.9.21.so will be used, not your freshly compiled version (which could have a completely different version number - e.g. libpulsecommon-0.9.19.so!). While we don't need to run the system paplay (as we have built our own version), it's easy to forget this quirk and break things. If you want to be sure, you can place a symlink in your build folder to fool the system into loading your libpulsecommon, even when the versions don't "match". As this is an overlinking problem, there is little danger in doing this hack: [colin@jimmy build (master)]$ ln -s libpulsecommon-0.9.19.so src/.libs/libpulsecommon-0.9.21.so [colin@jimmy build (master)]$ This puts the necessary symlink in place to make my dev build (0.9.19) replace the system build (0.9.21). This only has effect with the LD_LIBRARY_PATH variable set, so it wont interfere with anything on your system. Depending on your your distro packages things, the problems of overlinking may be present in more than just the paplay utility. So check this out and use objdump -p to confirm the client application you want to run is linked correctly and use the symlink hack if needed. Share and Enjoy: [Less]
Posted over 13 years ago
Well it's taken me a little time to commit this work, but here it is. This is the fruits of my labour from the KDE Multimedia Sprint earlier this year. As well as taking part in various discussions, I was able to spend some time cooking up a UI to ... [More] control the configuration of PulseAudio and the various cards attached.When adding PulseAudio support to the various parts of KDE that need it (Phonon, KMix), there was an important part of the puzzle missing: a card profile selector, and a sink/source port selector. I had always intended to include this functionality somewhere, but the KMix framework didn't really allow for it neatly (I could have created a separate dialog of course but it didn't quite feel right). The eagle eyed readers may have seen a sneak preview of this feature when looking at the KDE-specific help page I wrote up on the PulseAudio website. So I give you this: the Speaker Setup tab in System Settings. Speaker Setup GUI The little icon in the middle is your user icon, so you'll see this differently unless your a weird stalker type and have set your icon to mine :s The various drop downs allow fully control over all cards that are attached to the system. The buttons on the main pane allow you to test each speaker separately. In order to test the speakers, libcanberra is used. libcanberra is an implementation of the Free Desktop Sound Theme specification. It allows this test to be implemented with minimum hassle and I'm not personally interested in reinventing the wheel, hence the use of this library and the additional dependency.  Some people dislike using libcanberra in KDE (as was apparent from some discussions at the Multimedia Sprint), but I believe the reasons were often personal ones and not related to the usefulness of the code. If someone really wants to factor this out, they can but I have no interest in doing so and will prefer to use the existing implementation whenever possible (and this would include any future implementation I may or may not do with regards to support the Sound Theme Specification in KDE (or maybe Qt) directly) When a 5.1 surround system is presented, the GUI is obviously a bit more advanced: Speaker Setup GUI (5.1) For those naysayers, I've tried my best to ensure that the compile will work fine without PulseAudio installed. It should also degrade gracefully when it is compiled with PA support, but PA is not configured to be used at runtime. The whole tab will simply not be available. There is still one small problem left in that I don't handle disconnection/reconnection yet. This causes the GUI to crash if the PA server is stopped and restarted. This is not typically something that happens, but it's still something I will fix shortly all the same. This code is now in trunk (r1154776) so feel free to try it out and report other bugs etc. This GUI is also included in Mandriva Cooker (I did want to include it prior to 2010.1 release, but the timing didn't work out - tho' it probably would have been OK considering the delays that cropped up in the release process). I expect this functionality to be included in any updated/backported versions of KDE for 2010.1. For reference, in case you didn't spot it yourself, this GUI was heavily inspired by the gnome-speaker-setup utility. Share and Enjoy: [Less]
Posted almost 14 years ago
Well it's not really like that, but I guess those involved can think about it a bit like that at times!. For some background, Phonon is a Multimedia framework that was included in Qt 4 as far as I understand it, it was developed outside Qt, but was ... [More] adopted (please correct me if my history is incorrect here). It was designed to give application developers easy access to media playback systems, be it MP3 music or new fangled WebM video! Rather than implement any of the complex stuff itself, Phonon hands off the actual decoding and playback parts to existing media frameworks. Originally Qt wrote a GStreamer "backend" for Phonon and this was the only available backend on Linux in the early stages (others were available for other platforms too). I personally think that GStreamer was a good choice. I think it is a very powerful system, but it's not for the feint hearted. I wont begin to pretend that I understand it (although I have hacked my way through some GST code!), but the principle of it's operation seemed to fit the needs of the Phonon project very nicely. Sadly the GStreamer backend was plagued with some problems. I wont go into the details (primary because I don't really know them all!) but many KDE developers felt that it just wasn't appropriate and decided to write a Xine backend for Phonon instead (NOTE: This is not actually correct. Please read comment by Kevin Kofler below). This matured quickly, but it was always had it's own set of problems that resulted in many hacks to be introduced at the application level. This was very bad as it meant that those of us (Mandriva included) who stuck with and helped fix the GStreamer backend were sometimes left a little out in the cold due to these hacks. Ultimately this story has concluded with the Xine backend being more or less abandoned now, and renewed focus being put on the new VLC backend. VLC, or more accurately "VideoLAN", is a multimedia framework, very similar to GStreamer. It has a very well maintained code base and support for numerous codecs and formats. It is also totally cross platform, working with Windows, OSX and of course Linux and several embedded OSs to boot. Having a single Phonon backend with uniform capabilities and support across all platforms is very desirable, so progress with this is quite rapid and an official release of the Phonon-VLC backend will be available in a matter of weeks. But this is all about Phonon, not Qt Multimedia or Qt Mobility. So where does this all fit in? Well, Phonon has ultimately not really been developed much by Qt. That's not to say they have totally forgotten about it. I am assured that bugs reported will be looked at, time permitting, and that patches from downstream will be tested and merged, but it's fairly clear that it will not be actively developed further and no new features will come from the Qt side. Their new babies are Qt Multimedia and Qt Mobility. Qt Multimedia, and arguably to a larger extent, Qt Mobility has been developed with a strong focus on mobile usage. Now that Qt is owned by Nokia this is not surprising! So what was the motivation for this and how does it differ from Phonon? Well, like Phonon it also makes use of existing projects to provide the core media decode capabilities. It will continue to use GStreamer for most "linuxy" systems and others for e.g. Windows and OSX. It differs however with regards to focus. It encompasses several additional features regarding the various needs for a typical mobile environment, such as still image and video capture (think cameras on a mobile phone). There are several other key differences too but I wouldn't like to go into detail just now (I'm not really familiar enough with either Qt MM or Qt Mob to comment in any great depth), but suffice to say that this general abandonment of innovation in Phonon in favour of a new project has left several people in the KDE multimedia community feeling rather uncertain about what to do next; which horse to back! Here at the KDE Multimedia Sprint in Randa, Switzerland, we were lucky enough to discuss the various issues with the Qt Multimedia/Mobility guys in Brisbane, Australia via a video conference. Well it was supposed to be a video conference, but despite it being between two groups of multimedia geeks, video completely failed us (various firewall issues for one solution and the lack of admin rights at the remote end for another!), meant we had to make do with a normal phone call! Such is life! Anyway, they were kind enough to give us an overview of Qt Multimedia/Mobility and let us know their approximate roadmap. The outcome of this meeting was more or less that KDE Multimedia focus for the short term will remain with Phonon but the Qt guys will try and be more open about their plans and try and work better with the community longer term. At present, this is an uphill struggle as the VLC project has been very active in the KDE community for the last little while and seems to fit the needs in both the short and relatively long term of KDE, albeit in a way that is not currently exposed via Phonon API. This previous lack of communication is something that will be hard to overcome, but using a Qt integrated and supported solution definitely has advantages in the future - if they really mean it this time! The fact that the code is also used on Nokia mobile platforms give a fairly good reassurance that this will indeed be the case at least! The rather obvious question of "Why not extend Phonon?" was also raised. While it was difficult to hear exactly the responses, the general reasoning seemed to be that there were some design mistakes in Phonon that basically meant that each individual feature that needed to be added, actually needed to be done at the backend level first (for each and every backend) and then exposed out through the API. With the Qt Mobility approach, more of the core features and functionality can be implemented once, with it only reaching out the the underlying platform specific system for specific and defined operations. We enquired about the possibility of having a single Qt Multimedia backend written for Phonon, that allowed the Phonon API to continue in use at the application level while using the underlying systems/framework provided by Qt Mobility and/or Multimedia and deprecating all other Phonon backends. This is attractive in the sense that applications to not need to change horses mid stream and can gradually move over to using a pure Qt Multimedia API if indeed that is determined to be the most desirable outcome. That said it is also unattractive in some ways too. This adds yet another layer of abstraction to a system that many people argue is a layer of abstraction too far in itself! i.e. Application uses Phonon which uses Qt Multimedia which uses GStreamer; Why not just Application uses GStreamer? (there are of course many reasons to add a layer of abstraction; cross platform support being a primary one; but two layers is arguably not the best situation, especially on mobile platforms where wasted CPU cycles really hurt). That said, it would still be an acceptable stepping stone for most people. Regardless, there was no actual commitment to this eventuality from the Qt side. It was seen as a good idea but it's likely not something that there will be time (aka budget) for developing in the near term, which is understandable. Many of the problems with Phonon still remain however. Qt Mobility will still require the setup of different underlying support libraries on different platforms. Just as before, GStreamer will be required for it to work on Linux and downstream (distributions and, to a lesser extent, users) will need to ensure that this is all configured and working correctly. As with the original Phonon, this backend will be different on different platforms, which is not ideal for the downstream. So in the short to medium term (e.g. the next one to two years at least), Phonon will continue to be the primary media framework on KDE, and development on the Phonon-VLC backend will be seen as the best way forward to provide a standard experience across all platforms. GStreamer as a phonon backend will also continue, although the mplayer and xine backends should be considered deprecated. With regards to Qt Multimedia and Mobility development itself, the Qt guys will try to be more open; opening a private mailing list to more access and generally being more communicative. Those of you who regularly read this blog will be no doubt wondering where the PulseAudio connection is. Well, from what I gather, this is a primary difference of Qt Mobility and Qt Multimedia. Qt Mutlimedia seems to use ALSA directly and thus is not ideally suited for mobile situations (PulseAudio's timer based scheduling now being pretty much universally accepted as being the preferred approach on mobile platforms). Qt Mobility does actually use PulseAudio indirectly via GStreamer, but it does not seem to do anything special with regards to the "buffer-time" or "latency-time" attributes of the pulsesink (not that pulsesink is actually referred to directly in the appropriate place anyway from what I can tell). These attributes map directly to the tlength and minreq attributes of the buffer metrics in a PulseAudio stream. These are very important when it comes to mobile environments as the general aim is to provide as high a latency as possible. Higher latency means lower power usage (and for those wondering, this does not necessarily affect A/V sync on video playback - it's just about how much data you pump into the audio buffers before sleeping until you know it'll be almost empty). For a system that deals with audio playback on a mobile device, this is very important. Now Phonon is also similarly ignorant to these properties when using PulseAudio. The the help of folk from Intel we're going to look at increasing the defaults in Phonon when used with GStreamer pulsesink to see if higher latencies would bring benefits without any drawbacks at the application level (I don't think any of the uses of Phonon will have problems with this approach), but we'll also have to consider how best to expose this via the Phonon API to allow the application level to state more explicitly if this matters. When capture APIs become possible on Phonon this will become important. The whole question of how much thought has gone into this kind of power saving is Qt Mobility is still very much at the forefront of my mind. I hope to be able to discuss things in more depth with the developers in due course, hopefully influencing them to extend the API in a similar was as described above. More generally, those of us in the KDE community will try to get involved with Qt Multimedia/Mobility but until such times as it is easily configurable on the Desktop or there is a Phonon backend based on it, it will be hard to get involved too deeply. Overall I think everyone has an open mind, but with the current focus on VLC and the functionality it provides, it will be the most interesting bits for most KDE Multimedia guys for the short term. With regards to all of the above, I hope I've made fair and levelled comments. If you feel this is not the case, please tell me so in the comments below. I will happily retract or rephrase or reconsider any point if a suitable argument is made. I do not intend to represent anyone else in the KDE community in a way they do not feel is accurate so I'll be happy to both comment and edit the article with suitable annotation if this is deemed necessary. Edits: 27th May: Clarification of my incorrect statement of when/why Xine backend was introduced. Thanks to those who pointed it out. Share and Enjoy: [Less]
Posted almost 14 years ago by [email protected] (D.)
It's an annoying topic. Not many USB surround sound cards exist anyway, even less of those are good ones. But after an hour of searching the web and reading various articles, I've finally found a USB surround sound card that works well in ... [More] Linux:Terratec Aureon 5.1 USB MK-IIUsually the problem is that terratec's drivers are not too good. Luckily, the Linux drivers are often excellent due to the open source community's investments in them. And here the case is similar: Terratec was smart enough to use the standard USB interface, so they need not write drivers for any OS and the Linux USB Audio driver works perfectly - already for a long time.But German reviews on Amazon suggest that the digital output does not work with surround sound, but only stereo. This means it's just an option if you want analogue sound."Enforce USB bandwidth allocation (EXPERIMENTAL)" must be deactivated in the kernel.If you still need some help with the setup, e.g. for games, try this page.If you want a really good USB stereo sound card with digital out for Linux (cost " 20 €"), and you're up for some work, here's a German guide how to build your own.But according to German Amazon reviews and this website, the Creative SoundBlaster X-Fi Surround 5.1 USBis also supported in Linux - at least for stereo. A German guide is in the Ubuntu forums, but it seems it should work with any current Linux.Both cards have driver issues. It seems the Creative card doesn't work well in Vista x64 (no/bad subwoofer sound). I think in the end I will decide for the Creative card anyway. It's much newer and probably has better sound than the much older Terratec box.(...) -- Click to read the entire post. [Less]
Posted almost 14 years ago
pulseaudio: Spinal Tap FTW! We're trying to decide on a standard for software amplification and the current thinking is 11! (dB that is!) (by Colin)
Posted almost 14 years ago
pulseaudio: Latest PulseAudio+Phonon+Amarok+KMix support info+screencast: http://colin.guthr.ie/2010/04/slide-around-the-sound/ (by Colin)
Posted almost 14 years ago
Just a quick update on various KDE PulseAudio changes I've made recently. This is more of an update from previous articles than anything ground breaking in it's own right although there is a nifty (IMO) new feature now available. Firstly, it was ... [More] pointed out to me that the use of a QEventLoop was not the best approach when connecting to PulseAudio from a KDE app. I used this technique in Phonon and while it seemed to work fine in testing it did trigger some problems in some unlikely places: namely this bug as reported against Okular! So I changed how the connection test to PulseAudio is run to make it blocking. This has so far appeared to fix the problems \o/ Now on to something interesting I've recently added support in Phonon for "hijacking" the volume change requests to allow them to be pushed directly to PulseAudio, totally avoiding the backend itself. In additional it is possible to listen to changes from PulseAudio and then emit the relevant Phonon signal to let applications know the volume has changed. This allows volumes changed in a PulseAudio mixer (pavucontrol and now KMix too!) to be reflected in the Application GUI (should it present it to the user). Phonon provides it's own VolumeSlider widget that applications can use. I had to make some changes to this to avoid some complicated race conditions. As volume changes in PulseAudio are asynchronous, the change request may be followed some time later by the actual update notification. For this reason the it was not possible to use the "traditional" blockSignals(true) approach. I settled on two flags to achieve the necessary protection and it seems to be working well so far in my testing. Then I tested Amarok and found it didn't work at all This is because Amarok has it's own volume slider widget and does not listen for any volume changes from the Phonon layer. I was able to make the necessary changes to support this without too much trouble, but in doing so I had to change the mute behaviour slightly. Due to (I'm told) legacy reasons, when the volume is muted, Amarok would also set the volume to 0. This was reflected in the GUI by the slider showing 0. While it would be possible to keep this behaviour it's not really desirable these days (the OSD always said "Volume: 0% (muted)" when muted which made it rather redundant to show the %age!) when mute is supported properly. If GUI feedback of mute status on the slider itself is desired (the image does change to a mute symbol already) then it would likely be more appropriate to change the slider colour to grey or similar (which is also how other media players - e.g. VLC represent things). Anyway, with these issues fixed and suitable support for the feedback race conditions added to the Amarok slider code too, I've now got a rather nicely integrated solution Here is a quick screencast I recorded to show you how all these changes: Phonon, KMix & Amarok all work together (direct link) As always, these latest changes are in Mandriva Cooker. The Amarok changes are not in the 2010.1 Beta 1 just recently released, but they will be part of Beta 2 Share and Enjoy: [Less]
Posted about 14 years ago
pulseaudio: Some background, thoughts and musings on mutli-device audio stream routing in PulseAudio http://tr.im/Oc5q (by Colin)
Posted about 14 years ago
So I would like to take a few minutes to talk about audio routing in PulseAudio. This is a oft misunderstood topic and it does sometimes seem like black magic and/or broken but, as always, it's pretty simple when you look at it properly. That's not ... [More] to say it's sensible (I have a several reservations about the current way of working), but the first step to improving something is understanding it, so I'll try to explain here and then say what I think is needed to improve it. This is a rather complex and in depth post, so if this kind of stuff doesn't float your boat, it's a good candidate to skip :p So how does PulseAudio route your audio and what the hell do you mean by "audio routing" anyway? Well, PA handles multiple audio devices ("sinks" for output, "sources" for capture). When an application wants to play sound it says "Hey PulseAudio, play this!!", and PA tries it's best to comply. The application will typically not care about which device to actually output too - they delegate this job to PA (and ultimately to the user via PA's tools such as pavucontrol, gnome-volume-control and (more recently) kmix/phonon too). These tools allow you to move the stream to your preferred sink - no need for an unfamiliar GUI inside a particular application for choosing which audio device to use; users know where to look in their desktop environment to control sound settings. From an HCI/usability perspective I think this is very important (although incumbent users need to shake of their natural assumption that apps should provide a way to configure audio device settings). With a fresh user account PA will attempt to calculate a suitable default device to use. It does this by assigning each sink an internal score of appropriateness. This is just to determine our initial defaults so it doesn't matter too much if we get this wrong, but obviously it's nice to try and get things right first time! So once our default device is chosen, when a stream is played, it will use this sink. Simple huh? Well not quite. What if I change the default while a stream is playing? My stream is moved across to the new default right? No. Setting the default device does not do this. It acts as a fallback, it's not an "active" default. If I stop my app and play it again, it will be played on the new fallback, but it wont move when the stream is "live". Now this is just the very beginning so if you've become overexcited by now, best take a cold shower (and probably look up psychiatrists in the phone book...) as I'm about to move on to look at the "stream restore" database... Stream Restoration So the stream restore database is handled by module-stream-restore (m-s-r). It's part of the default PA install so 99.9% of users are likely using it. What this module does is to track when a user specifically moves a stream to a new device. When the user uses e.g. pavucontrol or kmix to move a particular stream to a new sink, this triggers a mechanism inside m-s-r that causes the sink name to be saved for that application. If that application appears at any point in the future and tries to play sound, m-s-r will try it's best to ensure that this sink is used. If the device is not currently available, we will ultimately use the fallback/default instead. If this saved sink becomes available at some point during the lifetime of the stream, the stream will be moved across automatically (which differs from the behaviour when setting the default sink). Now it gets complicated. Despite my terminology above, m-s-r does not use "applications" per-se when it saves the device choice. It will look at a stream and select a "stream restore id" for it based on several bits of metadata attached to the stream. Firstly it will look to see if the stream has a role. If it does, the role is used as the identifying factor, not the individual application. So e.g. for event sounds, the "stream restore id" will actually be "sink-input-by-media-role:event" regardless of which application actually produced it. As m-s-r is responsible for storing volume, mute and device preferences, this means that all event sounds will have the same volume and will be played on the same device. If the stream does not have a role, PA checks for a few other things to try and create it's "stream restore id": it checks for an "application id" (a specific property set AFAIK only by a select few applications), an "application name" (which 99% of PA clients provide) and finally it checks for a media name property (which is pretty unlikely IMO, although I may have missed a use case here). Once the "stream restore id" is chosen it is saved for that stream and we will always use this rule when updating our saved volume, mute and device settings thereafter. When a user moves the stream (using one of the afore mentioned GUI apps - or via any app that makes use of the pa_context_move_sink_input_by_*()  APIs (also applies to source_outputs)), the "stream restore rule" they are ultimately changing will depend on the metadata the application has provided PA in the first place. So for example, Amarok will be tagged with a "music" role, and thus when you use kmix to move the Amarok stream to a different device you are not just moving Amarok, you are actually moving all streams tagged as "music". (Update 1) But wait! It does not actually move the currently playing "music" streams. They will only be moved the next time a PA stream is created (this could be when the track changes, or it could be when the app restarts - it depends on implementation), or when the stream restore database is written by some PA client which requests the "apply_immediately" flag set. This whole approach can be summed up with two flow diagrams: Device Manager OK, so that about covers m-s-r, now I'll talk a bit about module-device-manager (m-d-m). This is a module I developed principally for integration with KDE. The GUI exposed for the Phonon preferences in KDE is such that it lists all devices that have ever been available on the device even if they are not currently available. This allows them to be listed and arranged into a priority list. Whenever the highest priority device is available, it will be used. It's a relatively simple UI and one that users can easily understand and work with. For a degree of flexibility, the GUI allows for different priority lists to be configured for different Categories (which in PulseAudio terminology are called Roles). So m-d-m provides an API and Protocol extension to implement such a routing policy directly in PA which turned the KDE GUI effectively into a frontend to PulseAudio (internally this is abstracted via Phonon but this is not really important). So this m-d-m will route your audio for you to the appropriate device. Due to how it is implemented, m-s-r will still take priority, so if you move a particular stream and the device choice is saved by m-s-r, it will take priority over the role-based priority list of m-d-m. I have now provided a way in kmix to delete any application specific rules in m-s-r such that the m-d-m routing (and thus what is displayed in Phonon preferences) will be used again should an override have been in place. Critique Right so that's how things work. Now let's rip it apart and moan a little about the shitty bits. A default that is not a default: First things first. This is a question we get a lot: "I've set my default device but <insert victim application here> doesn't want to use it". Now that you know how the routing works due to the excellent overview above, you can probably work out what's going on here. Either m-s-r has a specific device saved for that application's role or the application itself, and that overrides the "default" choice; the user was playing the stream when they set the default device but this wont be honoured until a new stream is created; or m-d-m is implementing a role-based priority list preference (which in all cases overrides the default button due to having a priority list for all cases - one for each role and one for the default case). All of the above is flexible but it sure as hell is not clear to the user what the hell is going on. There needs to be some kind of unification and automatic reaction here. Having a simple "default" button IMO makes sense. It's a very easy concept to grasp for users and we should try to make it work in the most case and explain more clearly in the various GUIs as to why it may not work in certain circumstances. Why, Why, WHY?: Things are not clear to the user what is going on. In a typical setup we have m-s-r and it remembers one thing. Unless you know how it works, you cannot configure a scenario when you have three or more devices and have it "just work" for you. For me three devices is not uncommon. At work I have set of USB speakers I use and at home I have Airtunes and network-based PA servers I use too. I want them to "just work" without me having to fire up a GUI every time I want to use them. A primary problem just now is that unless you've taken the time to read and understand the above descriptions, it's very unclear to users as to how the default device works and what m-s-r does and how it operates. Clarity and transparency is needed here, or some way of making it "just work" without needing such and explanation. You gotta role with it?: Yes that is a rather contrived "problem", but the point is valid. As we go down the path of encouraging applications to include as much metadata as possible in their streams, assuming we ever reach such a zenith, then the ultimate end result is that all streams have their role specified. When this happens a fundamentally useful part of PulseAudios design is effectively crippled in the default setup: m-s-r will always pick it's stream restore id of "sink-input-by-role:fooo". All application's will no longer be able to chose their own individual audio device; you will only be able to pick the device for that whole class of application. All music players must go to one device. All video players to another, but nothing in between. Some applications set their role generically but can be used for other purposes e.g. totem/dragon are video players but may be being used for just music in a given instance - I'd like to use my preferred music device not my preferred video device but I don't want to affect all video players with this choice. Obviously it's better if a multi-purpose app can work out it's role dynamically based on content but the principle point still stands - you cannot move streams anymore (with the exception of the afore mentioned caveat for currently playing streams when the move is initiated), only whole classes of streams. Some may argue that this is OK/acceptable. Personally I don't think so. I don't want an override anymore: Say you've picked an override for your stream/role with m-s-r. Say you've now decided you don't want that override and just want to use the default device now? None of the GUI tools out there just now allow you to reset this (with the exception of the latest kmix in my Git Repository at the time of writing). How do you solve a problem like Myrouting? So the above problems basically make things a bit too much like a black box. It's not clear what's going on and it doesn't offer enough flexibility in many cases either. How do we solve this? I'll now outline what I think is the best possible implementation of a routing system and how it will work. Overall Operation Firstly we need to remove the internal concept of a single "default" device. As we've discussed before within the PA community, we will move to a priority list concept. A significant difference to the KDE approach of showing the device priority list for users to tweak, we will ensure that exposing this list is not a strict requirement for operation. In order to service this requirement we will still offer the existing UIs for setting the default device, but the internal behaviour will change. Setting a device as default would simply move it to the top of the priority list. This will ensure that simpler UIs can still operate and whenever the user prefers a device above other others they just set it as default. In order to get the perfect priority list, they may have to click the "default" button a couple of times with a given setup, but it will stabilise for them very quickly (for reference, this default priory list will be the equivalent of the current m-d-m priority list with the psuedo-role: "none"). As well as the default priority list, we will also implement similar lists for each role (again very similar to the current m-d-m role-priority lists). When a stream has a role, we will simply use this list rather than the overall default one. If a given role does not have a priority list of it's own, the default one will be used (in KDE the phonon GUI will likely enforce that a list exists for each role, but has GUI techniques to keep it in sync). In addition to the above, each individual application will also have it's own priority list. Again this is fully optional. If such a list does not exist, the role-based list will be used instead, ultimately falling back to the default list if no role is present. When a new device appears it will be added to the default priority list only. It is open for debate as to where this device should appear in this list - top or bottom, but this could ultimately be a user preference. The routing logic should ultimately check the most appropriate list first, try to find the highest priority device in the list that is currently available. If none are available it will use the next most appropriate list ultimately falling back to the default list which will always contain an available device. New APIs New APIs will be made available (either as extensions or baked in - details TBC). These APIs will allow the querying and editing of these priority lists (thus facilitating GUIs such as the one in KDE). When editing these lists the changes they reflect will always be immediately applied to any running streams. APIs will also be exposed to delete a  role-based list or an application specific list (NB the application list could potentially also be cleared via the existing APIs by passing PA_INVALID_INDEX or an empty or NULL device name). Existing APIs The existing APIs for setting the default device and moving a stream to a given device will still operate as just now but will operate differently internally. As mentioned previously, setting a default device will update the overall default priority list. This change will be propagated to any currently running stream immediately. Thus a fresh user account with no priority lists saved, the default priority list will be used for all streams. Clicking on the default device will move any running streams to that new device. And thus the very basic use case will operate in an intuitive way. If a user moves a specific stream to a new device via the (pa_context_move_sink_input_by_*()  style APIs) this will trigger the update of the application specific priority list. This is a stark change to the existing behaviour which will update the details for the currently used device choice mechanism. If the priority list for particular role is to be updated by a given GUI application, then the new APIs above should be used to achieve this  result. If a stream is moved and it does not yet have it's own priority list one will be created for it automatically (containing only the chosen device initially. GUIs So what can the GUIs show? Well there are a lot of options now: A very simple GUI which just shows a list of devices and allows a single default to be shown. A more complex GUI that shows all devices in the default list and allows the user to order them. One that shows both the default and the known roles and allows a default to be chosen for each (or expose the full list for user ordering) etc. etc. (FWIW although it's possible I don't think it would be necessary to ever expose the per-application list although there should be a method for indicating that such a list exists and is in use and allow the user to delete it and user a higher level priority list). Caveats With regards to event sounds specifically, we want to make sure that these are handled differently to a regular stream produced by an application. For example I may want to use rhythm box to output sound to my Airtunes device and implement this via an application specific priority list. Any event sounds for this should not be pushed to this device. I'm not sure what the best solution to this conundrum is, but I suspect that a simple property set on the stream that says "do not allow per-application priority list updating" would be sufficient. This still allows streams to be moved to the device, but this wont be saved for later restoration (obviously moving an event sound is really hard due to their duration, so this logic is more for the principle rather than the practicality). (Update 1) As I propose to apply changes whenever they happen if you run e.g. two paplay processes at the same time and change one to use a specific device, my logic dictates that both streams would be moved. This is a regression on the current behaviour where only when the stream is restarted will it be moved, but to be honest I don't think it's much of a problem. If it is desired to have specific control over a given instance of an application, then we need to either a public API to not save the move (much like our internal one), or support a proplist property that suppresses this (e.g. no API change but a loose "standard" for performing this type of operation. If you want to run an application in a specific way, then you can always set a property for the e.g. the "application id" as mentioned above which would make it appear as a unique application compared to running it normally. So flexibility still exists here (albeit rather complex), but we probably do want to deal with the default cases well and make the more niche ones possible via some degree of extra work. Overall OK, so this is quite an exhaustive proposal and I've not nailed down the exact best way to implement it, but I think that this approach is ultimately the most flexible possible that supports all of the interfaces desired and still exposes the flexibility of the PulseAudio system. I have not given much thought to the storage of volume/mute status (which m-s-r currently tracks along with it's single device preference).  My gut feeling here is a fairly similar approach where you should be allowed to set the default volume, a per-device volume and a per-application volume. The former two being used as defaults and as soon as the per-application volume is changed via any API call, we save it with that specific application for future reuse. APIs can set the default volume and the per-role volumes and this will be propagated to applications that do not have their own specific override in place. So in summary, this is how I think things should work. I don't think it's actually as complicated to implement as I've made it sound (would probably only take about three or four times as long as it's taken me to write about it!!) and I believe it keeps the power and flexibility of the system, still allows for minimal control interfaces yet allowing more exposed and complex ones if required. Updates: [1] 16th Feb: Add notes about how moving a stream with a role does not move any currently live streams and how the proposed solution would prevent running two instances of the same app and moving the device independently for each (as one would follow the other) unless the application id was overridden for one of the instances. Share and Enjoy: [Less]