Re: [yoshimi-user] I broke it :(
- From: "Jonathan E. Brickman" <jeb@xxxxxxxxxxxxxxx>
- To: yoshimi-user@xxxxxxxxxxxxxxxxxxxxx
- Date: Sun, 28 Feb 2010 15:32:55 -0600
Yes, it was my crazy hybrid that died.
While it was out of action I tried Ubuntu studio, and Musix - neither
were usable at all, x-runs and crashes all over the place.
I then tried to re-create the steps I originally took to get where I
had been. I thought I'd got it right, but jack is very 'delicate' and
all sorts of audio apps time out very easily. This applies to the whole
Zyn& friends range, and also to Rosegarden, so I suspect it really is
a jack/alsa problem of some sort.
How on earth do you track down something like that?
A number of things have emerged to me. Perhaps some of them will be
applicable.
1. Kernel. Are you running the 64s-3b3 standard kernel, or one fed to
you by Debian? Definitely you need a good one, custom-made if not
64s-3b3, AVLinux, or CCRMA. I miswrote recently, by the way: in my
experience AVLinux is by far the fastest way to pro audio, CCRMA second,
Debian Testing with custom kernel is third.
2. glib. I took a big risk four or five days ago and updated my
(currently Debian Testing) rig's glib, and to my great shock have
experienced a near-100% visible performance increase, with consequent
improvement in horsepower delivered to Yoshimi.
3. Debian Lenny includes. I would stay away from these entirely. In
fact, I wonder how a given system can be stable if it uses Debian Lenny
binaries alongside Testing and later. You will see what I mean if you
take a Lenny system (or 64studio 2.0) and try to install the latest Xorg
from Debian Testing: apt will take in a large number of new
dependencies, but the system will be munged /terribly/, to the point of
hard-drive scrub being the most straightforward option.
4. Jackd versions. This has gotten very sticky for me in the past.
Lenny and 64s-2 have versions of Jackd so old as to be big trouble, and
when I tried to update them, I found I was smashing my head into
multiple dependencies of dependencies which brought me to the latest
Xorg...which is why #3 above happened twice! This is likewise why and
how AVLinux and CCRMA are so good; both take painstaking care to deliver
the current best working versions of Jackd and other libraries, which
the others (save Debian Testing with Experimental and Multimedia
libraries added) don't. Of the three approaches, CCRMA is perhaps the
most stable, because it is the only one using a standardized repo
system: I don't ever think about installing all updates in my Debian
Testing platform, because I am confident I would trash /something/ which
I want very much to be using :-)
5. Jackd configuration. Configuration of 0.118 and its close relatives
is only somewhat mysterious (and I imagine you know more than I about
that), but jack2 (1.9.4 if you will) gives another big layer of option.
The big one is 'sync' versus 'async' mode in jack2. jack2 in 'async'
mode, the default, gave me just slightly less performance than 0.118;
jack2 in 'sync' mode, which has to be set up using a command-line option
not found in 0.118, has given me possibly three times the overall
horsepower for Yoshimi and other Jackd work, measured in how low I can
push the latency and still have things work :-) I am told, that some
hardware needs it the other way around. And there are more variations.
The $100 sound card by which I am blessed is very good at 96000 frames
per second, which is much higher than many...which pushes my available
horsepower up, and latency down.
6. Desktop. I am multiply told that KDE is very bad news in its
programming structure, concerning xruns and the like. My Gnome is
working just fine, especially at the current glib, but I have Bluetooth
shut off and a number of other things which could suck up RAM and CPU.
AVLinux runs LXDE, which grabs even less; LXDE is probably one way that
AVLinux gets away with delivering good result using its default
non-realtime kernel. There are reports that NetworkManager has caused
xruns on many platforms, and it is the usual default network management
system now; I am running it with no problem, but AVLinux stays away from
it, and it may just be on a 32-bit platform that NM's interference
shows, I am doing 64-bit here.
7. Desktop hidden elements. I'm not sure how to specify this one, but
I'll say what I have seen. A while back I was playing around a lot with
Ubuntu. When I used Synaptic, I noticed that for each package it
installed, it attempted at least two different package-handling binary
calls involving Perl, and failed both, until it reached a third. I
thought this was interesting, so I went and searched for the Perl calls
which failed; the items were literally not there at all, and they were
quite standard and up-to-date Perl binaries available in Synaptic. I
eventually got around to installing desktop components which took in
those items as required dependencies...and lo and behold, the silly
things (package management things!) were kept in RAM all the time as
daemons, and the whole system slowed down. Not hugely, but I could
tell, it was infrastructure-level slowdown not app slowdown, it was the
level of burden which most often causes xruns in unreachable ways. And
if I turned them off, Gnome went haywire. This was the beginning of the
profundity of my disenchantment with Ubuntu, and it has grown since
then; having used better platforms and occasionally retrying Ubuntu as
people suggest, I find that Ubuntu remains "brittle" in the way many
distributions are, they work well until one installs the wrong very
standard package, at which time one, two, or ten different things break,
all of which one had better fix entirely (and in just the right ways) or
more packages will break upon installation.
So #7 becomes, in the end computation, the need to choose distro
platform most carefully. I have run into only a very few distros whose
leadership has the ability to maintain sufficiently high attention to
detail, to prevent a brittleness which becomes evident by at most the
second or third week after installation. And this is why I have settled
on AVLinux, CCRMA, and Debian Testing, why I won't go near Ubuntu Studio
(tried it just once for about five minutes), and why I was saddened
quite a lot during my two multiple-week forays into 64studio 3b3. I
have been strongly tempted to try Arch Linux as a fourth; it is built
with similar attention to detail, but it is not a fast-install distro
which makes large collection-choices, and I am somewhat low on time :-)
J.E.B.
Other related posts:
