Linux-audio-dev May 2009

linux-audio-dev@lists.linuxaudio.org

61 participants
47 discussions

Keeping "guardians" and "rebels" on the same boat

by Stéphane Letz

Hi all, I would be happy to get some reactions of this proposal that tries to keep the "guardians" and the "rebels" on the same boat. The pdf file for this proposal is : http://www.grame.fr/~letz/jackcontrol2.pdf. Compared to latest Fons proposal, this proposal basically combine the "control daemon" and the "jackd" server in a *unique* extended jackd (with control API IPC) (see 5). It also tries to minimize the number of shared libraries in the system, although we may decide to break-up the code in separated libraries if this is really needed (see 3). Concerning Torben proposal to have "control plug-ins" be part of the server, I agree with Fons here: this would be quite limited and more complex: a new interface would have to be defined, "who" is loading those plug-ins in the server... and so on. Let me explain it again: The first "big" conceptual change compared to the current SVN state is this new "control IPC" scheme. That is the so called control API can be used on client side also. The other point is this concept of "multi- config share state" (see 3). 1) Server side: - libjackserver.so contains: server code + C control API + "new" IPC control API (server side) + C Jack API + IPC Jack API (server side) - jackd executable is linked with libjackserver.so (nothing new here) - backends (ALSA, dummy...) are linked with libjackserver.so (nothing new here) - a "standalone" client (that wants to embed the server in it's process) is linked with libjackserver.so and directly uses the C control API to control/start the server and C Jack API to be a client (nothing new here). 2) Client side: - libjack.so contains : "new" IPC control API (client side) + IPC Jack API (client side) + config API (TO BE DEFINED) - clients are linked to libjack.so (nothing new here) - new control front-end (jackdbus, jackOSC...) are linked to libjack.so: they control the server using the IPC control API (client side), they can be regular clients using IPC Jack API (client side) to deal with connections management and so on... - a "default" centralized state for the server is always kept in ~/ jackdrc. When a client wants to auto-start, this "default" state is used. (this is important to keep in mind) - libjack may have to start the "jackd" executable using the fork+exec way, or the "jackd" process is an "always running + relaunch" process (this has to be more defined later on...) - Qjakctl stays as a regular client, it can still start the "jackd" process as usual. It can keep its own way of keeping multiple configurations as it does now. - more sophisticated control front-end (jackdbus, jackOSC...) are now regular clients. They can use the IPC control API (client side) for more sophisticated control of the server. As regular clients, they access the API to control connections... and so on. The important thing is that those clients are *obliged* to deal with this "default" centralized state. 3) Centralized multi-settings share state - the idea is to provide a way to *share* multiple server configurations in a unique place for all control applications. This is part the D-Bus proposal in some sense. WE HAVE TO DECIDE IF WE WANT THIS FEATURE BE PART OF JACK OR NOT (this can be coded as part of libjack.so or in a separated library called "libjackconfig.so" is we need to share this code between the sever and client side). - If we don't share a unique state, then any control application (jackdbus or any other in the future) will have the choice to use any format (XML...) but then obviously we loose the fact that all control applications would always see the same settings. 4) General: - a single jack2 package is needed. It contains the "jackd" daemon/ server as before. - "jackdbus" is now conceptually separated from the Jack source code. It only uses jack.h + control.h + config.h (??) and is linked to libjack.so as any regular client. It can be distributed separately as a more sophisticated control front-end available, or be available in the jack2 package. 5) Points of discussion: - this model is somewhat simplified compared to the latest Fons proposal (a daemon process + [possibly] several separated jackd servers). The point is that separated processes for control daemon and jackd servers would need another mechanism for "control daemon" <===> jackd server communications (that is: the control daemon launches the jackd server, but then has to control it while it is running, possibly get some info from it (notifications.. etc..)). If we stay with a unique "extended jackd" (with control API IPC), then things are a lot simpler. We can consider that having a single running jackd server is a common case and having several running jackd server a "corner case". It we decide that several running jackd servers is really necessary, then the "extended jackd" can still handle the situation if we accept to have several jackd servers running in a same process. Otherwise a more complex model for "completely separated control daemon and several jackd servers" has to be defined. - multi-config stare state: is this part of Jack or not? - if multi-config share state is part of Jack, then a new API to handle that has to be defined - when proposing new things, please keep in mind that jack2 is now multi-platform... don't be too Linux focused. Comments welcome! Stéphane

14 years, 11 months

more jack/qjackctl madness

by Fons Adriaensen

To whom it may concern: (again) Jackdmp 1.9.2, Qjackctl 0.3.4 I do the following: - Log in. - Start a jack app. - The app starts jackd, but using the wrong card, and things don't work as expected. Questions: 1. Which parameters are used for such an autostart ? Certainly not the ones in ~/.jackdrc, these would have been correct. 2. Qjackctl also ignores ~/.jackdrc, so what is the purpose of this file ? - I terminate the app. Check with ps, there is no more jackd running. - I start qjackctl. It immediately shows a running jackd, but his has restarted the previous wrong one. - Click Stop, Start in qjackctl. Get the same wrong jackd again. - Verify qjackctl's Setup window. This shows the settings for the right jackd, while it is running another one. This is *madness* One more: you can't terminate qjackctl without terminating jackd as well. Why not ? Killing qjackctl does the right thing. A request to the jackdmp and qjackctl devs: PLEASE REMOVE THAT DBUS MADNESS Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

14 years, 11 months

Line Array with AMBDec or WFSfocus

by Tom Brooke

I am looking to put together a line array speaker system and I would like to experiment with with adjusting the focus with dsp. I looked at the AES article about WFSfocus by Fons Adriaensen and it looks like this could be used and it also looks like ambdec could be adopted by changing the filters. I plan to have a stereo pair of 8 woofer tweeter combinations per side Does anyone know if WFsfocus is available or suggestions for adopting ambdec. Or if this is even feasable Tom Brooke

14 years, 11 months

Re: [LAD] [ANN] guitarix-0.04.4-1 release

by James Warden

that's my point: there's no point in checking the pointer validity after you pass it as an argument to a 3rd party function ;) I believe Hermann just made a quick hack last night and he got things cleaned up at last :) Cheers, J. --- On Sun, 5/24/09, Fons Adriaensen <fons(a)kokkinizita.net> wrote: > From: Fons Adriaensen <fons(a)kokkinizita.net> > Subject: Re: [LAD] [ANN] guitarix-0.04.4-1 release > To: linux-audio-dev(a)lists.linuxaudio.org > Date: Sunday, May 24, 2009, 9:48 AM > On Sun, May 24, 2009 at 05:36:49AM > -0700, James Warden wrote: > > > > I think any jack function will check if the client > pointer passed > > as an argument is valid so it is safe to call > jack_get_buffer_size > > before checking the client pointer validity. > > Probably (didn't check) Jack will survive, but don't > expect a valid return value if your client* is bogus. > What's the point of doing this ? > > Ciao, > > -- > FA > > Io lo dico sempre: l'Italia è troppo stretta e lunga. > > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev(a)lists.linuxaudio.org > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev >

14 years, 11 months

Re: [LAD] [ANN] guitarix-0.04.4-1 release

by James Warden

Hi Hermann, Great, I tested it against jack1 and jack2, and it is working fine now :) I looked at your additions. I have a couple of comments, nothing you should consider as important or critical: - guitarix.cpp, line 529-530: I think any jack function will check if the client pointer passed as an argument is valid so it is safe to call jack_get_buffer_size before checking the client pointer validity. However, I have the habit of checking pointer validity before passing it to a 3rd party function. You never know, when the 3rd party lib is closed-source and its API badly documented, you may get crashes. It's not the case here so you can keep it like that. - guitarix.cpp, line 570-579: I would create a local function for this block of code because you call it in some other place as well. You will have only one place to maintain and gain more control on the variation of gNumOutChans. Turn it into: if (merke == 0) { gtx_unregister_ports(); } - german looking variable names: I have nothing against german, even learned it at school :D but it's open-source, not open-german-source ;) - I would also formalize a bit more what is guitarix's code so someone can tell right away which is your code and which is not. For example, start all your home made standalone functions with gtx_ (for GuiTariX) For home made classes, GtxSomeClass For class members of home made classes: fGtxSomeMember For class methods of home made classes: gtxSomeMethod() This will become much more readable. You don't have to though, and cleaning up is a bit of a tedious job ... but if it is to grow as you add more functionality, keep this in mind :) Thanks for your work, I heard that you had to spend quite some time last night to make my patch fit in for jack1 ;) Tschuess :) J. --- On Sun, 5/24/09, hermann meyer <brummer-(a)web.de> wrote: > From: hermann meyer <brummer-(a)web.de> > Subject: Re: [LAD] [ANN] guitarix-0.04.4-1 release > To: warjamy(a)yahoo.com > Cc: linux-audio-dev(a)lists.linuxaudio.org > Date: Sunday, May 24, 2009, 2:17 AM > Am Samstag, den 23.05.2009, 05:04 > -0700 schrieb warjamy(a)yahoo.com: > > discussion started at LAD about changing the jack > server latency from the app called guitarix (like ardour > does from its menu JACK -> Latency). Proposed guitarix > patch (by me) works nice against jack2 but not against > jack1. See below. > > > > Hermann, > > > > I quickly ran guitarix in debug mode through gdb. You > get a crash at dsp_audio.cpp, line 469. Looks like memory at > output[2] and output[3] cannot be accessed. I tried to > understand what you attempt to do but this function > (mydsp::compute) is way to much for me to understand. It > looks like some sort of auto-code ... > > > > Anyway, output[2] and output[3] are passed in from > process() (process callback function). I believe these > arrays should correspond to buffers that you receive from > jack audio ports 2 and 3. However, at the time we try to > change the latency, they are already unregistered because of > DSP.setNumOutputs(). > > > > So it looks to me that resetting the jack buffer size > on the fly from guitarix badly interacts with how jack1 > handled your port deregistration requests. I don't know why > it works with jack2. Running guitarix through gdb against > jack2, I could see that output[2] and output[3] were still > valid memory locations after changing the jack buffer size > on the fly. > > > > This is a bit unfortunate that we get different > behaviors when using jack1 or jack2. I hope you'll sort it > out, I don't have more time to spend on it. > > > > J. > > > Morning James > > So I got it working. Your Code is submit to SVN with some > little > additions. Thanks James, that is the "first direct code > contribution" > the guitarix projekt recive, I hope more will follow. :D > > >

14 years, 11 months

Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...

by Stéphane Letz

Le 19 mai 09 à 11:30, Fons Adriaensen a écrit : > On Tue, May 19, 2009 at 10:38:24AM +0200, Stéphane Letz wrote: > >> 5) Another idea would be improve the "choice of auto-start >> strategy" by >> providing a runtime choice for that: a way for the user to select >> between >> the "classic", "D-Bus", "OSC", strategy once globally for a given >> working >> session... > > I will be writing an OSC layer (on top of the existing interfaces) > because I badly need a soluting for scriptable (i.e. non-interactive) > remote control of jackd. > > It will be non-invasive and just use the existing jackd/libjack > without modifying anything. There will be no such thing as an > 'OSC autostart strategy'. > > IMHO dbus could be just the same. This would mean that > any advantages it may bring will be there only if app > writers start using it *explicitly* by directly calling > dbus instead of a jackd/libjack C API function. > > Which just means that dbus will have to prove its value > in the market instead of being forced onto everyone, > and that is a Good Thing (TM). > > Support for accessing dbus could even be integrated in > libjack (or some new library) as long as it just adds > ew calls and does not modify the action of any existing > C API call. > > Ciao, > > -- > FA It seems you really don't want to see that using this "jack_client_open does a fork+exec call to launch jackd with the ./ jackdrc file" has been completely *hard coded* in libjack from day one! And is a really strong constraint for any possible new way of controlling the server. The discussion is now: do we keep this "hard coded thing in libjack" or do we try to relax it a bit ? Stephane

14 years, 11 months

Re: [LAD] [ANN] guitarix-0.04.4-1 release

by warjamy＠yahoo.com

discussion started at LAD about changing the jack server latency from the app called guitarix (like ardour does from its menu JACK -> Latency). Proposed guitarix patch (by me) works nice against jack2 but not against jack1. See below. Hermann, I quickly ran guitarix in debug mode through gdb. You get a crash at dsp_audio.cpp, line 469. Looks like memory at output[2] and output[3] cannot be accessed. I tried to understand what you attempt to do but this function (mydsp::compute) is way to much for me to understand. It looks like some sort of auto-code ... Anyway, output[2] and output[3] are passed in from process() (process callback function). I believe these arrays should correspond to buffers that you receive from jack audio ports 2 and 3. However, at the time we try to change the latency, they are already unregistered because of DSP.setNumOutputs(). So it looks to me that resetting the jack buffer size on the fly from guitarix badly interacts with how jack1 handled your port deregistration requests. I don't know why it works with jack2. Running guitarix through gdb against jack2, I could see that output[2] and output[3] were still valid memory locations after changing the jack buffer size on the fly. This is a bit unfortunate that we get different behaviors when using jack1 or jack2. I hope you'll sort it out, I don't have more time to spend on it. J. PS: by the way, be careful with hardcoded values. On one hand you have gNumOutChans (= 4), on the other you have arrays declared with [4]. --- On Sat, 5/23/09, hermann meyer <brummer-(a)web.de> wrote: > From: hermann meyer <brummer-(a)web.de> > Subject: Re: [LAD] [ANN] guitarix-0.04.4-1 release > To: "James Warden" <warjamy(a)yahoo.com> > Cc: linux-audio-dev(a)lists.linuxaudio.org > Date: Saturday, May 23, 2009, 2:24 AM > Am Freitag, den 22.05.2009, 09:07 > -0700 schrieb James Warden: > > Hermann, > > > > I added a Latency menu to guitarix. You can now change > the jack server latency on the fly from guitarix (a la > ardour). See patches below: > > > > --------- > > Hi James > > Many thanks, it's real welcome, but unfortunatly I > experience a lot of > chrash's with your patch added. > I work (at time) with jackd, not jackdmp, and guitarix > recive often a > wrong(NULL) pointer after change the buffer size and > chrash'd, also, > when jackd cant set the selected buffersize, jackd > chrash'd. > So here is a proper errorhandling needed. > > Anyway, I have include the jack_set_buffer_size_callback, > to recreate > the intern buffer's from guitarix, when the buffersize > change, so that > guitarix can handle a buffersize change (currently not > commit). > > I did'nt have check it with jackdmp, did it work for you > without > experience some chrash's ? > > regards > hermann > >

14 years, 11 months

Re: [LAD] [ANN] guitarix-0.04.4-1 release

by James Warden

Hi Hermann, wow, I forgot to test against jack1 ... mmmm, strange, they use the same API. I have no problem at all when using it against jack2. I will investigate a bit more later today and let you know. FYI, I use jack2 svn@3540. J. --- On Sat, 5/23/09, hermann meyer <brummer-(a)web.de> wrote: > From: hermann meyer <brummer-(a)web.de> > Subject: Re: [LAD] [ANN] guitarix-0.04.4-1 release > To: "James Warden" <warjamy(a)yahoo.com> > Cc: linux-audio-dev(a)lists.linuxaudio.org > Date: Saturday, May 23, 2009, 2:24 AM > Am Freitag, den 22.05.2009, 09:07 > -0700 schrieb James Warden: > > Hermann, > > > > I added a Latency menu to guitarix. You can now change > the jack server latency on the fly from guitarix (a la > ardour). See patches below: > > > > --------- > > Hi James > > Many thanks, it's real welcome, but unfortunatly I > experience a lot of > chrash's with your patch added. > I work (at time) with jackd, not jackdmp, and guitarix > recive often a > wrong(NULL) pointer after change the buffer size and > chrash'd, also, > when jackd cant set the selected buffersize, jackd > chrash'd. > So here is a proper errorhandling needed. > > Anyway, I have include the jack_set_buffer_size_callback, > to recreate > the intern buffer's from guitarix, when the buffersize > change, so that > guitarix can handle a buffersize change (currently not > commit). > > I did'nt have check it with jackdmp, did it work for you > without > experience some chrash's ? > > regards > hermann > >

14 years, 11 months

Re: [LAD] [ANN] guitarix-0.04.4-1 release

by James Warden

Hermann, I added a Latency menu to guitarix. You can now change the jack server latency on the fly from guitarix (a la ardour). See patches below: --------- PATCH Start guitarix.cpp ----------- Index: guitarix.cpp =================================================================== --- guitarix.cpp (revision 125) +++ guitarix.cpp (working copy) @@ -9,7 +9,7 @@ // global static fields -GtkWidget* fWindow, *menul, *menus, *pb, *midibox, *fbutton, *label1, *menuh; +GtkWidget* fWindow, *menul, *menus, *menulat, *pb, *midibox, *fbutton, *label1, *menuh; GdkPixbuf* ib, *ibm, *ibr; GtkStatusIcon* status_icon; GtkWidget* livewa; @@ -203,6 +203,32 @@ bool GTKUI::fInitialized = false; list<UI*> UI::fGuiList; +//----menu function latency +void set_jack_buffer_size(GtkCheckMenuItem *menuitem, gpointer arg) +{ + // let's avoid triggering the jack server on "inactive" + if (gtk_check_menu_item_get_active(menuitem) == false) + return; + + // are we a proper jack client ? + if (!client) { + cerr << "<*** guitarix.cpp: set_jack_buffer_size()" + << " we are not a jack client, server may be down ***>" + << endl; + return; + } + + + // if the buffer size is the same, no need to trigger it + jack_nframes_t buf_size = (jack_nframes_t)GPOINTER_TO_INT(arg); + + if (buf_size == jack_get_buffer_size(client)) + return; + + // let's resize the buffer + jack_set_buffer_size(client, buf_size); +} + //----menu funktion play stop void play_function (GtkCheckMenuItem *menuitem, gpointer checkplay) { ---------- PATCH END guitarix.cpp -------------- ---------- PATCH START GTKUI.cpp --------------- Index: GTKUI.cpp =================================================================== --- GTKUI.cpp (revision 125) +++ GTKUI.cpp (working copy) @@ -897,6 +897,7 @@ GtkWidget *menuHelp; GtkWidget *menuLoad; GtkWidget *menuSave; + GtkWidget *menuLatency; GtkWidget *menubar; GtkWidget *menu; GtkWidget *menu1; @@ -948,6 +949,40 @@ gtk_widget_show (menuitem); /*---------------- End Engine menu declarations ----------------*/ + /*---------------- Create Latency menu items --------------------*/ + /*-- Create Latency submenu under Engine submenu --*/ + menuLatency = gtk_menu_item_new_with_label ("Latency"); + gtk_menu_bar_append (GTK_MENU_BAR(menubar), menuLatency); + menulat = gtk_menu_new(); + gtk_menu_item_set_submenu(GTK_MENU_ITEM(menuLatency), menulat); + + /*-- Create menu item under Latency submenu --*/ + gchar buf_size[8]; + const int min_pow = 5; // 2**5 = 32 + const int max_pow = 13; // 2**13 = 8192 + group = NULL; + + for (int i = min_pow; i <= max_pow; i++) { + int jack_buffer_size = (int)pow(2.,i); + (void)snprintf(buf_size, 5, "%d", jack_buffer_size); + menuitem = gtk_radio_menu_item_new_with_label (group, buf_size); + group = gtk_radio_menu_item_get_group (GTK_RADIO_MENU_ITEM (menuitem)); + gtk_check_menu_item_set_active (GTK_CHECK_MENU_ITEM (menuitem), FALSE); + + g_signal_connect (GTK_OBJECT (menuitem), "activate", + GTK_SIGNAL_FUNC (set_jack_buffer_size), + GINT_TO_POINTER(jack_buffer_size)); + + // display actual buffer size as default + if (client) + if (jack_buffer_size == (int)jack_get_buffer_size(client)) + gtk_check_menu_item_set_active (GTK_CHECK_MENU_ITEM (menuitem), TRUE); + + gtk_menu_append(GTK_MENU(menulat), menuitem); + gtk_widget_show (menuitem); + } + /*---------------- End Latency menu declarations ----------------*/ + /*---------------- Create Settings menu items --------------------*/ menuEdit = gtk_menu_item_new_with_label ("Presets"); gtk_menu_bar_append (GTK_MENU_BAR(menubar), menuEdit); @@ -1074,6 +1109,7 @@ gtk_widget_show(handlebox); // remove handelbox here gtk_widget_show(menuitem); gtk_widget_show(menuFile); + gtk_widget_show(menuLatency); gtk_widget_show(menuEdit); gtk_widget_show(menuLoad); gtk_widget_show(menuSave); ------------ PATCH END GTKUI.cpp Feel free to add this functionality or not. Cheers! J. --- On Thu, 5/21/09, hermann meyer <brummer-(a)web.de> wrote: > From: hermann meyer <brummer-(a)web.de> > Subject: [LAD] [ANN] guitarix-0.04.4-1 release > To: linux-audio-dev(a)lists.linuxaudio.org > Date: Thursday, May 21, 2009, 8:56 AM > guitarix is a simple Linux Rock > Guitar amplifier for jack(Jack Audio Connektion Kit) > with one input and two outputs. Designed to get nice > thrash/metal/rock/blues > guitar sounds. . . . > > > Some new effect's in the amp section with new controllers, > overworked tuner, overworked midi output > (still it is experimental but can be usefull for rhythm > blues or jazz or. . . fun) > > Many thanks to Orcan Ogetbil (Fedora) for give the right > hint to impruve the tuner, > and the patch's to create a proper Makefile and more, > thanks Orcan. > > have fun > ________________________________________________________________________ > > guitarix based on Gtk, a great part is also realesed as > ladspa plugin. > guitarix is licensed under GPL > > Projektpage with screenshots: > http://guitarix.sourceforge.net/ > > download: > http://sourceforge.net/projects/guitarix/ > > > For capture guitarix make use of jack_capture ver >= > 0.9.30 from Kjetil > S. Matheussen. If you dont have it installed, look here: > > http://old.notam02.no/arkiv/src/?M=D > > For extra Impulse Response guitarix make use of jconv from > Fons Adriaensen. If > you dont have it installed, look here: > > http://www.kokkinizita.net/linuxaudio/index.html > > I use faust to build the prototype and will say thanks to > > : Julius Smith > http://ccrma.stanford.edu/realsimple/faust/ > > : Albert Graef > http://www.musikwissenschaft.uni-mainz.de/~ag/ag.html > > : Yann Orlary > http://faust.grame.fr/ > > > regards hermann > > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev(a)lists.linuxaudio.org > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev >

14 years, 11 months

Re: [LAD] phasex building/bug/suggestion

by hollunder＠gmx.at

On Thu, 21 May 2009 21:52:43 -0700 (PDT) William Weston <weston(a)sysex.net> wrote: > On Fri, 22 May 2009, hollunder(a)gmx.at wrote: > > > On Thu, 21 May 2009 16:45:08 -0700 (PDT) > > William Weston <weston(a)sysex.net> wrote: > > > >> On Thu, 21 May 2009, hollunder(a)gmx.at wrote: > >> > >>> Hi William, > >>> I just tested it a bit and it works really well, a huge > >>> improvement over 0.11.1 and really fun to play around. > >>> However, I found some minor weirdness and what looks like a bug to > >>> me. > >>> > >>> 1) autogen behaves strangely: > >>> > >>> $ ./autogen.sh > >>> **Error**: Directory `.' does not look like the top-level package > >>> directory > >>> > >>> This was in the top level dir, the one where autogen.sh is > >>> located. > >> > >> I should really remove autogen.sh from the source tree. I used it > >> to create an initial configure.ac, and haven't touched it since. > >> The following should work for new builds: > >> > >> aclocal > >> autoconf > >> automake > >> autoheader > >> ./configure --enable-arch=foo (where foo is a gcc supported arch) > >> make > >> make install > > > > So far I used the following in a script that builds a package from > > source: > > > > ./configure --prefix="/usr" --enable-arch="native" > > make > > make DESTDIR="$pkgdir/" install > > > > "$pkgdir/" is just a variable in this script. > > "native" is something like i686, this machine is an old-ish amd > > athlon XP3000+. > > > > What difference do these steps make? > > > > aclocal > > autoconf > > automake > > autoheader > > These four steps are almost a guarantee that an autoconf enabled > project will build on your system. When compiling anything and > having issues with ./configure && make, I always go for this series > to rebuild all the autogenerated files. Works like a charm most of > the time, especially for packages that weren't released on the same > distro that I'm trying to build for. > > Aclocal sets up some system dependent variables that configure > expects to have defined. This usually isn't needed unless you're > building with another version of autoconf, but it doesn't hurt > either. > > Autoconf rebuilds configure from configure.ac. Ususally, the > existing configure script will work just fine, but again, it doesn't > hurt. > > Automake builds a Makefile for each Makefile.am. > > Autoheader builds a config.h from a config-h.in. > > You bring up a very good point here. The normal ./configure && make > should just work for most builds. I'm going to look into this some > more and make sure the stable release gets it right. Thanks for the detailed explanation. It's almost certainly a different distro and version of several applications, so I'll try these steps, even if ./configure && make seems to work. Thanks for looking into it. > >>> 2) It looks like make is running configure again, although > >>> configure needs to be run before make can be run, so this seems > >>> to be redundant. > >> > >> I've noticed this before, normally after running autoconf. Once > >> the configure script is rebuilt, make shouldn't decide to rebuild > >> it. Does this happen every time for you, or just after cleaning up > >> and re-running aclocal and/or autoconf? > > > > The above-mentioned script always builds from a clean tarball or > > clean copy of the tarball so I always got it so far, but I just > > tried it. From a clean directory I ran > > configure [options], make, configure [no options], make > > and the second make didn't configure. > > > >>> 3) When playing a little piano piece I noticed that it cuts off > >>> some notes prematurely for some reason, likely timing related, > >>> even in poly-mode. The attached midi file should work as > >>> demonstration, note how the notes played by the right hand get > >>> cut long before the note-off. Both hands play continuously except > >>> for the end, so it should be easy to spot. Simple sounds like > >>> preset #3 work best. > >> > >> Sounds like you might be hitting the polyphony limit. What CPU are > >> you building for? CPU dependent things are configured in > >> src/phasex.h. Sane defaults where chosen for all the common x86 > >> CPU types (broken up into three classes) so as not to bog down the > >> realtime system, but depending on CPU power, you might be able to > >> squeeze a little more out of your machine. > > > > Judging from what 'top' tells me phasex isn't using that much cpu. > > Are you looking at top with voices in play? The CPU consumption > goes up with the number of voices currently being generated. When idle it chews around 6-15%, with 6 voices playing 25-30%. > > src/phasex.h: > > # define PHASEX_CPU_POWER 2 > > > > #if (PHASEX_CPU_POWER == 2) > > # define NUM_VOICES 6 > > #endif > > > > So this could indeed be the polyphony limit. > > Yes it is. I've been keeping it low enough to get full polyphony > out of two instances without choking up the realtime (I generally > run 4-6 instances and run sequencing out of MusE). I've been > thiknking of setting up the default builds with more polyphony and > treating the running of multiple instances as the special cases. It seems like with the default settings I could have at least 3 instances playing at the same time. Does it hurt if it is compiled for many voices and multiple instances are run with a low voice count each? In other words, does the compile with many voices impact performance even if these voices aren't used? Personally I think that the voice limit defined at compiletime is a problem, especially if it is that low. Most distributions out there are pure binary based, so they'll have to make a choice for their users with a wide variety of machines. Some switch at application start + sane default or auto-detection would be preferable. I usually only write scripts that build from source for my distro's community repository, like this one: http://aur.archlinux.org/packages/phasex-git/phasex-git/PKGBUILD where this isn't really an issue, but we are in the process of making a binary audio repository so we face that problem as well. > > Can I pass this at configure-time somehow or do I need to sed? > > You can override the definitions at configure time by passing new > ones as debug flags to the compiler: > > ./configure --enable-arch=athlon-xp --enable-debug="-DNUM_VOICES=12" Ah, thanks a lot, I will experiment. Does enable-debug have other implications/sideeffects? > >>> 4) A suggestion: > >>> Especially when playing back files and stopping in between you can > >>> get hung notes that can swell quite immensely and are hard to get > >>> rid of (well, you have to somehow hit the right note to get a > >>> note-off). Similar stuff could happen in other situations. > >>> Something like a panic-button that kills all sounds could help. > >> > >> The hung notes are most likely due to not receiving note off > >> messages (a problem with a lot of players when stopping > >> mid-stream). Phasex responds to the all-notes-off controller > >> message, but that's not available on a lot of controllers, so the > >> panic button sounds like a great idea. I'll see about > >> implementing it for 0.12.0-stable. > >> > >>> That's it for now, thanks a lot for phasex, it's really fun to > >>> play. > >> > >> Thanks for your support. Happy music-making! > >> > >> --ww > > > > Thanks, > > I haven't made a lot of music yet but the sounds that phasex > > produces are very inspiring to me (and I just bought nice monitors > > and a mic, so I kind of have to make some music now). > > The new monitors will make a *huge* difference for any style of > music. You won't regret your purchase. Of course, you'll be hooked > and start shopping for outboard preamps, compressors, eqs, etc... > Or at least that's what happened right after I bought new monitors. Definitely, this was the best purchase I did, ever. The difference is huge, now it's really a joy to listen to music, understanding lyrics, hear and feel bass, stereo image.. it's really great. For now it has to be enough gear, monitors, e-piano, a nice mic and a linux box full of audio apps, far more than is needed for making music. Reminds me to try the phasex audio in :) > Enjoy! I will :) Best regards, Philipp

14 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev May 2009