-----BEGIN PGP SIGNED MESSAGE-----
On 31/05/12 16:15, Ian Malone wrote:
On 31 May 2012 14:25, David Sommerseth <davids(a)redhat.com>
> -----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.
> 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.
Most multimedia end-use stuff doesn't do Jack. If you don't
support them then you make the spin much less usable for casual use
alongside production (which might be what you want, but would be a
Reimplementing the Pulse API is a pretty big target and what would
be the result? Another Pulse that bridges to Jack anyway? If you
use jack-pulse bridging then you have a Jack system and still have
As I understand it, the currently available pulse bridge requires a
running pulseaudio daemon running. So you have this chain:
app -> pulseaudio lib -> pulseaudio daemon -> pulse bridge -> jackd
By writing a native pulse library which integrates directly with jack,
app -> pulse/jack bridge API lib > jackd
Which means you should be able to get much more control over the
applications using pulse. Each of the apps should then appear as
separate jack sinks, which you can route more freely. And the pulse
based applications might even have a lower latency, as the audio
packets skips a "detour" to reach jackd. And this also helps avoid
fiddling around with issues related to running both jackd and
pulseaudio in parallel ... if jackd doesn't run before pulseaudio
runs, pulse might have taken hardware in possession and so on.
But as you say, this is a pretty hefty target to stretch for. But if
I'm not too far off, I think the end result will be easier to maintain
and control. Except of having to follow the pulse API more closely.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----