Hi, Mark has already posted a follow up, but I'll try and answer any questions you posed that he didn't cover. 'Twas brillig, and Taylor Hutt at 28/09/11 18:29 did gyre and gimble: > > > Since we have decided not to use Pulse, prior to my time, it seemed > > > prudent to continue with that decision. > > > I'll be blunt. This is a mistake. Revisit it. Do your own > evaluation. We > > > That's not bad advice, but it's not always prudent. > > In this case, I am part of a team working to make a shipping product, > and there are time constraints which > do not afford the time necessary to do that, _and_ to make forward > progress to get the sound system working > across a constantly increasing variety of hardware. While I accept your standpoint, I'd also point out that PulseAudio has been dealing with a variety of hardware for several years. We've got extensive support for probing the many different kinds of mixer setups to come up with a valid mixer element chain for volume controls and for switching to different outputs (headphones vs. speakers, internal vs. external mic etc). If time is of the essence for you, I think it would be highly adventitious to leverage years of experience from people rolling out solutions to varying hardware and reusing a relatively mature bit of software that already achieves probably 90-95% of what you'll need. To me, that would seem like the must prudent approach to something with time constraints. If anything I'd suggest the opposite would only be true if there were no time constraints at all! > The door has not categorically closed on Pulse for all time, but it has > closed for the time being. > We've got a lot of work to get Chromium and Chromium OS to a point where > ship with the desired features, and > I don't presently have the time to re-investigate Pulse across our set > of hardware. I think that's a shame as we've already solved a lot of the problem you'll encounter on that range of hardware. For problematic cases we have mechanisms to allow specific configurations to be dictated (specific mixer profiles attached via udev rules based on pci/usb ids). It think that if you really do want to do a good job in this area you'd do well to leverage the experience our community has built up. Even if you do not actually use PA, the people in our community have extensive experience you could leverage for advice. As I've mentioned a couple times now you really should join our mailing list. > > > As far as I understand it, > > > Pulse also doesn't cope well with dynamic devices -- it's more > suited to > > > a desktop system than to a system which will have devices > dynamically > > > inserted & removed. > > > This is a grave misunderstanding. PA copes *very* well with dynamic > > devices. It's one of the key parts of what we do. Policy modules allow > > > things to happen automatically (for example when I have a voip stream > > > and I enable my bluetooth headset, a policy module kicks in and knows > > that I want voip on bluetooth. This is all customisable, but at > the end > > of the day, this is very much a key part of the platform. > > > Can you explain how Pulse copes with devices that have not been seen > before and > for which no configuration has been written? The short answer is "it depends". Most of this stuff is modular so it's really up to what modules you write and/or configure in your setup. At present we have modules that implement a priority list based routing system on a per-role basis. e.g. each application presents a role and then the device to use is chosen based on a priority list specific to that role. When a new device is plugged in we currently go on the principle of least surprise, and as such it's added to the end of each priority list. It would be very simple to change that to make it e.g. go to the top of each priority list. We do also have other modules that override this list. We have an "intended roles" module which automatically matches up given streams to given devices. e.g. if a device is classified as a handset or a headset (i.e. some USB devices, Bluetooth devices etc) then they will be tagged with an "intended role" of voip. This means that should any voip streams come along, this device will be used. It's also trivial to write other modules to do policy the way you want. Moving streams around between devices is trivial. > Does Pulse work with HDMI audio and video? It works very well with HDMI audio. We don't touch video. > > This is good news as it means you still have time to make the right > > decision. I strongly suggest you take some time to read up a bit more > > about PA and chat to us about it. > > Point me to the definitive documentation, please. Most of the documentation is on our wiki. Sadly it's dog slow and somewhat outdated. We are in the process of moving all the content across to the Freedesktop.org wiki space, but this hasn't really been fully planned yet so will take a month or so before it's ready I suspect. http://pulseaudio.org/ Regarding stream management and moving stuff the doxygen documentation lives here: http://freedesktop.org/software/pulseaudio/doxygen/ Controlling device and stream volumes and getting info is covered here: http://freedesktop.org/software/pulseaudio/doxygen/introspect.html Sadly we don't yet have good docs written about moving streams around, but pavucontrol is basically our reference design here that covers all of the code needed to do this. While most policy modules would typically be written inside PA itself (due to the convenience of hooking into various events that happen (e.g. when a new device is added/removed, or when new streams are started etc.) there is nothing stopping you writing this kind of thing as an external application (they can receive similar notifications). Just keep in mind that any external program will be reactive rather than proactive. i.e. if something is written as a PA module it'll be able to know when a device has disappeared and then move any playing streams to a new device. An external application won't be able to hook into things at such an early stage and thus if it is deciding it's own device preferences it'll potentially conflict with the device choice made inside PA of the "rescued" stream and thus you may jump from an flat battery BT headset to internal speakers (PA choice) to USB speakers (external controller choice), whereas an internal module could move it to the right device first time. This example is perhaps a bit convoluted but hopefully I've highlighted the drawbacks of using an external app in this regard. However, I should think that writing a module for PA that uses the metadata and information from ADHD would be a pretty trivial job. I think this was (approximately) what Mark was potentially suggesting in his previous post. There are also numerous blog posts by Lennart and myself and others, which are now syndicated on the planet blog: http://freedesktop.org/software/pulseaudio/planet/ In particular I'd like to point out (some now quite old): http://0pointer.de/public/foss.in-pulse.pdf http://www.vidarholen.net/contents/blog/?p=21 http://colin.guthr.ie/2009/08/sound-on-linux-anti-fud-calm-certainty-and-confidence/ http://0pointer.de/blog/projects/jeffrey-stedfast.html There are of course some negative comments there too, but I think, on balance, the negative criticism have mostly been addressed now (in a large part due to driver issues as Pierre-Louis from Intel has already pointed out regarding your previous problems - and I have to say it's a real shame that we were not asked at the time about this as it would have saved you a lot of headaches in the intervening period). Anyway, I hope this reply has helped. As I offered to Leng Ooi a while ago I'd be happy to discuss things on the phone if you like. I did this before but this was probably more as a "recruitment" drive (possibly for your role!) rather than the technical discussion I'd hoped for (I was not and am not in the market for employment and/or relocation right now), so perhaps this time around it would be more fruitful? Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
