7 Dec
2004
7 Dec
'04
8:05 a.m.
I'm a bit puzzled with this one thing about low latency and jack: real
time bits can't do IO, but don't you get latency between say me
pressing some button and sound doing click? there's no garanty the not
realtime part of the application will run often enough to read the
input device, no?
just recently some heavy process started when i was fulling around
with some soft synths [i know that shouldn't be happening, but i just
recently switched distros and I haven't learned enough to write
dont-bother-me script to switch all potential sources of disturbance]
and the GUI of the soft synth became quite irresponsive, while audio
went on without any glitches - that's I suppose because the audio part
was running in realtime thread and decided itself when to yield cpu.
is the only way to ensure the effects don't lag from control input to
make sure I run as little processes as possible and hope the input
thread will be scheduled often enough?
--
Artem Baguinski: http://www.artm.org/
V2_Lab: http://lab.v2.nl/
V2_ Organisation for the Unstable Media: http://www.v2.nl/
7 Dec
7 Dec
9:27 a.m.
On tis, 2004-12-07 at 13:07 +0100, Artem Baguinski wrote:
I'm a bit puzzled with this one thing about low
latency and jack: real
time bits can't do IO, but don't you get latency between say me
pressing some button and sound doing click? there's no garanty the not
realtime part of the application will run often enough to read the
input device, no?
Is this a GUI button or a MIDI button?
MIDI buttons/sliders do not need to have any noticeable latency if the
MIDI-thread is run at the (near?) same priority as jack. Although the
thread has high priority, it is mostly idle and will consume next to no
CPU.
Suppose JACK consumes 90% of your CPU, you will have 10% left to do your
MIDI IO, which is plenty for processing a handful of bytes.
GUI buttons on the othe hand are expensive to repaint by nature, and the
cost depends on what kind of eye-candy your installed GUI-theme will
use.
just recently some heavy process started when i was
fulling around
with some soft synths [i know that shouldn't be happening, but i just
recently switched distros and I haven't learned enough to write
dont-bother-me script to switch all potential sources of disturbance]
and the GUI of the soft synth became quite irresponsive, while audio
went on without any glitches - that's I suppose because the audio part
was running in realtime thread and decided itself when to yield cpu.
Hmmm ...
# man nice
NAME
nice - run a program with modified scheduling priority
SYNOPSIS
nice [OPTION] [COMMAND [ARG]...]
DESCRIPTION
Run COMMAND with an adjusted scheduling priority.
With no COMMAND, print the current scheduling priority.
ADJUST is 10 by default. Range goes from -20 (highest
priority) to 19 (lowest).
...
...
So if you do:
# nice -10 audioapp [audioapp-options]
.. your audioapp should repaint itself before any less urgent process
(with normal or slightly high priority) gets a chance at the CPU. JACK
will still run at (near?) highest priority, so if your audio-processing
demands 90% CPU there will be not so much repainting going on ...
is the only way to ensure the effects don't lag from control input to
make sure I run as little processes as possible and hope the input
thread will be scheduled often enough?
Nah .. You should be able to get your audioapps running at a priority
high enough to only be disturbed by themselves.
mvh // Jens M Andreasen
11:41 a.m.
New subject: [linux-audio-dev] Re: jack, low latency and IO
Jens M Andreasen <jens.andreasen(a)chello.se> writes:
[...snip...]
yep. thanks for the enlightenment.
--
Artem Baguinski: http://www.artm.org/
V2_Lab: http://lab.v2.nl/
V2_ Organisation for the Unstable Media: http://www.v2.nl/
On tis, 2004-12-07 at 13:07 +0100, Artem Baguinski
wrote:
well, i meant an abstract input device ;-) not necesserily MIDI. may be
some thing i'll solder and connect to a parport of a serial port or
firewire or bluetooth. something i'm gonna want to use to control
[say] my soft synths.
I'm a bit puzzled with this one thing about
low latency and jack: real
time bits can't do IO, but don't you get latency between say me
pressing some button and sound doing click? there's no garanty the not
realtime part of the application will run often enough to read the
input device, no?
Is this a GUI button or a MIDI button? MIDI buttons/sliders do not need to have any
noticeable latency if the
MIDI-thread is run at the (near?) same priority as jack. Although the
thread has high priority, it is mostly idle and will consume next to no
CPU.
Suppose JACK consumes 90% of your CPU, you will have 10% left to do your
MIDI IO, which is plenty for processing a handful of bytes.
so i suppose this will be still valid for any other input... i see.
Suppose I have several various devices that control various aspects of
sound generation / processing. they all send "handful of bytes" now
and then and I want my JACK client to react immediately. Does it make
sence to have one high priority "input thread" to handle all of them?
Shall I request real time scheduling for this thread(s)?
GUI buttons on the othe hand are expensive to repaint
by nature, and the
cost depends on what kind of eye-candy your installed GUI-theme will
use.
I was talking about delay between the acttion of the user [mouse
button click in this case] and reaction of the sound generation /
processing stuff. I don't really care if button gets redrawn half a
second later if the effect starts right after i click. But I suppose
I'd think twice what sort of GUI controls and feedback to use
now. thanks again.
just recently
some heavy process started when i was fulling around
with some soft synths [i know that shouldn't be happening, but i just
recently switched distros and I haven't learned enough to write
dont-bother-me script to switch all potential sources of disturbance]
and the GUI of the soft synth became quite irresponsive, while audio
went on without any glitches - that's I suppose because the audio part
was running in realtime thread and decided itself when to yield cpu.
Hmmm ... So if you do:
# nice -10 audioapp [audioapp-options]
.. your audioapp should repaint itself before any less urgent process
(with normal or slightly high priority) gets a chance at the CPU. JACK
will still run at (near?) highest priority, so if your audio-processing
demands 90% CPU there will be not so much repainting going on ...
right.
is the only
way to ensure the effects don't lag from control input to
make sure I run as little processes as possible and hope the input
thread will be scheduled often enough?
Nah .. You should be able to get your audioapps running at a priority
high enough to only be disturbed by themselves. 
5:27 p.m.
New subject: [linux-audio-dev] Re: jack, low latency and IO
On Tuesday 07 December 2004 15:42, Artem Baguinski wrote:
Suppose I have several various devices that control
various aspects of
sound generation / processing. they all send "handful of bytes" now
and then and I want my JACK client to react immediately.
You do realize that you can't react immediately regardless.
Jack - and all other audio API's process audio in chunks/periods/buffers
whatever they are called.
So it depends on how much jitter you tolerate in the response.
This is determined by the period size in the simple case of handling input as
soon as possible (which is the next call to your process callback)
Which is the easy thing and if you are able to run low latency kernels you can
use with it with some kinds of controls. And in this case as long as the
event gets there by the next process cycle you're ok.
Or you need to add timestamping on incoming events with respect to the
position of the audio-playback-pointer in the current period
Then you delay them by the same amount in the next available process cycle.
You increase response time but you decrease jitter. But then you need accurate
and quick-as-possible response for those incoming events and this is the
situation Paul mentioned, where it gets complicated.
An solution for a custom hw interface could to use an audio input on the sound
card as a trigger/control input. Then you can just deal with it in your
process cycle. But then most audio interfaces don't like dc signals so you
have careful what you send in.
Just so you know why it is complicated :)
G
--
electronic & acoustic musics-- http://www.xs4all.nl/~gml
6:06 p.m.
New subject: [linux-audio-dev] Re: jack, low latency and IO
On tis, 2004-12-07 at 22:32 +0000, vanDongen/Gilcher wrote:
...
...
Or you need to add timestamping on incoming events
with respect to the
position of the audio-playback-pointer in the current period
Then you delay them by the same amount in the next available process cycle.
You increase response time but you decrease jitter. But then you need accurate
and quick-as-possible response for those incoming events and this is the
situation Paul mentioned, where it gets complicated.
This implies that either:
1) The driver timestamps when the interrupt happens (and that the
interrupt is not magically delayed.)
2) The "midi-thread" runs at higher priority than jack (so it can take
care of the event *excactly* when it happens, regardless ...)
No?
Just so you know why it is complicated :)
OK :)
G
--
(
)
c[] // Jens M Andreasen
5:33 p.m.
New subject: [linux-audio-dev] Re: jack, low latency and IO
On tis, 2004-12-07 at 16:42 +0100, Artem Baguinski wrote:
...
...
Given that your devices have a known worst-case latency within your
specified timing requirements, you can give them realtime priority.
I believe that reading the state of RS-232, like you suggested, is
perfectly safe.
It makes sense to read all your devices from one thread. It might save
you a context-switch (or two or ...) It can also give you a guarantee of
some kind of order if you need it.
On the other hand, a design with individual threads reading from each
IO-stream will be easier to maintain, and if there is nothing going on
there currently, the thread will block and be out of the runable loop,
hence leaving it up to the real-kernel-pro's to optimize your app.
Personally I have a mutex to protect me while the voice-stealing
algorithm is doing its magic, so I might have a look into the single-
thread variant ... perhaps. The mutex is not *that* expensive.
The mouse-down, mouse-dragged signals (and friends) fits within realtime
constraints. It is the 'do_running_fading_ink_repaint()' (or whatever)
that you need to keep low priority, albeit probably above Mozilla
repainting some nasty ads on its current page.
MIDI
buttons/sliders do not need to have any noticeable latency if the
MIDI-thread is run at the (near?) same priority as jack. Although the
thread has high priority, it is mostly idle and will consume next to no
CPU.
Suppose JACK consumes 90% of your CPU, you will have 10% left to do your
MIDI IO, which is plenty for processing a handful of bytes.
so i suppose this will be still valid for any other input... i see.
Suppose I have several various devices that control various aspects of
sound generation / processing. they all send "handful of bytes" now
and then and I want my JACK client to react immediately. Does it make
sence to have one high priority "input thread" to handle all of them?
Shall I request real time scheduling for this thread(s)?
GUI buttons on
the othe hand are expensive to repaint by nature, and the
cost depends on what kind of eye-candy your installed GUI-theme will
use.
I was talking about delay between the acttion of the user [mouse
button click in this case] and reaction of the sound generation /
processing stuff. I don't really care if button gets redrawn half a
second later if the effect starts right after i click. But I suppose
I'd think twice what sort of GUI controls and feedback to use
now. thanks again. 
6:03 p.m.
New subject: [linux-audio-dev] Re: jack, low latency and IO
On Tue, 2004-12-07 at 22:33 +0100, Jens M Andreasen wrote:
The mouse-down, mouse-dragged signals (and friends)
fits within realtime
constraints. It is the 'do_running_fading_ink_repaint()' (or whatever)
that you need to keep low priority, albeit probably above Mozilla
repainting some nasty ads on its current page.
FWIW, none of the OSX systems I have used handle this well at all.
Flash ads running in a background mozilla window will steal excessive
CPU from the Pro Tools (or DP or whatever) GUI. Of course the audio is
not affected, just the GUI.
This seems to work OK on Windows, probably due to the "feature" where it
boosts the priority of the foreground window.
Lee
6:40 p.m.
New subject: [linux-audio-dev] Re: jack, low latency and IO
On tis, 2004-12-07 at 16:49 -0500, Lee Revell wrote:
On Tue, 2004-12-07 at 22:33 +0100, Jens M Andreasen
wrote:
Mmm .. So Pro Tools are not upping their GUI even the slightliest by
default. To be honest neither do I, just shut down whatever gets in the
way.
In a serious OSX studio environment (as in pay money for time), the
machines running the session would not (hopefully not?) be connected to
the Internet anyway.
The mouse-down, mouse-dragged signals (and
friends) fits within realtime
constraints. It is the 'do_running_fading_ink_repaint()' (or whatever)
that you need to keep low priority, albeit probably above Mozilla
repainting some nasty ads on its current page.
FWIW, none of the OSX systems I have used handle this well at all.
Flash ads running in a background mozilla window will steal excessive
CPU from the Pro Tools (or DP or whatever) GUI. Of course the audio is
not affected, just the GUI.
This seems to work OK on Windows, probably due to the "feature" where it
boosts the priority of the foreground window.
Yep, that system appears to solve some common problems in a
straightforward way.
Lee
/jens
--
BTW: Anybody knows how to stop Evolution from inserting my email-adress
as a default auto-generated signature?
7:24 p.m.
New subject: [linux-audio-dev] Re: jack, low latency and IO
On Tue, 2004-12-07 at 23:39 +0100, Jens M Andreasen wrote:
BTW: Anybody knows how to stop Evolution from
inserting my email-adress
as a default auto-generated signature?
Ugh, I hate this feature too. The default changed from 1.x to 2.0.
Tools->Settings, click the account, edit, then on the Identity tab
change Signature from "Autogenerated" to "None"
Lee
7:57 p.m.
New subject: [linux-audio-dev] Re: jack, low latency and IO
On Tue, 2004-12-07 at 18:24 -0500, Lee Revell wrote:
On Tue, 2004-12-07 at 23:39 +0100, Jens M Andreasen
wrote:
Let's see ... first change environment to 'en' (to stop tranlation into
swedish so that I can follow you), and then, mmm ...
That was not so hard :)
Thankyou!
BTW: Anybody knows how to stop Evolution from
inserting my email-adress
as a default auto-generated signature?
Ugh, I hate this feature too. The default changed from 1.x to 2.0.
Tools->Settings, click the account, edit, then on the Identity tab
change Signature from "Autogenerated" to "None"
Lee
--
(
)
c[] mvh // Jens M Andreasen
11:44 a.m.
On tis, 2004-12-07 at 13:07 +0100, Artem Baguinski
wrote:
> I'm a bit puzzled with this one thing about low latency and jack: real
> time bits can't do IO, but don't you get latency between say me
> pressing some button and sound doing click? there's no garanty the not
> realtime part of the application will run often enough to read the
> input device, no?
Jens M Andreasen <jens.andreasen(a)chello.se> writes:
.. your audioapp should repaint itself before any less
urgent
process (with normal or slightly high priority) gets a chance at the
CPU. JACK will still run at (near?) highest priority, so if your
audio-processing demands 90% CPU there will be not so much
repainting going on ...
As a practical matter, JACK had better *not* be using 90% of your CPU.
That sort of load is unlikely to be reliably sustainable.
For any reasonable CPU load, there should be plenty of cycles
remaining to run non-realtime threads without requiring special
scheduling hacks.
Don't forget that other system resource bottlenecks can cause poor
performance. When running realtime, JACK locks down large amounts of
memory. Your GUI code may be getting paged out.
--
joq
12:53 p.m.
New subject: [linux-audio-dev] Re: jack, low latency and IO
"Jack O'Quin" <joq(a)io.com> writes:
yep, this is what i'm puzzled about.
forget the gui, suppose i meant that MIDI button.
JACK does everything to make sure the audio threads run uninterrupted
to process that audio on time and deliver it to the audio hardware,
right? but it doesn't make sure other IO gets handled on time.
If I make sure there's enough CPU cycles for everybody why do audio
threads require real time priority? to make sure audio gets delivered
to the hardware ASAP, right? but the handful of bytes from my moving a
MIDI slider has to be delivered and taken into account on time as
well, otherwise I still have delay between my action and synth's
reaction. so I want my input thread to run just as often as audio
thread, no? in this case suggestion of Jens (running MIDI [or input]
thread with the same priority as audio thread) seems the best i could
do. Only MIDI thread will do its job much quicker.
or am i missing something?
like, if each JACK application starts adding extra real time threads
they all will suffer from the same problems they would if they werent
real time scheduled?
.. your
audioapp should repaint itself before any less urgent
process (with normal or slightly high priority) gets a chance at the
CPU. JACK will still run at (near?) highest priority, so if your
audio-processing demands 90% CPU there will be not so much
repainting going on ...
As a practical matter, JACK had better *not* be using 90% of your CPU.
That sort of load is unlikely to be reliably sustainable.
For any reasonable CPU load, there should be plenty of cycles
remaining to run non-realtime threads without requiring special
scheduling hacks. Don't forget that other system resource
bottlenecks can cause poor
performance. When running realtime, JACK locks down large amounts of
memory. Your GUI code may be getting paged out.
--
Artem Baguinski: http://www.artm.org/
V2_Lab: http://lab.v2.nl/
V2_ Organisation for the Unstable Media: http://www.v2.nl/
2:01 p.m.
New subject: [linux-audio-dev] Re: jack, low latency and IO
On tis, 2004-12-07 at 17:54 +0100, Artem Baguinski wrote:
...
...
forget the gui, suppose i meant that MIDI button.
JACK does everything to make sure the audio threads run uninterrupted
to process that audio on time and deliver it to the audio hardware,
right? but it doesn't make sure other IO gets handled on time.
And here we mean specifically that MIDI button, and not the general case
of IO (and definately not some randomly slow block-device ...)
If I make sure there's enough CPU cycles for
everybody why do audio
threads require real time priority? ...
Low priority processes are only idle untill something happens that can
make them work. Say you want to have a look at your mailbox while your
audioapp is running, right? It will be OK that X (rendering your mail)
is not quite as snappy as it use to be when it is on its own, but it
would be very disturbing if your sound cracked up because jack had to
share cycles evenly with your mailapp.
... to make sure
audio gets delivered
to the hardware ASAP, right? but the handful of bytes from my moving a
MIDI slider has to be delivered and taken into account on time as
well, otherwise I still have delay between my action and synth's
reaction.
so I want my input thread to run just as often as
audio
thread, no? ...
I think you will have to or else the internal state of your app will not
be in sync with the outside world.
... in this case suggestion of Jens (running
MIDI [or input]
thread with the same priority as audio thread) seems the best i could
do. Only MIDI thread will do its job much quicker.
or am i missing something?
like, if each JACK application starts adding extra real time threads
they all will suffer from the same problems they would if they werent
real time scheduled?
Well, if those other apps starts indiscriminately adding desk-IO and
major repaints in realtime then, yes you would be in trouble. But what
we are talking about here is processing 'a handful of bytes' every ms or
so from a device with known (near)zero-latency. This will have a very
limited impact on overall performance.
mvh // Jens M Andreasen
12:12 p.m.
New subject: [linux-audio-dev] nice [was: jack, low latency and IO]
Jens M Andreasen <jens.andreasen(a)chello.se> writes:
So if you do:
# nice -10 audioapp [audioapp-options]
.. your audioapp should repaint itself before any less urgent process
(with normal or slightly high priority) gets a chance at the CPU. JACK
will still run at (near?) highest priority, so if your audio-processing
demands 90% CPU there will be not so much repainting going on ...
i couldnt decipher man nice / info coreutils nice so i googled to find
out [1]
The following nice command executes command-name with a lower
priority by raising the nice number by 5 units.
$ /usr/bin/nice -5 command-name
In the preceding command, the minus sign designates that what
follows is an option. This command could also be specified as
follows:
% /usr/bin/nice -n 5 command-name
...
Also I've figured that to lower the nice number I'll need root
priviliges. After patching my kernel [ok, downloading a patched kernel
;-P] to be able jack and friends as my normal self?.. or does this
patch changes the situation?
[time passes]
no, it doesnt change:
[artm@caracolito vlo-mp]$ nice -n 10 ./vlo
... vlo runs ...
[artm@caracolito vlo-mp]$ nice -n -10 ./vlo
nice: cannot set priority: Permission denied
... vlo doesn't run ...
[1] http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWaadm/SYSADV2/p78.html
--
Artem Baguinski: http://www.artm.org/
V2_Lab: http://lab.v2.nl/
V2_ Organisation for the Unstable Media: http://www.v2.nl/
1:02 p.m.
New subject: [linux-audio-dev] nice [was: jack, low latency and IO]
i couldnt decipher man nice / info coreutils nice so i
googled to find
out [1]
good, because nice is irrelevant for anything with even vaguely
realtime requirements.
actually, this is problem is not quite as simple as some people have
made out. i can't offer a good working solution myself because i am
still experimenting with it. if you don't need to timestamp incoming
events from your control unit or wherever, then just running
SCHED_FIFO but 1 or 2 priority steps below the JACK thread will be
fine. but if you need to timestamp them, it starts to get a lot
harder.
--p
1:05 p.m.
New subject: [linux-audio-dev] nice [was: jack, low latency and IO]
On tis, 2004-12-07 at 17:14 +0100, Artem Baguinski wrote:
Jens M Andreasen <jens.andreasen(a)chello.se>
writes:
> So if you do:
>
> # nice -10 audioapp [audioapp-options]
bzzt .. You are so right!
# nice --10 audioapp [audioapp-options]
i couldnt decipher man nice / info coreutils nice so i googled to find
out [1]
The following nice command executes command-name with a lower
priority by raising the nice number by 5 units.
$ /usr/bin/nice -5 command-name
In the preceding command, the minus sign designates that what
follows is an option. This command could also be specified as
follows:
% /usr/bin/nice -n 5 command-name
...
Also I've figured that to lower the nice number I'll need root
priviliges. After patching my kernel [ok, downloading a patched kernel
;-P] to be able jack and friends as my normal self?.. or does this
patch changes the situation?
I seem also not to be able to connect to jack without being root
(although the app runs suid root... )
[time passes]
no, it doesnt change:
2:06 p.m.
New subject: [linux-audio-dev] nice [was: jack, low latency and IO]
Jens M Andreasen <jens.andreasen(a)chello.se> writes:
All JACK clients must run as the same UID as the server. Please don't
run JACK as root, except as an experiment to get things working.
To gain realtime privileges as a non-root user you need the
realtime-lsm (with 2.6 kernels) or the capabilities patch (with 2.4).
http://jackit.sourceforge.net/docs/faq.php#a52
--
joq
Also I've
figured that to lower the nice number I'll need root
priviliges. After patching my kernel [ok, downloading a patched kernel
;-P] to be able jack and friends as my normal self?.. or does this
patch changes the situation?
I seem also not to be able to connect to jack without being root
(although the app runs suid root... )
3:34 p.m.
New subject: [linux-audio-dev] nice [was: jack, low latency and IO]
On tis, 2004-12-07 at 12:06 -0600, Jack O'Quin wrote:
Jens M Andreasen writes:
All JACK clients must run as the same UID as the server. Please don't
run JACK as root, except as an experiment to get things working.
To gain realtime privileges as a non-root user you need the
realtime-lsm (with 2.6 kernels) or the capabilities patch (with 2.4).
http://jackit.sourceforge.net/docs/faq.php#a52
OK!
Jack has been distributed with Mandrake 10.1 without the realtime
module. So it only runs as root by default here, and then still being
severely disturbed by the underlying journaling filesystem.
I have rebuild the jackd according to the recommendations in the source-
distribution. Works as advertized :) Guess I missed the part about
realtime-lsm while dancing ...
mvh // Jens M Andreasen
Also
I've figured that to lower the nice number I'll need root
priviliges. After patching my kernel [ok, downloading a patched kernel
;-P] to be able jack and friends as my normal self?.. or does this
patch changes the situation?
I seem also not to be able to connect to jack without being root
(although the app runs suid root... )
4:04 p.m.
New subject: [linux-audio-dev] nice [was: jack, low latency and IO]
On Tue, 2004-12-07 at 20:34 +0100, Jens M Andreasen wrote:
Jack has been distributed with Mandrake 10.1 without
the realtime
module. So it only runs as root by default here, and then still being
severely disturbed by the underlying journaling filesystem.
We are trying to get the realtime LSM in the kernel so this won't be an
issue in the future. Once it's in the kernel, we only have to get the
distros to configure it correctly :-P and JACK should "just work" out of
the box as a normal user.
Lee
8 Dec
8 Dec
12:15 p.m.
New subject: [linux-audio-dev] nice [was: jack, low latency and IO]
Lee Revell <rlrevell(a)joe-job.com> writes:
On Tue, 2004-12-07 at 20:34 +0100, Jens M Andreasen
wrote:
Appropriately configured, of course. ;-)
--
joq
Jack has been distributed with Mandrake 10.1
without the realtime
module. So it only runs as root by default here, and then still being
severely disturbed by the underlying journaling filesystem.
We are trying to get the realtime LSM in the kernel so this won't be an
issue in the future. Once it's in the kernel, we only have to get the
distros to configure it correctly :-P and JACK should "just work" out of
the box as a normal user.
11 Dec
11 Dec
8:51 a.m.
New subject: [linux-audio-dev] nice [was: jack, low latency and IO]
On ons, 2004-12-08 at 10:16 -0600, Jack O'Quin wrote:
Lee Revell <rlrevell(a)joe-job.com> writes:
Hi!
I have bitched the Mandrake-team for shipping a version/config of jack
that cannot work. It appears like it might be the jack-team that is (at
least partially) to blame ... (?)
I said that they (Mandrake) set up jack to have its sockets on /tmp,
which cannot work when /tmp is part of journaling file-system.
After that, I have had a look at various options that are available in a
clickedeclick style after install. One of them is to empty /tmp on
reboot.
At first I thought that this option would do
# rm /tmp/*
.. or some such. Apparently not because when i do df:
-------------------------------------------------------
[jens@elephant jens]$ df
Filesystem Size Used Avail Use% Mounted on
/dev/hda5 3,4G 2,2G 1,1G 69% /
/dev/hda7 4,3G 2,0G 2,3G 47% /home
none 126M 0 126M 0% /mnt/ramfs
/dev/hda1 1,6G 1,4G 207M 87% /mnt/windows
none 126M 68K 126M 1% /tmp
-------------------------------------------------------
... , it should be clear that /tmp is now similar to /mnt/ramfs (which
is the one I created from the guidelines in the jack source-
distribution.)
The jackd included with mdk10.1 still sounds "funny". How is that?
I have no clue, do not know the answer, but if I do:
[jens@elephant jens]$ /usr/bin/jackd --version
jackd version 0.98.1
default tmp directory: /tmp
... and:
[jens@elephant jens]$ /usr/local/bin/jackd --version
jackd version 0.99.0 tmpdir /mnt/ramfs protocol 13
... , then I get the impression that something very positive happened
between jackd_0.98.1 and jackd_0.99.0
Comments?
--
(
)
c[] mvh // Jens M Andreasen
On Tue, 2004-12-07 at 20:34 +0100, Jens M
Andreasen wrote:
Appropriately configured, of course. ;-) Jack has been distributed with Mandrake 10.1
without the realtime
module. So it only runs as root by default here, and then still being
severely disturbed by the underlying journaling filesystem.
We are trying to get the realtime LSM in the kernel so this won't be an
issue in the future. Once it's in the kernel, we only have to get the
distros to configure it correctly :-P and JACK should "just work" out of
the box as a normal user.
12:33 p.m.
New subject: [linux-audio-dev] nice [was: jack, low latency and IO]
Jens M Andreasen <jens.andreasen(a)chello.se> writes:
I have bitched the Mandrake-team for shipping a
version/config of jack
that cannot work. It appears like it might be the jack-team that is (at
least partially) to blame ... (?)
If you discover a bug in JACK, please open a report...
http://jackit.sourceforge.net/mantis/
I said that they (Mandrake) set up jack to have its
sockets on /tmp,
which cannot work when /tmp is part of journaling file-system.
Perhaps they should configure using --with-default-tmpdir=PATH. The
default path, /tmp, is not usually the best choice, but has the major
advantage of being present on every system. For a default, that's
good.
Distribution makers may have reason to know that a better option is
available. Some use /dev/shm, which is needed for POSIX shared memory
support and therefore often configured correctly. Beware, however,
that compiling JACK to use POSIX shared memory will conflict with that
choice.
After that, I have had a look at various options that
are available in a
clickedeclick style after install. One of them is to empty /tmp on
reboot.
At first I thought that this option would do
# rm /tmp/*
.. or some such. Apparently not because when i do df:
-------------------------------------------------------
[jens@elephant jens]$ df
Filesystem Size Used Avail Use% Mounted on
/dev/hda5 3,4G 2,2G 1,1G 69% /
/dev/hda7 4,3G 2,0G 2,3G 47% /home
none 126M 0 126M 0% /mnt/ramfs
/dev/hda1 1,6G 1,4G 207M 87% /mnt/windows
none 126M 68K 126M 1% /tmp
-------------------------------------------------------
... , it should be clear that /tmp is now similar to /mnt/ramfs (which
is the one I created from the guidelines in the jack source-
distribution.)
A better check is probably something like this...
$ grep tmp /etc/fstab
/dev/hda8 /tmp ext2 defaults 0 2
none /dev/shm tmpfs defaults 0 0
jack /tmp/jack tmpfs defaults 0 0
You want it to say `tmpfs' (or maybe `ramfs').
[jens@elephant jens]$ /usr/bin/jackd --version
jackd version 0.98.1
default tmp directory: /tmp
... and:
[jens@elephant jens]$ /usr/local/bin/jackd --version
jackd version 0.99.0 tmpdir /mnt/ramfs protocol 13
... , then I get the impression that something very positive happened
between jackd_0.98.1 and jackd_0.99.0
Comments?
Mixing two different versions of JACK on the same system is usually a
disaster. Programs linked with /usr/lib/libjack.so.0 will generally
not work correctly with /usr/local/bin/jackd.
--
joq
11:03 p.m.
New subject: [linux-audio-dev] nice [was: jack, low latency and IO]
On lör, 2004-12-11 at 10:33 -0600, Jack O'Quin wrote:
grep tmp /etc/fstab
Right! So here it is:
[jens@elephant jens]$ grep tmp /etc/fstab
none /mnt/ramfs tmpfs defaults 0 0
none /tmp tmpfs defaults 0 0
... So they are not similar, but actually same.
Mixing two different versions of JACK on the same
system is usually a
disaster. Programs linked with /usr/lib/libjack.so.0 will generally
not work correctly with /usr/local/bin/jackd.
That is an understatement :) LD_LIBRARY_PATH=/usr/local/lib would be
ones friend to get going.
I said 0.98.1 sounds "funny" (as in clicks and cracks) compared to
0.99.0 and wondered what kind of magic happened inbetween? Many other
people have the 0.98.1 version distributed as RPM ready to experiment
with ... To file a bugreport when the latest and greatest version works
(here) is not so very intuitive.
Regarding "magic": How come jackd is not showing up in top except for
idle running low?
--
(
)
c[] mvh // Jens M Andreasen
7229
days inactive
7233
days old
linux-audio-dev@lists.linuxaudio.org
22 comments
6 participants
participants (6)
-
Artem Baguinski -
Jack O'Quin -
Jens M Andreasen -
Lee Revell -
Paul Davis -
vanDongen/Gilcher