Colin.Guthr.ie Illegitimi non carborundum

14Feb/1028

This is the route to hell

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 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:

Diagram of the initial stream routing process

Diagram of what happens when a new device becomes available

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:
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • Identi.ca
  • Slashdot
Comments (28) Trackbacks (0)
  1. This thing consumes about 10% of CPU when listening to the music or playing a game. Avoid this at all costs, please. At least, till it will become not CPU consuming.

    • If the CPU is consuming 10% on your system then you are perhaps using one of the more advanced (and thus CPU intensive) resamplers in PA. There are several different resamplers available with varying quality vs. CPU trade-offs therein.
      Alternatively, it could be that the ALSA drivers for your h/w are not giving accurate timing information to PA (this is quite common, although most drivers have had updates in this area over the last year or so – if it is at fault here, you should report it to the ALSA folk via their mailing list).
      On my system PA consumes ~0% CPU when playing music (it can vary but is usually listed as 0% or 1% in top with 0% shown more often than 1%), so this is not something that is fundamentally broken in PA.
      But thanks for spreading disinformation… we really can’t get enough of that!!

      To everyone else, please can we keep comments on topic? Thanks

      • I have a new PC, Gigabyte board with on-board audio, and a Phenom II x3 CPU. Top shows pulse-audio using 5-8%, system monitor shows it as just 1 or 2%. Top shows pulse-audio as second only to Xorg in total CPU time used. The PC has been running for 13 hours, but I only just launched Audacious to play a folder of music. PA quickly came from nowhere to be second in CPU usage. I have not changed any settings, this is the default. Same as many others see and scream about.
        Colin, your article was informative. But I still don’t see how PA justifies it’s drain on the CPU.

  2. Great post. It’s really nice to be able to understand some of the problems you’re dealing with, and I think your approach sounds pretty sane.

  3. An enjoyable read. I appreciate your precise and well-written explanations of what can sometimes be a confusing system – thanks for your contributions to the community!

  4. Very interessting. Thank you for the detailed explanation.

  5. Oh this is an awesome post, I hope KDE is the first to fix this complex problem through an awesome GUI

  6. A good read that has definitely made me more informed about how PA works currently, and how it might work in the future. Also and again very happy to hear about your KDE PA work.

  7. I like your ideas they make a lot of sense, please implement them :)

    The concept of priority lists is very nice, your ideas as presented above is exactly what I want to be able to do!
    I can think of lots of examples where I want to move one application from a role (music) to a specific device but not all.

    One additional thing I would like to see is the possibility to manually “turn off” a device, forcing all streams to use the next one in their list. The obvious example is a laptop, at home I want it to play some things on the internal sound card (to the laptop speakers), and some on my usb headset, but on for instance a train I want to “turn off” the internal sound card forcing all streams to play on my usb headset.

    • Thanks :)

      Generally speaking it is possible right now to “turn off” a sink or a source by choosing an appropriate profile from the “Configuration” tab in pavucontrol. All cards should have an “Off” profile which would basically achieve this result :)

      • Yes that does what I am looking for. Do you have any plans to implement a similar configuration tab in kmix?

        • Well I was reckoning on including the equiv of the Configuration tab in a KCM that would be available as an extra tab in the System Settings -> Multimedia. It’s more of a config thing than an every day thing so would prefer to keep it away from kmix for that reason. pavucontrol is kinda the down and dirty, big bulky do it all client and the Desktop Envs should really do a bit of pick and chose to provide users with the appropriate level of UI IMO. Comments welcome on this topic but I think it’s the right way to go :)

  8. @Colin

    Thank you for your response. I was using PA some time ago when I had Ubuntu. I didn’t spread dissinformation, because it seems it was something wrong with it in Ubuntu (according to your comment they most likely set advanced resampler as a default one) and it seems Ubuntu should be blamed. If it’s only a matter of choosing a proper resampler then I’d love to have PA in my system.

  9. Thanks for explaining. I have a “hate-love” relation with PA. When it’s working then it’s super cool but if you having a problem it’s hard to fix (even for me :)) because it’s a complicated piece of technique. But i have faith things will come together on the end :)

  10. Isn’t the easier and more clear (to users) solution to make phonon default to alsa and not pulseaudio?
    It just adds a lot of (user visible) complexity and I have yet to see any advantages over what Phonon already does just fine…

    • No because if phonon on it’s own was used, this would only solve the audio problem for Phonon applications. That’s probably about five or six applications in mainstream usage. Compare this to the vast majority of sound applications that are available on Linux. The world does not revolve around KDE and if we are to offer a complete sound solution the problems have to be solved at a much lower level in the stack than phonon. It’s important for KDE that phonon integrates with this lower layer as seamlessly as possible.

      • 5 or 6 in mainstream usage? Hmm, I think you are seriously selling this short.
        Phonon is a Qt technology, not a KDE technology, so that point is also not true.

        But lets not make this a phonon vs pulseaudio. The question was why use pulseaudio on top of Alsa while Alsa alone works just fine.
        Your answer is that it then works for apps like ogg123 too, and thats a sane answer.
        But that doesn’t actually answer my question of why not stick to Alsa. What does pulseaudio bring that Alsa doesn’t.
        Again, the PA may look nice on the drawingboard (well, your blog puts some doubts there too) but in real life it doesn’t seem to actually add any benefits. Just headaces.

        • I’m not sure I would justify the CPU usage, but there are several factors at play here: 1) Resampling is now done in PA not the app, so a CPU usage shift will be apparent. 2) PA uses a reasonably good resampler by default (which has the trade-off of higher CPU), 3) Driver bugs may result in causing PA to enter it’s busy loop much more often than it should thus driving up CPU usage. 4) Connecting clients (like pavucontrol) which put a latency requirement on streams for visualisation (e.g. vu meters) will cause PA to wake up more often than it needs to and use more CPU (tho’ this should be pretty minimal), 5) Some rogue PA clients may be requesting information constantly and keep PA’s usage higher.

          What I can tell you is that on my hardware (a 4 year old Intel C2D 64-bit with HDA h/w) the CPU is never more than 2% from what I can tell, with the typical case being 0%, sometimes creeping towards 1%, so I suspect that your higher CPU usage is indicative of something specific rather than some endemic. Find the problematic part and fix it. That is the right way to work with Open Source, not saying “this sucks because it doesn’t work for me right now”, but saying, “OK this is neat but this bit isn’t idea, what can I do to make it better”. If you don’t like it, fine, don’t use it, but if you don’t want to play the game, don’t be surprised if you don’t get much respect from the players when shouting from the sidelines.

          With regards to Phonon, I’m sure you’re right that there are more applications than that overall, but I did say “mainstream” usage. Maybe my definition of “mainstream” is a bit harsh, but regardless of the numbers I don’t think there is any disagreement that Phonon covers a tiny minority of sound producing applications on Linux. That is/was the crux of my point.

          The fact that you mention phonon vs. pulseaudio is really quite funny. I know both code bases pretty well (look for me in the commits of both) and they are so completely different and target such completely different areas of the audio stack that to compare them is really quite ludicrous which is why I never do! Also while I agree it is a Qt technology, there has also been very little by way of integration work done by Qt people on this. I’ve personally worked rather hard to get good integration with PA and this is done in the KDE version of libphonon. It’s not been taken on by the Qt version yet despite it being available for 6+ months. So it can’t really be called a Qt- technology if all the KDE distros out there basically reply on a KDE fork of phonon. In short, it’s a bit of a mess. It’s fine if you know the rules and where to get package xyz from, but for a general user it’s pretty tricky. I suspect the lack of impetus from Qt on Phonon is that they are already planning the QtMultimedia stuff which will ultimately replace it. With the join up of Maemo and Moblin announced recently I hope that there will be more direct engagement with PulseAudio from Qt directly. Intel is alreay committed to PA on their embedded platforms and this tie-up will hopefully help cement this and provide better Qt support.

          Back to your point about alsa being enough on it’s own, I strongly disagree. I thoroughly believe that some form of userspace component is needed to drive desktop audio. From dealing with multi-user and multi-seat issues to dealing with sound from remote X11 applications; from interfacing with bluetooth headphones, amplifiers and headsets to hot-moves of streams; from dealing with device hotplug in a sane way to powersavings from the timer-based model, there are numerous things that are simply not possible with alsa on it’s own and are enabled by PulseAudio.

          This blog post is not about discussing that and, as I asked in an earlier comment, I’d like to keep the posts on topic. If you want to talk more about alsa vs. PA then please comment on my earlier article that is much more relevant and contains much more detailed reasoning: http://colin.guthr.ie/2009/08/sound-on-linux-anti-fud-calm-certainty-and-confidence/

  11. I basically like pulseaudio, but for most (basic) users it is way too complicated to be used remotely. I have this setup, a networked amplifier talked to via pulseaudio rtp. It just works for all apps using pulseaudio (which is basically everything except wine these days). But it gets cumbersome as soon as I want remote sound (the amplifier accepts only streams from one ip and mac address). I would like to see something like remote graphics, you just set DISPLAY variable and if the server is reachable you’re done. This is simple and even works seamlessly through several connected ssh sessions. Now just introduce a similar variable for sound (name SPEAKER or just SOUND) with the same syntax and it would ease work a lot.

    • What you describe (something similar to DISPLAY variable) is already fully supported. We actually piggy back on to this variable already. All you need to do is enable the relevant option in paprefs and it will follow you when you ssh with X forwarding enabled. For more info, see my earlier post: http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-2-pulseaudio/

      • Yes, it works. But not as easy and transparent as remote display. PULSE_SERVER is not as easy to remember and understand (especially for novice users) as SOUND or SPEAKER or even DISPLAY and it is too technical a term. And you don’t (yet) get the automatic advantage of the ssh tunnel, you have to set up the tunneling yourself (as direct access, especially with a vpn between, will not be possible always) which can be difficult if the remote sshd configuration doesn’t allow tunneling other than X11. And I noticed Solaris and MacOS X (don’t know which version) sshd tends to sometimes drop tunneled connections if there is no transfer for a long time, even with timeouts set to off. This never happens with the x11 tunnel, even after weeks of idle time.

        • Yes I agree that it would be very nice to teach ssh how to forward PA sessions just like it currently knows how to forward X11 sessions but for most private networks, just piggy backing on to X11 for the connection variables and authentication details is the next best thing. Most people don’t have to remember any details or even know that the PULSE_SERVER variable even exists. The only time a user would need to know about this variable is when they go outside the local LAN. Yes I agree it’s not ideal but someone will need to champion ssh support and due to it’s nature, I’d imagine the QA process is pretty tough.

  12. It sounds like you have considered most of the concerns for SINKS. What about SOURCES? That USB connection to my MIDI keyboard, motherboard connection to Mic and Line inputs, USB Sound card, CD/DVD and Blue-Ray players, and TV tuner card that never seem to line up so they can be used properly?

    I can usually get the playback devices to work, but not to route them to recording programs.

    I have almost no experience in getting PA to work in KDE, mostly working in GNOME and LXDE, maybe KDE doesn’t have this problem. Mostly I drop back to M$ Window$ for recording, not because it is simpler, but because I have more experience in that environment. I am trying to go straight Linux (either Ubuntu or Debian), but this stops me.

    • Pretty much all I described will also be available for Sources too (I tend to just “say” things about playback as it’s easier to grasp it as a concept but I’m very much thinking about sources too. It does get a little more complicated as for a lot of sound cards, Line in and Mic in are mutualy exclusive – i.e. you cannot sample the mic and record from line in at the same time. We solve this currently by the use of profiles and ports. A given card profile will ultimately make a set of sinks and sources available for a card. In theory a card can provide two independent sources for Line in and Mic and thus they would appear in the priority lists independently. If the card does not allow mutual configuration, then a single sink will be created but a list of “ports” can be provided so that the user can pick which one they want. to use. Currently the priority lists idea does not take into consideration the port of a sink or source. This means that Line in would always have the same priority as Mic in and likewise Speakers output would always have the same priority as Headphones out. This may be a problem, but in practice can be solved by storing the device name+port as a pair in the priority lists if this is deemed necessary.

  13. You are doing an impressive work in PulseAudio, thanks!

    I have a little question about module-device-manager. Is there any way to set the priority of each device in the startup script, or in a system wide configuration? Maybe I missed something, but I looked for it a few months ago when I installed Mandriva 2010.0 and found nothing.

    This is my scenario, using Mandriva 2010.0 and KDE: I have two sinks, one for the soundcard in the motherboard, and another for the HDMI output in my graphic card. The highest priority device should be the soundcard. However, when I create a new user account and check the device list in Phonon settings GUI I see that the HDMI output is at the top. I have to explicitly move the soundcard device over the HDMI device to get sound.

    Of course I don’t create users too often and doing that initial configuration isn’t a big deal, but when using xguest session (which uses a fresh user account every time it is started) it becomes a bit annoying. So, can the priority for each device be set in somewhere like /etc/pulse/default.pa? Thanks for the information.

    • That is almost certainly “my bad” with module-device-manager. I think I probably add all the sinks into an empty list in the order they are kept internally (which is random) rather than their internal computed priority (which is a set of hard coded rules as to which one is “best”, but will typically do a pretty good job and thus avoid the need for any manual tweakage) which should provide sensible defaults. I’ll make sure I look at this. Thanks for bringing it to my attention :)

      (Of course you could still include the database file for module-device-manager in your /etc/skel if you really wanted a custom default, but it’s probably not worth it!)

  14. defaul device
    I feel that it is natural not to move existing streams when the default device is changed. Obviously the user is comfortable with the current setup and if a default device is plugged in, wouldn’t want the stream automatically move to this new device, especially if using headphones.

    stream restore
    Just for clarification, when moving the stream via pavucontrol the changes take place automatically because “the stream restore database is written by some PA client [pavucontrol] which requests the “apply_immediately” flag set.

    As for “I don’t want an override anymore”, I agree. Wouldn’t it make sense, if moving a stream to a default device, simply to remove the override?

    I really like you proposal and feel that it is more “natural”

  15. Oh and about the CPU consumption comments, I too have have similar problems.

    You mentioned “it could be that the ALSA drivers for your h/w are not giving accurate timing information to PA”. Perhaps in a separate article you could explain the details of why this raises CPU. Especially with respect to determining if our devices are susceptible, how to fix them, and if any workarounds – say in daemon.pa – could be applied.

    Also do you happen to know if the “USB SounBlaster mp3+” devices (usb-041e_USB_Audio-00-MP3) have this problem?


Leave a comment

No trackbacks yet.