[pulseaudio-discuss] Trying to get Pukseaudio playing nice with KDE 4.6 on Arch Linux

[Colin Guthrie]

'Twas brillig, and Ng Oon-Ee at 15/02/11 12:08 did gyre and gimble:
> 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.

Yeah fair point... I guess we'll need to make the whole setup flexible
enough to cope with both scenarios.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]