7 Mar
2010
7 Mar
'10
11:17 a.m.
Hi there.
The distro I'm using installs a script with jack that lets it run as a
daemon.
I'm wondering whether this makes any sense at all, whether there is a
use case for this that isn't covered by anything else.
I'd like to hear you opinion.
http://repos.archlinux.org/wsvn/packages/jack/repos/testing-x86_64/?opt=dir
jack.conf is the config file in /etc/
jack.install is run when jack is installed/upgraded/removed
rc.jack is the daemon script itself
So what do you think?
Regards,
Philipp
7 Mar
7 Mar
12:31 p.m.
On Sun, Mar 7, 2010 at 10:17 AM, Philipp <hollunder(a)lavabit.com> wrote:
Hi there.
The distro I'm using installs a script with jack that lets it run as a
daemon.
I know that I personally do not consider this an appropriate way to
run JACK, and I am irritated by distributions that do this. That
doesn't mean I'm right.
8 Mar
8 Mar
12:07 p.m.
On Sunday 07 March 2010 11:31:50 Paul Davis wrote:
On Sun, Mar 7, 2010 at 10:17 AM, Philipp
<hollunder(a)lavabit.com> wrote:
Let's say you are running Rivendell with jack and want things to come up to
rdairplay ready to go...
Thoughts?
all the best,
drew
Hi there.
The distro I'm using installs a script with jack that lets it run as a
daemon.
I know that I personally do not consider this an appropriate way to
run JACK, and I am irritated by distributions that do this. That
doesn't mean I'm right.
12:42 p.m.
On Mon, Mar 8, 2010 at 11:07 AM, drew Roberts <zotz(a)100jamz.com> wrote:
On Sunday 07 March 2010 11:31:50 Paul Davis wrote:
you set the system up to run an X session for a given user, and that
user's startup configuration starts JACK etc. etc.
if the system is headless, same thing but just via init and a user login script
or something like that.
On Sun, Mar 7, 2010 at 10:17 AM, Philipp
<hollunder(a)lavabit.com> wrote:
Let's say you are running Rivendell with jack and want things to come up to
rdairplay ready to go...
Thoughts? Hi there.
The distro I'm using installs a script with jack that lets it run as a
daemon.
I know that I personally do not consider this an appropriate way to
run JACK, and I am irritated by distributions that do this. That
doesn't mean I'm right. 
5:47 p.m.
On Mon, Mar 08, 2010 at 11:42:25AM -0500, Paul Davis wrote:
you set the system up to run an X session for a given
user, and that
user's startup configuration starts JACK etc. etc.
if the system is headless, same thing but just via init and a user login script
or something like that.
The only thing these would do is spare the user
the effort to launch jackd. But that is not the
point at all.
Use cases:
- More than one user on the same system, each one
using part of the available HW/channels. Not likely
if you have just a stereo audio interface, but quite
a normal thing if you have 64 channels connected to
different parts of a installation.
- Changing users without interrupting operation,
as e.g. in broadcasting, or when part of the audio
processing is fixed and not dependent on the user.
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
5:58 p.m.
On Mon, Mar 8, 2010 at 4:42 PM, <fons(a)kokkinizita.net> wrote:
Use cases:
- More than one user on the same system, each one
using part of the available HW/channels. Not likely
if you have just a stereo audio interface, but quite
a normal thing if you have 64 channels connected to
different parts of a installation.
- Changing users without interrupting operation,
as e.g. in broadcasting, or when part of the audio
processing is fixed and not dependent on the user.
all sound entirely justifiable to me. but this is about promiscuous
mode, not whether JACK is started by init, surely?
6:15 p.m.
On Mon, Mar 08, 2010 at 04:58:20PM -0500, Paul Davis wrote:
On Mon, Mar 8, 2010 at 4:42 PM,
<fons(a)kokkinizita.net> wrote:
Yes, but the two are related. Promiscuous mode only
makes sense if jackd is not started as the result of
some user login but as a system service.
--
FA
Use cases:
- More than one user on the same system, each one
using part of the available HW/channels. Not likely
if you have just a stereo audio interface, but quite
a normal thing if you have 64 channels connected to
different parts of a installation.
- Changing users without interrupting operation,
as e.g. in broadcasting, or when part of the audio
processing is fixed and not dependent on the user.
all sound entirely justifiable to me. but this is about promiscuous
mode, not whether JACK is started by init, surely?
6:24 p.m.
On Mon, Mar 8, 2010 at 5:11 PM, <fons(a)kokkinizita.net> wrote:
Yes, but the two are related. Promiscuous mode only
makes sense if jackd is not started as the result of
some user login but as a system service.
i don't see that at all. how does starting it as a system service
(i.e. started by init) change the story?
8:18 p.m.
On 09/03/2010, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Mon, Mar 8, 2010 at 5:11 PM,
<fons(a)kokkinizita.net> wrote:
I'd say they're indirectly related.
The primary feature request in this case would be:
"Allow mulitple users to start/run/access jackd, and allow multiple
client connections from these users."
And if that works, naturally an init script will work too. Or rather,
an init script will only work if the above is implemented.
Anyway, as far as the thread subject is concerned, the init scripts
have been removed from the package until the feature is supported
upstream: http://bugs.archlinux.org/task/15102
--
GPG/PGP ID: B42DDCAD
Yes, but the two are related. Promiscuous mode
only
makes sense if jackd is not started as the result of
some user login but as a system service.
i don't see that at all. how does starting it as a system service
(i.e. started by init) change the story?
5169
days inactive
5170
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
5 participants
participants (5)
-
drew Roberts -
fons＠kokkinizita.net -
Paul Davis -
Philipp -
Ray Rashif