Re: [LAD] phasex building/bug/suggestion - Linux-audio-dev

22 May 2009

On Thu, 21 May 2009 21:52:43 -0700 (PDT)
William Weston &lt;weston(a)sysex.net&gt; wrote:

...
  On Fri, 22 May 2009, hollunder(a)gmx.at wrote:

  On Thu, 21 May 2009 16:45:08 -0700 (PDT)
 William Weston &lt;weston(a)sysex.net&gt; 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