'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. -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] _______________________________________________ pulseaudio-discuss mailing list [email protected] https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
