'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/]
