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
Received on Sat Dec 24 08:15:05 2005
This archive was generated by hypermail 2.1.8 : Sat Dec 24 2005 - 08:15:06 EET