Re: [pulseaudio-discuss] Suggestion for dbus communication with JACK
On Wed, 21.10.09 06:43, Ng Oon-Ee (ngoo...@gmail.com) wrote: On Tue, 2009-10-20 at 16:45 +0200, Lennart Poettering wrote: On Tue, 20.10.09 12:26, Ng Oon-Ee (ngoo...@gmail.com) wrote: Quick suggestion, in latest pulse and latest jack pulse will give up control of the audio hardware when Jack starts (as informed by dbus) and grab control back once Jack stops. Could module-jack-sink and module-jack-source also be loaded/unloaded at these points? I took a quick look/grep through the current git sources but couldn't figure out where this is handled. I'd love to add this, and ventilated that a couple of times to the Jack folks already. The last time we discussed that however there was simply no D-Bus name that I could sanely bind this logic to (i.e. a name that is taken as last step of initialization, where we know for sure that Jack is fully accessible) Maybe this has changed, but I believe it hasn't. It is not an option to bind this logic to the device reservation logic itself because that is supposed to be generic and also doesn't tell us anything about when Jack is fully up and running. Ah, looks like it isn't as simple a matter as I'd thought. If I understand correctly what you're saying, does this mean that the device reservation logic is a general dbus get your hands off the audio device command to Pulseaudio, currently? That's cool, though making what I suggest much more difficult. Yes exactly. It tells PA to stop using a device. It doesn't tell PA hey, now JACK is running and accessible. I'm sure the Jack folk know better than I on the D-Bus name, but jack_control status seems to work fine to tell me when Jack is ready for use, and it communicates via dbus as well... Last time I checked they had a name there where picking before actually spawning off the jack audio daemon. As long as things are that way round this is not useful for PA's needs. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Suggestion for dbus communication with JACK
On Tue, 2009-10-20 at 12:26 +0800, Ng Oon-Ee wrote: Quick suggestion, in latest pulse and latest jack pulse will give up control of the audio hardware when Jack starts (as informed by dbus) and grab control back once Jack stops. Could module-jack-sink and module-jack-source also be loaded/unloaded at these points? I took a quick look/grep through the current git sources but couldn't figure out where this is handled. Corollary suggestion: mark the internal audio device as 'off' (as if user had set 'off' in Configuration of pavucontrol) when jack takes control of the audio device. More suitable to what has actually happened then having an 'active' sink which doesn't accept audio, pausing whatever streams happen to be playing to it at the time (and causing a 'hang' in the sound app, though I know that's an app bug in audio handling). Right now I can just manually move the stream to the module-jack-sink output and the app continues fine, but if the sink had been marked 'off', this would have happened automatically I believe. This second suggestion is more wish-list than anything, since I know its not as simple as the first. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Suggestion for dbus communication with JACK
'Twas brillig, and Ng Oon-Ee at 20/10/09 07:26 did gyre and gimble: On Tue, 2009-10-20 at 12:26 +0800, Ng Oon-Ee wrote: Quick suggestion, in latest pulse and latest jack pulse will give up control of the audio hardware when Jack starts (as informed by dbus) and grab control back once Jack stops. Could module-jack-sink and module-jack-source also be loaded/unloaded at these points? I took a quick look/grep through the current git sources but couldn't figure out where this is handled. Corollary suggestion: mark the internal audio device as 'off' (as if user had set 'off' in Configuration of pavucontrol) when jack takes control of the audio device. More suitable to what has actually happened then having an 'active' sink which doesn't accept audio, pausing whatever streams happen to be playing to it at the time (and causing a 'hang' in the sound app, though I know that's an app bug in audio handling). Right now I can just manually move the stream to the module-jack-sink output and the app continues fine, but if the sink had been marked 'off', this would have happened automatically I believe. This second suggestion is more wish-list than anything, since I know its not as simple as the first. It was my impression that the module-jack-* was loaded at this point, but I've not looked at the code, and a simple grep seems to confirm you findings. These would be good additions for interoperability IMO (but I may have missed something). Col -- 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 pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Suggestion for dbus communication with JACK
On Tue, 20.10.09 12:26, Ng Oon-Ee (ngoo...@gmail.com) wrote: Quick suggestion, in latest pulse and latest jack pulse will give up control of the audio hardware when Jack starts (as informed by dbus) and grab control back once Jack stops. Could module-jack-sink and module-jack-source also be loaded/unloaded at these points? I took a quick look/grep through the current git sources but couldn't figure out where this is handled. I'd love to add this, and ventilated that a couple of times to the Jack folks already. The last time we discussed that however there was simply no D-Bus name that I could sanely bind this logic to (i.e. a name that is taken as last step of initialization, where we know for sure that Jack is fully accessible) Maybe this has changed, but I believe it hasn't. It is not an option to bind this logic to the device reservation logic itself because that is supposed to be generic and also doesn't tell us anything about when Jack is fully up and running. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Suggestion for dbus communication with JACK
On Tue, 2009-10-20 at 16:45 +0200, Lennart Poettering wrote: On Tue, 20.10.09 12:26, Ng Oon-Ee (ngoo...@gmail.com) wrote: Quick suggestion, in latest pulse and latest jack pulse will give up control of the audio hardware when Jack starts (as informed by dbus) and grab control back once Jack stops. Could module-jack-sink and module-jack-source also be loaded/unloaded at these points? I took a quick look/grep through the current git sources but couldn't figure out where this is handled. I'd love to add this, and ventilated that a couple of times to the Jack folks already. The last time we discussed that however there was simply no D-Bus name that I could sanely bind this logic to (i.e. a name that is taken as last step of initialization, where we know for sure that Jack is fully accessible) Maybe this has changed, but I believe it hasn't. It is not an option to bind this logic to the device reservation logic itself because that is supposed to be generic and also doesn't tell us anything about when Jack is fully up and running. Ah, looks like it isn't as simple a matter as I'd thought. If I understand correctly what you're saying, does this mean that the device reservation logic is a general dbus get your hands off the audio device command to Pulseaudio, currently? That's cool, though making what I suggest much more difficult. I'm sure the Jack folk know better than I on the D-Bus name, but jack_control status seems to work fine to tell me when Jack is ready for use, and it communicates via dbus as well... ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
