|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
On 05/31/2012 03:25 PM, David Sommerseth wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31/05/12 08:43, Brendan Jones wrote:Just a note that the default F17 pulseaudio configuration supports jack bridging via dbus (/etc/pulse/default.pa). ### Automatically connect sink and source if JACK server is present .ifexists module-jackdbus-detect.so .nofail load-module module-jackdbus-detect .fail .endif This is different to again to module-jack-sink.so/module-jack-source.so which is what some of us have been using up until now. What that means is if jack-audio-connection-kit-dbus is on the spin by default, bridging is set up automatically. This is something that needs to be considered carefully and I'd be interested in how well jackdbus is working for people. I was having random errors in the past with jackdbus hogging CPU with pulse. I will perform some more monitoring here, but it would be great to hear what others have experienced.Throwing in a large torch at fire here now ... do we really need pulseaudio? I mean, this is a multi-media production spin, filled with applications where Jack has become the standard - at least among the audio based applications. I don't know how that jack/pulse bridge really works ... but if pulse really is needed, wouldn't it be better to write something which can completely replace the pulse libraries, and rather re-use just the API ... so that pulse based applications appears as those in/out sinks in Jack directly? This might be a rather long-term goal though.
With pulseaudio-jack bridging, both are running. Pulseaudio simply redirects its output to jack's default system input ports.
This means applications which are not jack enabled will in most cases simply work. I regularly need to run applications for work (such as skype) and this seems to be a really stable solution.
Having said that, I'd really like one of the aims of the Spin be focussed on ease of configuration, and providing an easy way to disable pulseaudio completely should be considered.
This might be a better way to get better predictability in how the audio production applications would behave, still having a fallback for non-jack capable software. Please educate me if I'm totally wrong here. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/HcUcACgkQIIWEatLf4HeKFQCfeZY63NLf82/4ePLXKQBLUdky V+gAn2lrXHIsPPjVmCo/NfCYS0VA0FIu =fLRW -----END PGP SIGNATURE-----
_______________________________________________ music mailing list music@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/music
[Fedora Legacy Announce] [Fedora Extras] [Home] [Kernel] [Fedora Legacy] [Fedora Desktop] [Fedora Directory] [PAM] [Red Hat Development] [Red Hat 9 Bible] [Red Hat 9] [Big List of Linux Books] [Gimp] [Yosemite News] [Yosemite Camping]