29 Sep
2002
29 Sep
'02
5:33 p.m.
Now supports connecting to input ports and you can control the number of
columns of meters with -c, -c 1 will give you a vertical strip.
http://plugin.org.uk/meterbridge/meterbridge-0.0.4.tar.gz
Input monitoring "works" by disconnecting everything from the port,
connecting it to the meter in and connecting the monitor out of the meter
to the original port. When it quits it tries to put things back the way
they should be, but it might not always get it right.
If you run too many (8+) then things start to get dodgy, jack carries on
running, but you can't quit meters. I don't know why.
Thanks to Joern and Gerd for testing the extra-alpha versions, and Kai for
fixing the autoconf mess.
- Steve
30 Sep
30 Sep
12:03 p.m.
Steve Harris wrote:
Now supports connecting to input ports and you can control the number of
columns of meters with -c, -c 1 will give you a vertical strip.
http://plugin.org.uk/meterbridge/meterbridge-0.0.4.tar.gz
either it is not really compressed, or my browser performed some
magic...
anyway, "tar xvf" worked for me.
some observations:
output metering works fine.
when i start an instance of meters jackd sometimes complains:
cannot create new client; bridge already exists
cannot complete new client connection process
(i must confess my system still drops out every 2 secs, so i may be
missing so many deadlines that even otherwise well-behaved jack clients
choke...)
i also found it's advisable to re-start jack after a meter crash,
otherwise things get fishy (alsaplayer loses its jack connection during
meter startup and there are random crashes of jackd, alsaplayer and
meters).
with a clean jack, i was able to get 12 stereo meters on 2 ports before
i got bored :)
the restoring of connections on exit succeeds almost always except when
it segfaults (which i can't seem to reproduce reliably). i closed some
of my 12 meters in random order, and the port connections were always
restored correctly. only sometimes it makes alsaplayer time out and
reconnect to jack, and all meters freeze - is that what one would expect
when the source is gone, or should they just drop to zero ?
one minor problem: when you have multiple meters running and "killall"
them, things seem to happen in the wrong order, i.e. the port chain
breaks. but i don't see how meterbridge could avoid that, unless there
is a way to make the port restoration atomic.
the input however i can't seem to get to work at all. it comes up,
displays a signal for maybe half a second, then bails out:
# meterbridge -t dpm alsa_pcm:in_1 alsa_pcm:in_2
Registering as bridge
engine has shut down socket; thread exiting
here's what little i can do with gdb:
(gdb) run -t dpm alsa_pcm:in_1 alsa_pcm:in_2
Starting program: /usr/local/bin/meterbridge -t dpm alsa_pcm:in_1
alsa_pcm:in_2
[New Thread 1024 (LWP 3450)]
Registering as bridge
[New Thread 2049 (LWP 3451)]
[New Thread 1026 (LWP 3452)]
[New Thread 2051 (LWP 3453)]
engine has shut down socket; thread exiting
Program received signal SIGINT, Interrupt.
[Switching to Thread 1024 (LWP 3450)]
0x401f0d6e in select () from /lib/libc.so.6
(gdb) info threads
3 Thread 1026 (LWP 3452) 0x401f0d6e in select () from /lib/libc.so.6
2 Thread 2049 (LWP 3451) 0x401ef4ca in poll () from /lib/libc.so.6
* 1 Thread 1024 (LWP 3450) 0x401f0d6e in select () from /lib/libc.so.6
(gdb) thread 1
[Switching to thread 1 (Thread 1024 (LWP 3450))]#0 0x401f0d6e in select
()
from /lib/libc.so.6
(gdb) where
#0 0x401f0d6e in select () from /lib/libc.so.6
#1 0x400eaf54 in __DTOR_END__ () from /usr/lib/libSDL-1.2.so.0
#2 0x400d44c6 in SDL_WaitEvent () from /usr/lib/libSDL-1.2.so.0
#3 0x08049840 in main (argc=5, argv=0xbffff614) at main.c:212
#4 0x4013c9ed in __libc_start_main () from /lib/libc.so.6
(gdb) thread 2
[Switching to thread 2 (Thread 2049 (LWP 3451))]#0 0x401ef4ca in poll
()
from /lib/libc.so.6
(gdb) where
#0 0x401ef4ca in poll () from /lib/libc.so.6
#1 0x4007eb40 in __pthread_manager () from /lib/libpthread.so.0
#2 0x4007ed68 in __pthread_manager_event () from /lib/libpthread.so.0
(gdb) thread 3
[Switching to thread 3 (Thread 1026 (LWP 3452))]#0 0x401f0d6e in select
()
from /lib/libc.so.6
(gdb) where
#0 0x401f0d6e in select () from /lib/libc.so.6
#1 0x400eaf54 in __DTOR_END__ () from /usr/lib/libSDL-1.2.so.0
#2 0x0804aea2 in gfx_thread_dpm (foo=0x0) at dpm_meters.c:84
#3 0x400da0e7 in SDL_RunThread () from /usr/lib/libSDL-1.2.so.0
#4 0x400da2ee in RunThread () from /usr/lib/libSDL-1.2.so.0
#5 0x4007ee67 in pthread_start_thread () from /lib/libpthread.so.0
#6 0x4007eeb5 in pthread_start_thread_event () from
/lib/libpthread.so.0
Input monitoring "works" by disconnecting
everything from the port,
connecting it to the meter in and connecting the monitor out of the meter
to the original port. When it quits it tries to put things back the way
they should be, but it might not always get it right.
If you run too many (8+) then things start to get dodgy, jack carries on
running, but you can't quit meters. I don't know why.
can't reproduce this.
Thanks to Joern and Gerd for testing the extra-alpha
versions, and Kai for
fixing the autoconf mess.
i guess we really ruined your day on #lad yesterday >;->
best,
jörn
--
Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)
1 Oct
1 Oct
5:17 a.m.
On Mon, Sep 30, 2002 at 06:01:06 +0200, Joern Nettingsmeier wrote:
OK, well my jackd had been running for several hours, maybe bitrot had set
in.
when i start an instance of meters jackd sometimes
complains:
cannot create new client; bridge already exists
cannot complete new client connection process
That is just becuase it tried to connect as brdige, and if it cant tries
bridge-<pid>
i also found it's advisable to re-start jack after
a meter crash,
otherwise things get fishy (alsaplayer loses its jack connection during
meter startup and there are random crashes of jackd, alsaplayer and
meters).
Thats bad. In the stderr output, does it look like the meter manages to
clean up after isself?
the restoring of connections on exit succeeds almost
always except when
it segfaults (which i can't seem to reproduce reliably). i closed some
of my 12 meters in random order, and the port connections were always
restored correctly. only sometimes it makes alsaplayer time out and
reconnect to jack, and all meters freeze - is that what one would expect
when the source is gone, or should they just drop to zero ?
No, they will freeze, making then return to zero would require more logic,
so I didn't do it ;)
one minor problem: when you have multiple meters
running and "killall"
them, things seem to happen in the wrong order, i.e. the port chain
breaks. but i don't see how meterbridge could avoid that, unless there
is a way to make the port restoration atomic.
Yeah, thats not fixable. Making them not crash is probably better.
I'd like to get to the bottom of your segfual problem. I though id
probably fixed it.
the input however i can't seem to get to work at
all. it comes up,
displays a signal for maybe half a second, then bails out:
Thats bizarre.
If you run too
many (8+) then things start to get dodgy, jack carries on
running, but you can't quit meters. I don't know why.
can't reproduce this. i guess we really ruined your day on #lad yesterday
>;->
:) no its bette than releaseing versions that will fail embarasingly
- Steve
11:54 a.m.
On Tue, Oct 01, 2002 at 09:01:39 -0400, Paul Davis wrote:
Right, well I was testing meter failure modes, which probably included
a dozen segfaults, and many failed cleanups.
- Steve
OK, well my
jackd had been running for several hours, maybe bitrot had set
in.
i routinely leave jackd running for 2-3 days non-stop (if ardour
doesn't segfault - if it does, this can mess up jackd, which i need to fix)
3 Oct
3 Oct
6:42 a.m.
Steve Harris wrote:
yes. it's just that meterbridge somehow causes alsaplayer to time out.
the jack crashes were not easy to pin down - i haven't come up with
anything reproducible yet.
ok, i just wanted to make sure it's expected behaviour.
just to clarify, i mean killall -TERM, not killall -KILL. out of
curiousity, is there a way to tell the scheduler not to pre-empt the
process until the port cleanup is completed ? (sorry if this is a dumb
question, i don't know much about unix programming...)
not that i think this feature is really needed.
agreed :)
i'll give it another beating tonight.
hope you are enjoying your trip to spain!
best,
jörn
--
Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)
On Mon, Sep 30, 2002 at 06:01:06 +0200, Joern Nettingsmeier wrote:
ok, i could have thought of that myself....
when i start an instance of meters jackd
sometimes complains:
cannot create new client; bridge already exists
cannot complete new client connection process
That is just becuase it tried to connect as brdige, and if it cant tries
bridge-<pid> i also found
it's advisable to re-start jack after a meter crash,
otherwise things get fishy (alsaplayer loses its jack connection during
meter startup and there are random crashes of jackd, alsaplayer and
meters).
Thats bad. In the stderr output, does it look like the meter manages to
clean up after isself? the restoring
of connections on exit succeeds almost always except when
it segfaults (which i can't seem to reproduce reliably). i closed some
of my 12 meters in random order, and the port connections were always
restored correctly. only sometimes it makes alsaplayer time out and
reconnect to jack, and all meters freeze - is that what one would expect
when the source is gone, or should they just drop to zero ?
No, they will freeze, making then return to zero would require more logic,
so I didn't do it ;) one minor
problem: when you have multiple meters running and "killall"
them, things seem to happen in the wrong order, i.e. the port chain
breaks. but i don't see how meterbridge could avoid that, unless there
is a way to make the port restoration atomic.
Yeah, thats not fixable. Making them not crash is probably better.
I'd like to get to the bottom of your segfual problem. I though id
probably fixed it. the input
however i can't seem to get to work at all. it comes up,
displays a signal for maybe half a second, then bails out:
Thats bizarre.
7:05 a.m.
On Thu, Oct 03, 2002 at 12:38:33 +0200, Joern Nettingsmeier wrote:
Not that this is a good thing, it should be fixed. I didn´t check to see
if there was a client name query function. If so I will use that, if not I
will probably just move to always using bridge-<pid>. ¿comments?
Sig term (should) cause the cleanup handler to be called, nothing will
happen to the process other than that IIRC. ITs up to you what you do with
the signal, but its polite to exit afterwards ;)
- Steve
That is just
becuase it tried to connect as brdige, and if it cant tries
bridge-<pid>
ok, i could have thought of that myself.... Yeah, thats
not fixable. Making them not crash is probably better.
I'd like to get to the bottom of your segfual problem. I though id
probably fixed it.
just to clarify, i mean killall -TERM, not killall -KILL. out of
curiousity, is there a way to tell the scheduler not to pre-empt the
process until the port cleanup is completed ? (sorry if this is a dumb
question, i don't know much about unix programming...)
3:41 p.m.
Steve Harris wrote:
Sig term (should) cause the cleanup handler to be called, nothing will
happen to the process other than that IIRC. ITs up to you what you do with
the signal, but its polite to exit afterwards ;)
;)
i was thinking of a situation like this:
some meterbridges run.
i issue "killall meterbridge".
meterbridge receives a SIGTERM, the exit handler is called and all
functions you registered with atexit() are executed (i.e. the port
restoration).
the problem is, when there are multiple processes called meterbridge,
they will all be killed at once and their exit functions will likely run
concurrently. which is bad, because one instance might just have
disconnected, gets pre-empted without having restored the old
connection, another instance tries to clean up and BANG! the signal
chain is broken. i *think* this is what i'm seeing.
how would you (in theory) handle this ? is there a way for userspace
apps to declare a part of their code atomic ? if not, would it make
sense to use a lockfile upon entering the port reconnection code ?
(not that i'm interested in this feature... it's just that i want to
know how userspace is supposed to handle situations like this.)
--
Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)
On Thu, Oct 03, 2002 at 12:38:33 +0200, Joern Nettingsmeier wrote:
Not that this is a good thing, it should be fixed. I didn´t check to see
if there was a client name query function. If so I will use that, if not I
will probably just move to always using bridge-<pid>. ¿comments?
hehe, watch out and stay out of the sun, your punctuation is already
becoming spanish :)
i like the pid approach. i don't know if i fully understand its
implications, but it feels like this should be added to the jack docs as
a "best practise" recommendation.
That is
just becuase it tried to connect as brdige, and if it cant tries
bridge-<pid>
ok, i could have thought of that myself.... Yeah, thats not fixable. Making them not crash is
probably better.
I'd like to get to the bottom of your segfual problem. I though id
probably fixed it.
just to clarify, i mean killall -TERM, not killall -KILL. out of
curiousity, is there a way to tell the scheduler not to pre-empt the
process until the port cleanup is completed ? (sorry if this is a dumb
question, i don't know much about unix programming...)
4 Oct
4 Oct
5:48 a.m.
On Thu, Oct 03, 2002 at 09:38:42 +0200, Joern Nettingsmeier wrote:
heh, having found it on this wierd keyboard it seemed a pity to waste it;)
The food and wine is more of an issue, I´m starting to fantasise about
vegetables (and not having a permenant hangover).
Not that this
is a good thing, it should be fixed. I didn´t check to see
if there was a client name query function. If so I will use that, if not I
will probably just move to always using bridge-<pid>. ¿comments?
hehe, watch out and stay out of the sun, your punctuation is already
becoming spanish :) i like the pid approach. i don't know if i fully
understand its
implications, but it feels like this should be added to the jack docs as
a "best practise" recommendation.
The downside is its ugly, and you tend to end up with foo-4535364 and
foo-4535384 which are hard to tell apart at a glance. It does cheaply
guarantee uniqueness though.
some meterbridges run.
i issue "killall meterbridge".
meterbridge receives a SIGTERM, the exit handler is called and all
functions you registered with atexit() are executed (i.e. the port
restoration).
the problem is, when there are multiple processes called meterbridge,
they will all be killed at once and their exit functions will likely run
concurrently. which is bad, because one instance might just have
disconnected, gets pre-empted without having restored the old
connection, another instance tries to clean up and BANG! the signal
chain is broken. i *think* this is what i'm seeing.
Yes, thats right, the client diconnects its inputs then connects them to its
outputs. That isnñt an atomic operation, so you will get connection loss
in big chains.
Reversig the order would help, but its not possible ATM because there is
no connection quering API. I try to disconect everything and reconnect
that ones that are disconnected.
Maybe a jack-killall could do a better job, by telling the clients to
shutdown one by one, then killing them if they dont. Does jack know the
clients pid?
how would you (in theory) handle this ? is there a way
for userspace
apps to declare a part of their code atomic ? if not, would it make
sense to use a lockfile upon entering the port reconnection code ?
Lockfiles are a pain, I try to aviod them if possible. But, yes, if I
thought it was vital I would use a lockfile.
- Steve
9:40 a.m.
how would you (in theory) handle this ? is there a way
for userspace
apps to declare a part of their code atomic ? if not, would it make
no.
sense to use a lockfile upon entering the port
reconnection code ?
the port reconnection code is evil. i think its completely the wrong
approach. its just a kludge to avoid using a patch bay.
--p
8098
days inactive
8103
days old
linux-audio-dev@lists.linuxaudio.org
9 comments
3 participants
participants (3)
-
Joern Nettingsmeier -
Paul Davis -
Steve Harris