sorry, seems like I replied to the wrong receiver. On Wed, Jun 5, 2013, at 05:42 AM, Kaj Ailomaa wrote: > > On Wed, Jun 5, 2013, at 02:49 AM, Robin Gareus wrote: > > On 06/05/2013 02:18 AM, Kaj Ailomaa wrote: > > > On Wed, May 29, 2013, at 09:12 AM, Kaj Ailomaa wrote: > > > > > I'd like to go ahead and change this in packaging, making jackdbus and > > > jackd separate for jack2. Also, make jackdbus conflict with jackd. > > > But, that is only if there are no bad implications from doing this, and > > > I currently know of none. > > > > > > > I really like having both around. If possible, please do not make them > > conflict. > > > > My current development habits depend on having both available at the > > same time and IMHO it'd be a major regression if that is no longer > > possible using the official debian package. > > > > I use jackdbus as main jackd (runs most of the time and automatically > > switches backends depending on connected interfaces). I also regularly > > use jackd for a 2nd or 3rd instance -- most of the time for debug > > purposes e.g. running ardour in valgrind without interfering with the > > main jackdbus, but also for multiple indep jack sessions on the same > > machine w/ different audio-interfaces. > > > > 2c, > > robin > > > > I can see the point in being able to run multiple instances of jack, > which is quite possible with jackd. But, why - from a user point of view > - would you ever want to run both jackd and jackdbus at the same time? > Which user based workflow are you fulfilling with this option? > > A fairly common problem: > - start patchage (starts jackd by default) > - start qjackctl (jack already running) > - stop jack with qjackct (appears to be stopped, but the process is > still running) > - start jack with qjackctl (if set to start jackdbus, now both jackd > and jackdbus are running) > > Now, this may be a qjackctl bug, but I'm still wondering.. > > If the reason to use both jackdbus and jackd is solely for development > purposes, I'd vote for making them conflict in packaging, just to make > things easier for the users. > Personally, I'd prefer there was only one jack, but that is of course > not possible to fix in packaging. > > I might need to read up more on the design choices for jack, why we > ended up with three variants, jack1, jack2 (and jackdbus). And also, > from a technical point of view, what they all are useful for. > But, from a user point of view, I don't see why there is need for more > than one. In a basic setup, all you need is one jack, and one instance > of jack. Options should be apply able, but don't need to be default. > > One way to cause even further headache would be to create three > packages: jackd2, jackdbus and jackd2-mixed. > > Later, I would also very much like to look at the possibility of being > able to auto start jack by starting any jack application. If this is bad > in some use cases, let's make it a settable option where-ever most > suitable (upstream or packaging). > For this, one would need a mechanism to make sure the correct jack is > started. This could also be an alternative to packaging jackd and > jackdbus separately. > > Right now, not even "pro" users have an easy time using linux audio, > unless they already know all about the different forms of jack. I think > this is a little ridiculous.
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
