Bugzilla Bug 209494

audacity-1.3.4 (and audacity-1.3.4-r1) includes a buggy portaudio-v19 snapshot
for audio recording/playback. As a result, starting audacity or opening the
preferences dialog takes a minute due to timeouts, all attempts at playback or
recording to alsa devices fail, and the application prints a constant stream of
error messages:

configuring for 44100Hz, period = 1024 frames (23.2 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 16bit little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit little-endian
ALSA: use 2 periods for playback
Expression 'ret' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1034
Expression 'AlsaOpen( hostApi, parameters, streamDir, &pcm )' failed in
'src/hostapi/alsa/pa_linux_alsa.c', line: 1066
Expression 'ret' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1034
Expression 'AlsaOpen( hostApi, parameters, streamDir, &pcm )' failed in
'src/hostapi/alsa/pa_linux_alsa.c', line: 1066
Expression 'ret' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1034
Expression 'AlsaOpen( hostApi, parameters, streamDir, &pcm )' failed in
'src/hostapi/alsa/pa_linux_alsa.c', line: 1066
Expression 'ret' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1034
Expression 'AlsaOpen( hostApi, parameters, streamDir, &pcm )' failed in
'src/hostapi/alsa/pa_linux_alsa.c', line: 1066

etc. See the Debian bug (in the URL field) for more gory details.

The solution is to update audacity's internal portaudio snapshot to 2007-12-07
or later, which is known to fix the alsa and jack bugs. This has already be
done by audacity upstream:

http://audacityteam.org/wiki/index.php?title=Audacity_PortAudio_v19

Created an attachment (id=143093) [details]
Ebuild with newer portaudio snapshot

To fix the bug, here's an ebuild that uses the 20071207 portaudio-v19 snapshot.

Created an attachment (id=143095) [details]
portaudio-cvs-rev1.7.patch (for above ebuild)

Patch from audacity CVS, modifications to portaudio-v19 required for audacity
to compile. Used by the above ebuild.

Erm... This should use system portaudio libs, not any bundled nonsense. Until
portaudio-19 gets unmasked, the functionality should be just hard disabled.

(In reply to comment #3)
> Erm... This should use system portaudio libs, not any bundled nonsense. Until
> portaudio-19 gets unmasked, the functionality should be just hard disabled.

1. Audacity-1.3 has ZERO functionality without portaudio (because it uses
portaudio for all sound I/O).
2. Audacity-1.3 cannot use external portaudio-18, because -18 and -19 have
different APIs and feature sets.
3. (this is the fun part) Audacity-1.3 CANNOT use an external portaudio-19
either! This is because it actually uses a custom-patched CVS snapshot of
portaudio-19, and those patches have apparently not been taken by portaudio
upstream.

So in this case, I recommend doing what Audacity upstream recommends, and using
their bundled patched internal portaudio snapshot.

(In reply to comment #4)
> Audacity-1.3 CANNOT use an external portaudio-19
> either! This is because it actually uses a custom-patched CVS snapshot of
> portaudio-19, and those patches have apparently not been taken by portaudio
> upstream.

Yeah, this is just wonderful strategy. Shipping (broken as a bonus)
custom-patched bundled libs is definitely the way to go... should be employed
more widely for complete PITA maintainer experience. In a similar way, this
also bundles its own allegro and links it in statically so that in case of
vulnerability users can enjoy that permanently.

(In reply to comment #2)
> Created an attachment (id=143095) [edit] [details]
> portaudio-cvs-rev1.7.patch (for above ebuild)
> 
> Patch from audacity CVS, modifications to portaudio-v19 required for audacity
> to compile. Used by the above ebuild.
> 

hmm the patch doesn't apply here against 1.3.4 :(

(In reply to comment #6)
> hmm the patch doesn't apply here against 1.3.4 :(

Of course not. Look at what the attached ebuild does. The patch is not applied
to audacity-1.3.4; instead it is applied to the portaudio v19_20071207 snapshot
(which the ebuild uses to replace audacity-1.3.4's broken portaudio snapshot)

(In reply to comment #7)
> (In reply to comment #6)
> > hmm the patch doesn't apply here against 1.3.4 :(
> 
> Of course not. Look at what the attached ebuild does. The patch is not applied
> to audacity-1.3.4; instead it is applied to the portaudio v19_20071207 snapshot
> (which the ebuild uses to replace audacity-1.3.4's broken portaudio snapshot)
> 

ha ! I didnt see that, thanks ! Indeed, it seems to improve alsa playback
(which happened to not work at all recently here while it used to work if using
a specific frequency rate iirc).

Any reason to use pa_stable from dec. 2007 while audacity cvs uses one from
jan. 2008 ?

(In reply to comment #8)
> Any reason to use pa_stable from dec. 2007 while audacity cvs uses one from
> jan. 2008 ?

No reason, it's just that while googling for how to fix the bug, I've read many
reports that Dec. 2007 portaudio snapshots are known to work well, and I know
that audacity used to have the 20071207 snapshot in their CVS version (although
I guess they have upgraded to a newer snapshot by now).

updated in r2, thanks a lot !

If audacity 1.3.4-r1 is known to not work because of this issue, should it be
(hard)masked?  It still shows as stable.