Bug#584605: audacity: Continuing to backtrace

[Dave Witbrodt]

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' 
build-dependency.

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 
were needed!

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...
Dave W.