<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> On 05/28/2009 05:15 AM, Lennart Poettering wrote: <blockquote cite="mid:20090527221525.GA22919@tango.0pointer.de" type="cite"> <pre wrap="">On Thu, 28.05.09 04:53, Patrick Shirkey (<a class="moz-txt-link-abbreviated" href="mailto:pshirkey@boosthardware.com">pshirkey@boosthardware.com</a>) wrote: </pre> <blockquote type="cite"> <pre wrap="">I think it is useful that you have the internal api calls so dbus is not a requirement for communicating with PA. </pre> </blockquote> <pre wrap=""> I am sorry to inform you that eventually PA will use D-Bus for client communication too. Already now building PA without D-Bus is not really supported anymore (read: noone bothers to check if those builds still compile). </pre> </blockquote> 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? It could just provide a simple on/off switch for jack to call and take care of everything else via dbus commands or it could provide a little more power under the hood. It could be maintained seperately but included at compile time so there would be little chance of breakage. Alternately "pactl -jack on" , "pactl -jack off" might work just as well. <blockquote cite="mid:20090527221525.GA22919@tango.0pointer.de" type="cite"> <pre wrap=""></pre> <blockquote type="cite"> <pre wrap="">- FYI, Stephane has clarified that the existing code that signals for PA to suspend is part of the ALSA level code and is only tied to dbus because that was the option chosen for communicating to PA. It almost sounds like he was not aware of the API calls that are available. So thanks for clarifying that point as it provides another option for seamless integration of jack and PA. </pre> </blockquote> <pre wrap=""> Have a link to the archives of this mail? </pre> </blockquote> I have copied here for your convenience. ++++++++++++++++ >I have been researching the issues with pulse and jack working together >seamlessly. >I have found some interesting info and am happy to see that jackdbus already >has support for notifying pulseaudio to suspend itself and allow jack to access >the default sound card or assigned device. This is not "jackdbus" by itself, but the fact that the ALSA JACK backend now uses some D-Bus based "reservation" code (defined by PulseAudio developers). When the ALSA JACK backend starts, it ask for the card and PA has to release it. When the ALSA driver stops, it gives back the card. So yes this reservation code is activated when JACK2 in compiled with D-Bus, but it is not coded in the "jackdbus" executable. +++++++++++++++++++ <blockquote cite="mid:20090527221525.GA22919@tango.0pointer.de" type="cite"> <pre wrap="">Lennart </pre> </blockquote> </body> </html>