On Tue, 2011-02-15 at 10:10 +0000, Colin Guthrie wrote: > 'Twas brillig, and Ng Oon-Ee at 15/02/11 00:28 did gyre and gimble: > > If with jack1, you'd have to add logic to unload the > > alsa modules before starting jack and reloading them after stopping > > jack. > > Yeah this was what I meant before when I suggested setting the card > profile to "off". This has the effect of removing the alsa-sink/source > modules but it's easy to reverse (just change the profile back). > > At present, even with jack2 and the dbus-based suspend, I suspect the > setting of the card profile is still preferred. As the reservation > protocol keeps the sinks loaded (but in a suspended state), the streams > connected to it just sit there "corked", rather than move across to the > jack sinks (I think... not tested this so just going on theory which I > hope is correct). > > I'd likely be in favour of the device reservation dbus protocol not > actually suspend things, but actually set the appropriate card profile > to 'Off' (temporarily - e.g. suppress the saving of it) and restore it > back when the dbus reservation is released. This would all e.g. a Dummy > output to be loaded or the Jack Source in this case to "take over" the > running streams (module-rescue-streams does it's work). > > Does this last suggestion make sense/have any drawbacks? > > Col There will be a lag time between the disappearance of the alsa-card and the appearance of the jack sink/source. Not to mention the wider issue here:- Should we assume a) User who starts Jack wants pulseaudio to continue outputting to jack? b) User who starts Jack wants pulseaudio to get out of the way. If b), said user would be terribly annoyed if, halfway through a 2-hour recording, a notification audio suddenly played because pulseaudio was auto-connected. I propose that b) is normally the case, and while auto-switchover behaviour should be made easy (if possible), it should not be the default.
