[pulseaudio-discuss] [PATCH] JACK: Add module-jackdbus-detect

[Colin Guthrie]

'Twas brillig, and Colin Guthrie at 03/12/10 12:46 did gyre and gimble:
> 'Twas brillig, and David Henningsson at 03/12/10 11:58 did gyre and gimble:
>> On 2010-12-03 11:35, Colin Guthrie wrote:
>>> Hiya
>>>
>>> Seems like a good patch at first glance.
>>
>> Thanks! :-)
>>
>>> One minor question that I
>>> really don't know the answer to right now, but firgured it's worth
>>> asking. This approach seems totally separate from the device reservation
>>> protocol that works between Jack and PA to do graceful handover. Is
>>> there any chance of races here between the two different IPCs? I don't
>>> think so (i'd expect Jack to ensure it gets the device first before it
>>> reports that it isStarted()).
>>
>> I'd say they are unrelated. The device handover, as you say, might
>> happen before JACK is fully started. Also; JACK controlling ALSA is not
>> all use cases, JACK can also control firewire sound cards (and it has
>> network and oss drivers as well).
>>
>> Also IIRC, there is no automatic stream moving/rescuing when device
>> reservation happens, so existing streams will not move, you'll still
>> have to manually switch to the JACK sink in kde/gnome/pavu-control.
> 
> Hmm, right, those streams will be corked and thus not move across...
> 
> Wonder how best to handle that :s Really the sinks/sources should be
> fully unloaded and thus allow the stream rescuing to happen (in theory
> we should move it to the jack sink rather than just rescuing, but that's
> beside the point.
> 
> I guess if we had priority list routing and jack was always higher than
> alsa in the priority list, then this is a non-issue, but that's maybe
> not the best way to think about it....
> 
> 
>>> I think it's probably OK to go into default.pa, but it could also be an
>>> option in paprefs too.....
>>>
>>> e.g. a ticky box for:
>>>
>>> "[ ] Automatically redirect audio through Jack if it is started"
>>>
>>> or similar.
>>>
>>> WDYT is best?
>>
>> Perhaps I need to explain a little further - there is a "routing
>> patchbay" inside the JACK server; connect=true means that when a
>> module-jack-sink is started, it will connect the jack-sink (which is an
>> input seen from JACK) to the system's sound card output. If
>> connect=false, it will just show up as an unconnected sink, making it
>> easy for people who want to connect that sink to the sound card, run it
>> through a vocoder [1], record it into Ardour, or anything else.
>>
>> Perhaps we should go and ask the Ubuntu Studio and/or Planet CCRMA folks
>> and see if they have an opinion? Leaving them unconnected would be a
>> less invasive approach.
> 
> Ahh right I see what you mean.
> 
> Well if the whole loading of the module was left to paprefs (or rather
> module-gconf), the main ticky box could have a sub-ticky box for the
> "connect" argument of the module. Would be trivial to write for paprefs
> and lets users choose easily without messing with config files.

I've pushed the first patch to git now (master + stable-queue) but I'll
wait and see what you think about putting this into paprefs rather than
default.pa before committing the second patch (or not). I'll make the
changes to paprefs if you like?

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