On Sun, September 16, 2012 9:51 am, Brendan Jones wrote: Turns out the jackd2 package already pulls in any x11 stuff dbus-x11 needs and the 130kb it takes on my disk is not a problem. So I can fake an X11 session without having one. -- Len Ovens www.OvenWerks.net

On Mon, September 17, 2012 9:07 am, S. Massy wrote: I'm still working on it. I have a solution that does get jackd running by using this script: --------------------------------8<---------------- #! /bin/bash # file: /home/user/data/script/jackstart # # This is ridiculous: export DISPLAY=:0 # dbus-launch started, DBUS_SESSION_BUS_ADDRESS exported: export `dbus-launch | grep ADDRESS` # dbus-launch started, DBUS_SESSION_BUS_PID exported export `dbus-launch | grep PID` jackd -dalsa -dhw:0 -r44100 > ~/.log/jack.log 2>&1 -------------------------------8<------------------ I don't like it ... it runs /bin/dbus-daemon twice and both instances keep running. There should be a way to get both ADDRESS and PID from one instance. The second problem is more complex. In an X session situation, all processes running in that session have the same environment values because those values are passed to them by the session. In a console or terminal situation, something like this could be used as part of .profile or .bashrc for somewhat of the same effect.... but, I would likely have more than one login that I may be using. I have (so far with just playing with ALSA) found it handy to have one terminal (out of the 6 VTs) just to run alsamixer. I think it may be nice to have one for making and breaking jack connections as well as whatever audio apps I want to play with. So far that would be 6 instances of dbus-daemon... and I am not sure if something started in one terminal would be able to talk to one in another... So, I think I need to have a file that has the three exportable values in it: DISPLAY, PID and ADDRESS. At a new login bashrc checks for this file and if it is not there, starts dbus and creates the file. If the file is there, then the PID is checked to see if it belongs to dbus and if so exports the file contents... or if not recreates the file. Another way (I am thinking these up as I go BTW) might be to have /etc/rc.local run a script that: su $jackuser starts dbus as $jackuser creates file in /home/$jackuser/.config/fakedbus (or something) This file would have the three lines to export at boot time. exits This assumes only one user will be using the machine in this way or that the same script will be run for all users who might. It would get sourced as part of .bashrc as the user logs in. The advantage of this is that jackdbus could be run using jack_control for example. a2j would be able to use dbus. Session software would be able to run for persistent jack/midi connections. The system could be run remotely via ssh logins as well. Comment: Linux and linux distros have become X11 centric or server use only. There have become a rather narrow set of ways it is meant to be used. Using Linux as a desktop CLI OS is now quite difficult and takes some thought and knowledge on the part of the installer. My test box is a PII (I think) 300Mhz with 191M ram and a 2.6G drive (include swap). It is amazing what can be fit in here when there is no GUI to worry about and how much spare CPU there is to play with. Len -- Len Ovens www.OvenWerks.net