[03:16] <len> astraljava, there does seem to be a new image today (mar 30) 12% difference from mar 28.
[03:18] <len> The jackd thing seems to come and go, one day it will work the next image not... then on again.
[03:20] <len> jackdbus auto seems to get run when qjackctl is started... not when run is hit. 
[03:20] <CFHowlett> meeting this sunday??
[03:22] <len> ScottL, I have not marked the jack-PA bridging incomplete. as far as I know that part works consistently... so long as I can get jack to start.
[03:23] <len> Sorry for not answering sooner... I was doing family time ;-)  ok I'm not that sorry, family is pretty important too.
[03:24] <len> ailo I will try some of those things after I print the memory stick.
[03:57] <len-live> ailo this seems to be a jack-PA interaction. I don't know that bridging is the problem though.
[03:58] <len-live> if I login and start jack with qjackctl, it starts fine. jack and PA bridge and there are no problems.
[04:02] <len-live> If I start a PA application (audacious) and it is playing and then start jack I have a problem. Exit qjackctl and audacious ... restart qjackctl and it still doesn't work. kill PA and everything works again.... including PA.
[04:13] <len-live> PA control does some wild and wonderful stuff. I am bridging PA to jack. pavucontrol shows both the jack sink and the "speaker". The audio is going into jack and the so i can control the level going to jack. But the I can also still cotrol the soundcard levels from pavucontrol too with the speaker volume even though this output is not selected.
[07:37] <astraljava> len-live: Ok, then it was just halted for one day only.
[11:29] <ailo> len: jackdbus needs an application to control it, so it's not as simple to start from the command line. When jackdbus is running, it will show as "jackdbus" among the list of running processes. But, if you disable dbus for jack, you'll see "jackd" in the list of processes instead.
[11:30] <ailo> Or, disable dbus for qjackctl is what I mean
[11:32] <falktx> ailo: jack_control does the same as jackd, but for dbus
[11:34] <ailo> It's getting a little ridiculous as what dependencies are concerned. Removing jackd2 and replacing it with jackd1 makes you have to uninstall some apps, like ardour
[12:13]  * falktx hates debian/ubuntu use of jack1 vs jack2, it's crazy
[15:53] <len-1204> ailo: I'm not sure, but I may be seeing a difference in the way jack works from one kernel to the next. (or maybe there have been changes in jackd or PA)
[15:54] <len-1204> a week or two ago, I could start jack with qjackctl while PA was playing audio.
[15:54] <len-1204> It was still jackdbus auto back then.
[15:55] <len-1204> The audio would stop because jack grabbed the hardware. But just changing where PA was sending the stream would correct things
[15:56] <len-1204> Now, if PA is playing audio, qjackctl can't start jackd.
[15:58] <len-1204> Once qjackctl has failed to start jackdbus... it seems the only way to set things right is to kill -9 jackdbus and kill PA (which just restarts itself)
[15:58] <len-1204> Then start jackdbus before any audio stream.
[16:11] <len-1204> I was wrong. PA does not have to be restarted.
[16:12] <len-1204> but the stream has to be stopped and jackdbus stopped and started before the stream is restarted.
[16:21] <len-1204> I get the same problem if I use qjackctl or jack_control
[18:32] <len> falktx: do you happen to know if it is expected for ubiquity to download software updates as part of the install process, but not install them?
[18:33] <len> After install, the newsoftware version star comes up and says new sofware has already been downloaded but needs to be installed.
[18:34] <len> No complaints, just seems odd.
[18:39] <falktx> not sure
[18:39] <falktx> last time I checked ubiquity didn't installed updates, the reason was to make install times faster
[18:40] <len> So they are downloaded but not installed. I guess that means machines designed to be run off net can be hooked up for as little time as possible.
[21:57] <len> ailo, playing with jackd and friends... Using jack_control instead of qjackctl to start/stop jackdbus.
[21:57] <len> len@music1204:~$ jack_control stop
[21:57] <len> --- stop
[21:57] <len> DBus exception: org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)
[21:58] <len> As you can see it  gives the same message as qjackctl.
[21:58] <len> But jackdbus has in fact stopped and jack_control restarts it just fine.
[22:20] <len> Interesting, qjackctl tracks the status of jackdbus just fine when it is being stopped/started even when the above error message is received be jack_control.
[22:30] <len> qjackctl seems to stop jackdbus differently than jack_control. qjackctl stops jackdbus in a way that leaves the jacksink output in PA active while with jack_control, jacksink goes away when jackdbus is stopped.
[22:52] <len> qjackctl setup does have a way not to have the applications still running dialog when stopping.