19 May
2007
19 May
'07
11:56 p.m.
The [P]hase [H]armonic [A]dvanced [S]ynthesis [EX]periment, version
0.10.2 is ready for download (source tarball and FC6 RPMs) at:
http://sysex.net/phasex/
This release contains many fixes, most notably better support for
older GTK versions. PHASEX now works with GTK2 versions as low as
2.4.x, which should help most of the build issues on older distros.
Here's everything from the Changelog for this release:
* Fixed typos and omissions in parameter help file.
* Improved error handling and reporting in jack.c.
* Fixed JACK thread shutdown.
* Added Pete Shorthose's patch for saving memory with a single
knob anim.
* Added Lars Luthman's patch for improper style handling in
gtkknob.c.
* Fixed knob centering on middle click drag events.
* Cleaned up style and whitespace in gtkknob.c, added boilerplate.
* Added current midimap file to saved settings.
* Fixed build and runtime problems with GTK versions 2.4 to 2.8
* Fixed invalid setting of patch modified flag on startup.
* Updated error message for unhandled ALSA MIDI errors.
* Fixed passing of debug flags in configure.ac.
* Fixed detection of functions in libm.
* Added install of phasex.desktop to Makefile.am.
* Fixed uninitiailized varibable warnings in midi.c.
* Fixed missed internal update on boolean parameters first
switching to zero.
* Removed dead update_widget_val() in callback.c.
* Disabled engine side of audio ringbuffer locking (easier on JACK).
* Changed name of ALSA MIDI sequencer input port for readability.
* Added project roadmap.
Special thanks go to Pete Shorthose and Lars Luthman for your
patches to the gtkknob code, and to the rest of you for offering
incredible feedback, especially on the build issues and ALSA/JACK
startup issues.
Cheers!
--ww
--
/* William Weston <weston(a)sysex.net> */
20 May
20 May
7:46 a.m.
if test -f ./phasex.desktop; then \
/bin/install -c -m 644 ./phasex.desktop /usr/share/phasex; \
desktop-file-install --vendor=sysex --add-category="Audio"
--add-category="AudioVideo" \
--add-category="X-MIDI" --add-category="X-JACK"
./phasex.desktop; \
fi
/bin/sh: line 2: desktop-file-install: command not found
make[2]: *** [install-data-local] Error 127
make[2]: Leaving directory `/home/nedko/sandbox/phasex-0.10.2'
make[1]: *** [install-am] Error 2
make[1]: Leaving directory `/home/nedko/sandbox/phasex-0.10.2'
make: *** [install-recursive] Error 1
I'm able to run what is installed. I still get segfault on exit.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
21 May
21 May
6:51 a.m.
On Sun, 20 May 2007, Nedko Arnaudov wrote:
if test -f ./phasex.desktop; then \
/bin/install -c -m 644 ./phasex.desktop /usr/share/phasex; \
desktop-file-install --vendor=sysex --add-category="Audio"
--add-category="AudioVideo" \
--add-category="X-MIDI" --add-category="X-JACK"
./phasex.desktop; \
fi
/bin/sh: line 2: desktop-file-install: command not found
make[2]: *** [install-data-local] Error 127
make[2]: Leaving directory `/home/nedko/sandbox/phasex-0.10.2'
make[1]: *** [install-am] Error 2
make[1]: Leaving directory `/home/nedko/sandbox/phasex-0.10.2'
make: *** [install-recursive] Error 1
Thanks for pointing this one. Looks like I forgot to check to make
sure 'desktop-file-install' is actually available. Fixed in my
codebase now, and will be out with the next release. This is the
very last thing that happens in a 'make install', so at least it
doesn't break anything else in the install.
I'm able to run what is installed. I still get
segfault on exit.
This one looks like you may have hit a case where the engine
thread is waiting on the buffer ready condition to be broadcast from
the jack thread, which never comes because JACK requested a client
shutdown instead of running the process callback. Does this patch
help?
--- phasex-0.10.2/src/jack.c 2007-05-19 15:22:04.000000000 -0700
+++ phasex/src/jack.c 2007-05-21 01:12:29.000000000 -0700
@@ -231,6 +231,12 @@
*****************************************************************************/
void
jack_shutdown_handler(void *arg) {
+ if (pthread_mutex_trylock(&buffer_mutex) == 0) {
+ buffer_full = 0;
+ buffer_needed = buffer_size;
+ pthread_cond_broadcast(&buffer_has_space);
+ pthread_mutex_unlock(&buffer_mutex);
+ }
if (client != NULL) {
jack_deactivate(client);
jack_client_close(client);
The ringbuffer mutex and condition really need to go away. I'm
planning on it as part of the move to support other audio
frameworks.
Thanks again for you help, Nedko!
--ww
8:02 a.m.
William Weston <weston(a)sysex.net> writes:
This one looks like you may have hit a case where the
engine
thread is waiting on the buffer ready condition to be broadcast from
the jack thread, which never comes because JACK requested a client
shutdown instead of running the process callback. Does this patch
help?
The patch does not help. I beleive the AFAIK the jack_shutdown_handler()
is called only when jackd is being shut down, not during jack client
shutdown. I added printf in the function and it does not show during
phasex shutdown. It appeared however when I tried to stop jackd while
phasex was running (and there were some other strange messagest too):
# phasex
JACK tmpdir identified as [/tmp]
cannot read server event (Success)
cannot complete execution of the processing graph (Resource temporarily unavailable)
zombified - calling shutdown handler
jack_shutdown_handler() called.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
10:46 a.m.
On Mon, 2007-05-21 at 13:03 +0300, Nedko Arnaudov wrote:
William Weston <weston(a)sysex.net> writes:
the shutdown handler is called if the JACK server exits or zombifies the
client (removes it from the process graph). both of these are
indistinguishable from the client side (unless the client goes poking
around the system in a non-portable and inadvisable way).
--p
This one looks like you may have hit a case where
the engine
thread is waiting on the buffer ready condition to be broadcast from
the jack thread, which never comes because JACK requested a client
shutdown instead of running the process callback. Does this patch
help?
The patch does not help. I beleive the AFAIK the jack_shutdown_handler()
is called only when jackd is being shut down, not during jack client
shutdown. I added printf in the function and it does not show during
phasex shutdown. It appeared however when I tried to stop jackd while
phasex was running (and there were some other strange messagest too):
# phasex
JACK tmpdir identified as [/tmp]
cannot read server event (Success)
cannot complete execution of the processing graph (Resource temporarily unavailable)
zombified - calling shutdown handler
jack_shutdown_handler() called. 
4:53 p.m.
On Mon, 2007-05-21 at 13:03 +0300, Nedko Arnaudov wrote:
William Weston <weston(a)sysex.net> writes:
I get the same here every time if i ^O (load a patch) in phasex whilst
something else is running in jack (eg seq24 & a single whysynth). If i
do the ^O whilst seq24 is stopped, i can load the patch without
problems, and i can then do subsequent ^O's whilst seq24 is running.
This one looks like you may have hit a case where
the engine
thread is waiting on the buffer ready condition to be broadcast from
the jack thread, which never comes because JACK requested a client
shutdown instead of running the process callback. Does this patch
help?
The patch does not help. I beleive the AFAIK the jack_shutdown_handler()
is called only when jackd is being shut down, not during jack client
shutdown. I added printf in the function and it does not show during
phasex shutdown. It appeared however when I tried to stop jackd while
phasex was running (and there were some other strange messagest too):
# phasex
JACK tmpdir identified as [/tmp]
cannot read server event (Success)
cannot complete execution of the processing graph (Resource temporarily unavailable)
zombified - calling shutdown handler
jack_shutdown_handler() called.
22 May
22 May
9:21 p.m.
New subject: **[SPAM]** Re: PHASEX-0.10.2
On Mon, 21 May 2007, Graham Biswell wrote:
On Mon, 2007-05-21 at 13:03 +0300, Nedko Arnaudov
wrote:
Check out the patch I just sent out to fix the JACK shutdown issues,
which should take care of phasex shutting down in an unfriendly way
when this happens.
I'll be looking into the patch loading issue next. From what I can
tell, the first access of the File menu (either by hitting it
directly or accessing an item through a keyboard acceleration)
causes enough of a CPU hit to disrupt other threads. This is the
only menu that currently uses the GTK stock items and keyboard
accelerations. Any GTK hackers out there have any tricks for making
sure a GtkAccelGroup has fully initialized itself?
--ww
William Weston <weston(a)sysex.net> writes:
I get the same here every time if i ^O (load a patch) in phasex whilst
something else is running in jack (eg seq24 & a single whysynth). If i
do the ^O whilst seq24 is stopped, i can load the patch without
problems, and i can then do subsequent ^O's whilst seq24 is running. This one looks like you may have hit a case where
the engine
thread is waiting on the buffer ready condition to be broadcast from
the jack thread, which never comes because JACK requested a client
shutdown instead of running the process callback. Does this patch
help?
The patch does not help. I beleive the AFAIK the jack_shutdown_handler()
is called only when jackd is being shut down, not during jack client
shutdown. I added printf in the function and it does not show during
phasex shutdown. It appeared however when I tried to stop jackd while
phasex was running (and there were some other strange messagest too):
# phasex
JACK tmpdir identified as [/tmp]
cannot read server event (Success)
cannot complete execution of the processing graph (Resource temporarily unavailable)
zombified - calling shutdown handler
jack_shutdown_handler() called. 
23 May
23 May
12:54 a.m.
New subject: **[SPAM]** Re: PHASEX-0.10.2
On Tue, 2007-05-22 at 16:21 -0700, William Weston wrote:
I'll be looking into the patch loading issue next.
From what I can
tell, the first access of the File menu (either by hitting it
directly or accessing an item through a keyboard acceleration)
causes enough of a CPU hit to disrupt other threads. This is the
only menu that currently uses the GTK stock items and keyboard
accelerations. Any GTK hackers out there have any tricks for making
sure a GtkAccelGroup has fully initialized itself?
do you have a specific reason to lay blame on the accel group?
more than say, the open dialog? also, does this problem occur
when switching tabs to the oscillators page? the widgets are
realised on demand and there are a tonne of them on that page.
i would have expected much more of an impact from that.
pete.
24 May
24 May
5:56 a.m.
On Wed, 23 May 2007, pete shorthose wrote:
On Tue, 2007-05-22 at 16:21 -0700, William Weston
wrote:
This reasoning was based on the fact that only the file menu uses
accelerators, and only the file menu experienced the delay (and only
on the first access), whether accessed by clicking with the mouse or
using a keyboard accelerator. The first access of the file menu
would cause JACK xruns about half the time, while opening a file
dialog after the file menu has already been accesed would not cause
xruns.
After much experimentation, I came to find that the file menu
slowness was actually caused by the use of GTK's stock items, and no
amount of show/hide/realize calls could get the stock items to do
all of their initialization before the first time they're displayed.
So now that I've put my foot in my mouth, let me rephrase that
question: Any GTK hackers out there have any tricks for making sure
a that menus using stock items get fully initialized so that there
is no extra delay the first time they are accessed?
I'll be looking into the patch loading issue
next. From what I can
tell, the first access of the File menu (either by hitting it
directly or accessing an item through a keyboard acceleration)
causes enough of a CPU hit to disrupt other threads. This is the
only menu that currently uses the GTK stock items and keyboard
accelerations. Any GTK hackers out there have any tricks for making
sure a GtkAccelGroup has fully initialized itself?
do you have a specific reason to lay blame on the accel group?
more than say, the open dialog? also, does this problem occur
when switching tabs to the oscillators page? the widgets are
realised on demand and there are a tonne of them on that page.
i would have expected much more of an impact from that.
I currently have menus without stock items and prebuilt file dialogs
in my codebase, and I can't get the GUI to cause any JACK xruns
anymore. I'll have to admit, redrawing all those widgets on demand
every time they reappear into view still makes it a bit sluggish.
Is there a way to make GTK cache the visual state of widgets (or
even whole windows) so that every widget on the page doesn't need to
be asked how to redraw itself from scratch every time it pops of of
view for whatever reason?
regards,
--ww
6:08 a.m.
On Thu, 2007-05-24 at 00:56 -0700, William Weston wrote:
On Wed, 23 May 2007, pete shorthose wrote:
xruns? The GUI should _never_ be able to affect the audio thread's
performance. Aren't you running JACK in realtime mode?
--ll
On Tue, 2007-05-22 at 16:21 -0700, William Weston
wrote:
This reasoning was based on the fact that only the file menu uses
accelerators, and only the file menu experienced the delay (and only
on the first access), whether accessed by clicking with the mouse or
using a keyboard accelerator. The first access of the file menu
would cause JACK xruns about half the time, while opening a file
dialog after the file menu has already been accesed would not cause
xruns. I'll be looking into the patch loading issue
next. From what I can
tell, the first access of the File menu (either by hitting it
directly or accessing an item through a keyboard acceleration)
causes enough of a CPU hit to disrupt other threads. This is the
only menu that currently uses the GTK stock items and keyboard
accelerations. Any GTK hackers out there have any tricks for making
sure a GtkAccelGroup has fully initialized itself?
do you have a specific reason to lay blame on the accel group?
more than say, the open dialog?
8:09 a.m.
On Thu, 24 May 2007, Lars Luthman wrote:
On Thu, 2007-05-24 at 00:56 -0700, William Weston
wrote:
Yup, I'm running JACK with realtime scheduling, and I had exactly
the same thought. The GUI is running at a normal SCHED_OTHER
priority, and it holds no absolutely no locks needed by other
threads after everything is up and running.
--ww
On Wed, 23 May 2007, pete shorthose wrote:
xruns? The GUI should _never_ be able to affect the audio thread's
performance. Aren't you running JACK in realtime mode? On Tue, 2007-05-22 at 16:21 -0700, William Weston
wrote:
This reasoning was based on the fact that only the file menu uses
accelerators, and only the file menu experienced the delay (and only
on the first access), whether accessed by clicking with the mouse or
using a keyboard accelerator. The first access of the file menu
would cause JACK xruns about half the time, while opening a file
dialog after the file menu has already been accesed would not cause
xruns. I'll be looking into the patch loading issue
next. From what I can
tell, the first access of the File menu (either by hitting it
directly or accessing an item through a keyboard acceleration)
causes enough of a CPU hit to disrupt other threads. This is the
only menu that currently uses the GTK stock items and keyboard
accelerations. Any GTK hackers out there have any tricks for making
sure a GtkAccelGroup has fully initialized itself?
do you have a specific reason to lay blame on the accel group?
more than say, the open dialog?
8:26 a.m.
On Thu, 2007-05-24 at 03:09 -0700, William Weston wrote:
On Thu, 24 May 2007, Lars Luthman wrote:
What kernel is this? Are you using Ingo Molnar's RT patch?
--ll
On Thu, 2007-05-24 at 00:56 -0700, William Weston
wrote:
Yup, I'm running JACK with realtime scheduling, and I had exactly
the same thought. The GUI is running at a normal SCHED_OTHER
priority, and it holds no absolutely no locks needed by other
threads after everything is up and running. On Wed, 23 May 2007, pete shorthose wrote:
xruns? The GUI should _never_ be able to affect the audio thread's
performance. Aren't you running JACK in realtime mode? On Tue, 2007-05-22 at 16:21 -0700, William Weston
wrote:
> I'll be looking into the patch loading issue next. From what I can
> tell, the first access of the File menu (either by hitting it
> directly or accessing an item through a keyboard acceleration)
> causes enough of a CPU hit to disrupt other threads. This is the
> only menu that currently uses the GTK stock items and keyboard
> accelerations. Any GTK hackers out there have any tricks for making
> sure a GtkAccelGroup has fully initialized itself?
do you have a specific reason to lay blame on the accel group?
more than say, the open dialog?
This reasoning was based on the fact that only the file menu uses
accelerators, and only the file menu experienced the delay (and only
on the first access), whether accessed by clicking with the mouse or
using a keyboard accelerator. The first access of the file menu
would cause JACK xruns about half the time, while opening a file
dialog after the file menu has already been accesed would not cause
xruns.
11:09 p.m.
On Thu, 24 May 2007, Lars Luthman wrote:
What kernel is this? Are you using Ingo Molnar's RT patch?
2.6.20-rt8, built with complete preemption, dynamic ticks, high res
timers, timer frequency at 1000Hz, and all of the expensive
debugging features turned off. I'll be trying out 2.6.20-rt7
tonight.
--ww
xruns? The GUI should _never_ be able to affect the
audio thread's
performance. Aren't you running JACK in realtime mode?
Yup, I'm running JACK with realtime scheduling, and I had exactly
the same thought. The GUI is running at a normal SCHED_OTHER
priority, and it holds no absolutely no locks needed by other
threads after everything is up and running. 
2:18 p.m.
On 5/24/07, William Weston <weston(a)sysex.net> wrote:
By any chance, is the IRQ used by your sound card dedicated to it or
is it shared with for instance your video card ? Do you have the same
behaviour when deactivating RENDER and COMPOSITE extensions ?
Cheers,
__________________
Marc-Olivier Barre,
Markinoko.
xruns? The GUI
should _never_ be able to affect the audio thread's
performance. Aren't you running JACK in realtime mode?
Yup, I'm running JACK with realtime scheduling, and I had exactly
the same thought. The GUI is running at a normal SCHED_OTHER
priority, and it holds no absolutely no locks needed by other
threads after everything is up and running. 
6:58 a.m.
Hi,
first congrats! Its an addictive toy already.
Quoting William Weston <weston(a)sysex.net>et>:
<snip>
If you use a compositing window manager such a compose, you'll have a
lot less expose events, as the window manager keeps a copy of the
window-content for composition. Some gtk-hackers also made experiemnts
with offscreen-bitmaps for widgets, but (I belive) it has not been
merged into gtk+ yet.
After much experimentation, I came to find that the
file menu
slowness was actually caused by the use of GTK's stock items, and no
amount of show/hide/realize calls could get the stock items to do
all of their initialization before the first time they're displayed.
So now that I've put my foot in my mouth, let me rephrase that
question: Any GTK hackers out there have any tricks for making sure
a that menus using stock items get fully initialized so that there
is no extra delay the first time they are accessed?
I would ask that on
gtk-app-devel list.
also, does this problem occur
when switching tabs to the oscillators page? the widgets are
realised on demand and there are a tonne of them on that page.
i would have expected much more of an impact from that.
I currently have menus without stock items and prebuilt file dialogs
in my codebase, and I can't get the GUI to cause any JACK xruns
anymore. I'll have to admit, redrawing all those widgets on demand
every time they reappear into view still makes it a bit sluggish.
Is there a way to make GTK cache the visual state of widgets (or
even whole windows) so that every widget on the page doesn't need to
be asked how to redraw itself from scratch every time it pops of of
view for whatever reason?
regards,
--ww
Ciao
Stefan
6375
days inactive
6380
days old
linux-audio-dev@lists.linuxaudio.org
14 comments
8 participants
participants (8)
-
Graham Biswell -
Lars Luthman -
Marc-Olivier Barre -
Nedko Arnaudov -
Paul Davis -
pete shorthose -
Stefan Kost -
William Weston