On Thu, 21 May 2009 21:52:43 -0700 (PDT) William Weston <[email protected]> wrote:
> On Fri, 22 May 2009, [email protected] wrote: > > > On Thu, 21 May 2009 16:45:08 -0700 (PDT) > > William Weston <[email protected]> wrote: > > > >> On Thu, 21 May 2009, [email protected] 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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
