[pulseaudio-discuss] Working with PA and jack
gmane at colin.guthr.ie
Thu May 28 01:38:04 PDT 2009
'Twas brillig, and Patrick Shirkey at 28/05/09 06:31 did gyre and gimble:
> Thanks for the heads up. There is no desire to use an api that is not
> going to be future proofed. Would you consider having a "pajackcontrol"
> app that uses dbus to communicate with pa and provides the existing api
> hooks to jack so that legacy jack and non dbus jack can still signal pa
> to play nicely?
Providing backwards compatibility is one thing but if the pulse client
library just decides to use DBUS rather than sockets, why should any
client application care? I don't think there is any intended client API
breakage. That wouldn't go down well!
Even if it were a problem, why go to the effort? I mean if you want to
use "legacy" jack, then why not "legacy" PA too?
Free software is an ecosystem, it's all moves together. If you take a
Neanderthal man and place him in a modern city, he'd be dead by
lunchtime, probably after trying to tame the big, red metal Mammoth.
I don't expect to compile a modern distro with gcc 0.1. etc. etc.
> Alternately "pactl -jack on" , "pactl -jack off" might work just as well.
That assumes that jack wants all your audio devices. What if you have a
crappy USB speakers that are find for general usage but rubbish for
pro-audio. Jack wont want them. Pulse should still get to use them.
This is handled currently by the dbus device reservation spec.
Tribalogic Limited [http://www.tribalogic.net/]
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the pulseaudio-discuss