> True. I do know there has been talk recently about > enhancing PulseAudio > and GNOME applications so that when certain events > happen (like a user > receives a voicecall via ekiga or something), that > this automatically > mutes other audio that might be playing. That is a > useful and a > compelling feature that could tip the scales and make > PulseAudio a > better fit for integration with OpenSolaris. > However, it is my > nderstanding that this isn't yet working upstream, > and is still in > the design stages. >
> As I mentioned before, adding PulseAudio to the > OpenSolaris Desktop will > involve a non-trivial amount of work, so I do think > that we need to make > sure that the benefits are significant enough to > warrant doing the work. > I do not think PulseAudio is there today, but that > could change quickly. > > Though we also need to work with the Solaris > Boomer/OSSv4 team. Since > OSSv4 does support per-application mixing features > directly, it might > make more sense to integrate such desktop mixing > features more directly > with OSSv4 on Solaris instead of using PulseAudio. > It will take some > nalysis time to figure out the best path forward. I > have been in > regular communication with Garret D'Amore about these > sorts of issues, > but we are still at the early stages of analysis. > OSS4/Boomer is already ahead of the Linux audio stack just because we already take care of mixing audio streams regardless of the API that's used. Pulse Audio cannot mix streams that are written to Jack or the ALSA mem-mapped interface. > At the moment, I know that the Boomer/OSSv4 team is > really busy working > to get OSSv4 working on Sun Ray. I suspect there > will not be a lot of > progress to improve more general desktop audio > issues, such as > per-application mixing, until the Sun Ray work is > done. However, once > that is finished, I think that coming up with a > better per-application > mixing story is high on the laundry list of tasks to > work on. > Controlling devices is perhaps the most important issue in desktop audio. You want to essentially virtualize audio services and only Kernel level mixing can achieve that. Intelligence in the driver makes applications simpler to create. Right now if you're developing for Linux - do you write for Pulse or ALSA or Jack or GStreamer? In the case of Solaris - just develop for GStreamer and everything else you get for free - like mixing, latency, device allocation, etc. regards Dev -- This message posted from opensolaris.org
