I didn't accomplish very much after work tonight toward debugging this
problem, but I have some new information to report.
Since 'audacity' was working for me just a few months ago, I decided I
wanted to try to locate an earlier version that works on my hardware. I
looked at /usr/share/doc/audacity/changelog.Debian.gz, and my best guess
is that I last used version 1.3.10.
(I really wish that I could bisect using 'git'. Does the 'audacity'
upstream use 'git', or do the Debian maintainers have their own 'git'
repo where they merge new versions from upstream? I am merely a
beginner with tools such as 'git' and 'gdb', but I did spend a month
debugging a kernel issue on LKML when kernel 2.6.26 was hanging during
boot on two of my machines, so I believe I could bisect this if the
sources were available via 'git'.)
In the meantime, it occurred to me that Squeeze or Lenny would have an
older version I could try. Squeeze has the same version as Sid, but
Lenny has (the very old) version 1.3.5. I decided that installing Lenny
binaries in Sid would be a bad idea, but downloaded the sources and
tried to build it. The only changes I had to make to allow the build to
succeed were some paths to header files from the 'vamp-plugin-sdk'
Miracle of miracles! Version 1.3.5 runs fine on my system -- no changes
to my custom /etc/asound.conf file, kernel modules, or anything else
I fully intended to dive into the 1.3.12 source code more seriously
tonight, but once I had a working version of 'audacity'... I ended up
just playing with it instead... :-(
Reinhard: I disagree about FFMPEG being a problem in my case. I
provided the warning about my usage of debian-multimedia.org packages of
FFMPEG only for full disclosure. But it is clear that 'audacity' is
crashing during startup on my system because of initialization routines
that are trying to detect the ALSA devices available on my system.
Nothing involving FFMPEG is being touched (so far as I can tell) either
in the code where the crash occurs or in code reached before that point.
I definitely agree that this bug should be taken upstream. However, I
would like to work on understanding the problem for a few days longer,
in the hope I can pin down more exactly why 'audacity' is choking when
trying to grok my system's ALSA devices. Adrian and I have already
discovered some poorly written code, and no doubt there is more such
code in the vicinity which should be challenged upstream. Besides, this
is my big chance to play with 'gdb', about which I know very little!
I've been waiting for an opportunity like this.... ;-)
Adrian: I see that you've looked at the code and have some ideas about
what is going wrong and how to triage and instrument the crash. I
really intended to look seriously at the code tonight, but when 1.3.5
actually worked... I just ended up playing with it, trying to figure out
how to get my guitar pedal to output a stronger signal level so that my
EMU 0404 card's inputs could deliver a decent sound level to 'audacity'.
(I figured it out, BTW, but it wasn't obvious....)
Your suggestions look very interesting, and I hope to try some (or all)
of them out tomorrow night after work. I agree that we are probably
getting more negative return values in nearby code, where it was assumed
there would be no errors. I have some ideas of my own in addition to
yours, but I would like to look more carefully at the code first to try
to get a handle on what it is _supposed_ to be doing. My guess last
night (having barely looked at the code) was that they were trying to
put together a list of capture devices -- something like what 'aplay -l'
or 'aplay -L' would show -- but that they wrote fragile code which works
on most machines but chokes on my EMU 0404 card.
Thanks, and more to come...
pkg-multimedia-maintainers mailing list