Re: [LAD] phasex building/bug/suggestion

On Thu, 21 May 2009 21:52:43 -0700 (PDT)
William Weston <weston@email-addr-hidden> wrote:

> On Fri, 22 May 2009, hollunder@email-addr-hidden wrote:
>
> > On Thu, 21 May 2009 16:45:08 -0700 (PDT)
> > William Weston <weston@email-addr-hidden> wrote:
> >
> >> On Thu, 21 May 2009, hollunder@email-addr-hidden 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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Fri May 22 16:15:03 2009