On Fri, 2005-12-23 at 19:46 -0800, Russell Hanaghan wrote: > Paul Davis wrote: > > >On Fri, 2005-12-23 at 15:31 -0800, Kjetil S. Matheussen wrote: > > > > > >>Lee Revell: > >> > >> > >>>>>>>Jack then needs to be compiled as such right? That is, specifically to > >>>>>>>use /dev/shm as a tmpfs? > >>>>>>> > >>>>>>> > >>>>>>You know there's actually no good reason this has to be a compile time > >>>>>>setting. It would be trivial to modify JACK to set this at runtime. > >>>>>> > >>>>>> > >>>>>how would a client know where to find the server sockets? > >>>>> > >>>>> > >>>>> > >>>>By having a file called something like /tmp/jack_server_sockets_path > >>>>containing info about where the server sockets are? > >>>> > >>>> > >>>> > >>>$HOME/.jack_server_sockets_path? > >>> > >>> > >>Yes, either $HOME/.jack_server_sockets_path_<hostname> > >>or /tmp/jack_server_sockets_path_<username> > >> > >> > > > >this looks to me like a 50% solution. it solves part of the problem > >(allowing the location of the actual sockets/fifos to be determined at > >runtime) by substituting another compile-time-only path instead. i see > >the attraction, i am just not sure its the best solution. > > > >--p > > > > > > > > > > > So the first solution is the most solid; compile jack to utilize /dev/shm? > > Unless there is some trade off or sacrifice when doing so to either the > systems stability and performance, or to jackits stability / > performance, I don't see this as a major problem. Obviously, make sure /dev/shm exists and is a tmpfs mount first but yes, there's no trade off at all. Lee
