[LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...

[Patrick Shirkey]

Krzysztof Foltman wrote:
> Paul Davis wrote:
>
>   
>> there are other applications that want to start (and potentially) stop
>> jack. if a d-bus aware version of jack is installed instead of the
>> non-dbus-aware one, then applications that do not use the control API
>> for this will fail. ergo: installing the dbus aware version
>> (potentially) breaks the operation of control apps that predate the
>> control API. not the end of the world, but not good either.
>>     
>
> The current state is that it starts the "unintended" version of jackd,
> and confuses almost everyone in the process. Or fails to start the
> server at all, because DBUS version is already running in background,
> confusing everyone else.
>
> In my opinion, plain refusal to start with incompatible version is less
> dangerous, because it gives the end users a necessary information (about
> different pieces of software being incompatible). The users may then
> decide if they prefer the "proven-but-possibly-dead-end" tool set
> (qjackctl and friends) or "still-experimental-but-promising" tool set
> (laditools etc).
>
> The current model is misleading. In some cases it doesn't tell when the
> system works differently to what user intended. In other cases, it
> doesn't explain the primary cause for the server failing to start. My
> reaction to this kind of software is to uninstall it as quickly as possible.
>
>   

I agree that many people get confused at this point. However not many 
people are prepared to uninstall due to the associated issues with 
removing deps. Especially a dep as important as jack.

It's also misleading to refer to the existing proven toolset which is 
quite useful to many professionals as "possibly dead end". That's 
verging on fud.





Patrick Shirkey
Boost Hardware Ltd



>> also, the current jack ecosystem is already deeply confused by the
>> existence of jack1 and jack2, which have a few very subtle but
>> important differences. adding yet another
>> almost-the-same-but-different option is a PR disaster waiting to
>> happen.
>>     
>
> Well, the damage is already done, see Fons' email and probably dozens of
> people who had the same experience but never bothered to report it. I
> think people who spent some time with Linux audio have plenty of
> experience with incompatible parallel APIs - OSS vs ALSA, ALSA vs JACK,
> JACK MIDI vs ALSA sequencer, raw MIDI vs sequencer MIDI. That's Linux
> Audio SNAFU. At least when you have JACK MIDI vs ALSA seq MIDI problem,
> nothing is pretending to work, the apps just don't see each other's MIDI
> ports (+/- a2jmidid, but that's for advanced users).
>
> On the other hand, this "two conflicting JACK executables that appear to
> be compatible but aren't, and they may be picked randomly in some
> instances" is a whole new thing, and nobody is used to it yet ;)
>
> Krzysztof
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>