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.

pkg-multimedia-maintainers mailing list

Reply via email to