<div class="gmail_quote">On Tue, Sep 27, 2011 at 8:16 AM, Tanu Kaskinen <<a href="mailto:tanu.kaskinen@digia.com">tanu.kaskinen@digia.com</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> On Tue, 2011-09-27 at 18:02 +0300, Rémi Denis-Courmont wrote: > Le mardi 27 septembre 2011 17:27:14 Arun Raghavan, vous avez écrit : > > Do you have any more details? Seems to be more of a policy daemon than > > an audio server. > > Isn't audio policy daemon just a fancier name for (modern) audio server? > Does PulseAudio not implement audio policy? > > Sure, PulseAudio certainly does not police video devices. That's partly done > by the X server (XVideo grabs), partly by the window manager, but mostly not > done at all. > > But still... Looking at what there is currently, there doesn't seem to be any trace of a client interface. That would suggest that it won't handle the actual audio stream data. Of course, the project is in a *very* early stage, so the client interface bits might get added later. In order to replace speculation with actual facts, I'll CC Taylor Hutt, who seems to be doing the development. Taylor, would you possibly have time to share some information about ADHD? For convenience, here's a link to the beginning of this thread: <a href="http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-September/011452.html" target="_blank">http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-September/011452.html</a> </blockquote><div> Hello folks, I am indeed the one doing the majority of the work on the ADHD system at present, and I can answer questions about it. As a bit of background, PulseAudio was attempted for a while before my time on the Chromium OS project. The results for some of the hardware we have were not very inspiring -- at idle, I was told Pulse would take 30% of the CPU. So, Pulse was removed, and the sound system sat for a long while. The guy originally in charge of sound decided to work on something else and I took the responsibility. Since we have decided not to use Pulse, prior to my time, it seemed prudent to continue with that decision. 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. We've also looked at UCM and decided that it wasn't right for our purposes, at least in the present state. Since it's expected that Chrome machines will have devices dynamically added and removed, we needed to be able to adapt to those dynamic events, and respond in a manner which will allow the user to select the output & input device -- think of this as a problem similar to printing: if you've got more than one printer available to your system, and you want to print a document, the computer cannot easily decide which printer you wish to use at all times. ADHD is the name of the Portage project, and gavd is the name of the daemon that runs. There will probably be other aspects to ADHD as time marches on, but right now it is just the daemon. gavd is not a policy daemon. The purpose of gavd at this point is to monitor for new hardware, removed hardware, and things being plugged into the on-board minijacks. Presently, gavd is only going to be dealing with audio hardware, but it is believed that it will ultimately subsume the management of video output, particularly HDMI. At present, the HDMI output is handled by the power management daemon. gavd will maintain information about the currently installed hardware and provide that information to Chrome, and Chrome will probably end up making the policy decisions about the output device to use, maybe based on some type of input from the user. At present, all this is in flux, and the final direction / ultimate goal has not been codified. I'm currently working to get enough infrastructure built up in gavd so that we can start experimenting with changes that will be done in the rest of the system. In short, gavd is not attempting to do what Pulse does, nor is it trying to replace UCM. Rather, it's a solution for our special needs. At some point in the future, I can envision a way that we might able to use UCM to switch between different configurations, or even to use Pulse Audio. But for now, we've got to resolve various software issues in the project so that all parts of the projects are on the same page. Once everything is aligned with respect to device management, then we can decide what comes next. thutt </div></div>