Additional (believed current) issues:

* Re-routing the Portaudio ins/outs can only be done when Audacity is paused 

* Clicking in the input meter to start monitoring will crash Audacity if it hasn't previously recorded from JACK in that session  

Two backtraces for the monitoring crash follow (using jackd 1.9.3 or 1.9.5). User who submitted these also says "When I run with a debugger, and break at  PaUtil_EndBufferProcessing, the bug does not occur." 

On Ubuntu 9.04 using PA 19+svn20100810:
 
 (gdb) bt
 #0  0x08364d77 in Meter::IsMeterDisabled (this=0xac74600) at widgets/Meter.cpp:1135
 #1  0x084af120 in NonAdaptingProcess (bp=0x0, streamCallbackResult=0xac73834, hostInputChannels=0xac51310,
      hostOutputChannels=0x0, framesToProcess=512) at src/common/pa_process.c:822
 #2  0x084b00a0 in PaUtil_EndBufferProcessing (bp=0xac73738, streamCallbackResult=0xac73834) at src/common/pa_process.c:1526
 #3  0x084a7825 in JackCallback (frames=512, userData=0xa769590) at src/hostapi/jack/pa_jack.c:1403
 #4  0xb66e42c1 in ?? () from /usr/lib/libjack.so.0
 #5  0xb66fa418 in ?? () from /usr/lib/libjack.so.0
 #6  0xb66964ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
 #7  0xb651249e in clone () from /lib/tls/i686/cmov/libc.so.6
 (gdb)
 
On Ubuntu 9.10 using PA 19+svn20090620-0ubuntu1:

 (gdb) bt
 #0  0x0835ba57 in Meter::IsMeterDisabled (this=0x8d2d6c8) at widgets/Meter.cpp:1135
 #1  0x084927dd in NonAdaptingProcess (bp=0xb2e45010, streamCallbackResult=<value optimized out>,
      hostInputChannels=0x8d1cba8, hostOutputChannels=0x0, framesToProcess=4096) at src/common/pa_process.c:822
 #2  0x08493760 in PaUtil_EndBufferProcessing (bp=0x8d2c338, streamCallbackResult=0x8d2c434)
      at src/common/pa_process.c:1526
 #3  0x0848b0b8 in RealProcess (frames=4096, userData=0x8936560) at src/hostapi/jack/pa_jack.c:1403
 #4  JackCallback (frames=4096, userData=0x8936560) at src/hostapi/jack/pa_jack.c:1544
 #5  0x011b1afd in ?? () from /usr/lib/libjack.so.0
 #6  0x011cc1f5 in ?? () from /usr/lib/libjack.so.0
 #7  0x0121c80e in start_thread (arg=0xb2e46b70) at pthread_create.c:300
 #8  0x0140ca0e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
 (gdb)

Do we still have the issues stated in comment #0?

* JACK has to be shut down before starting Audacity

* Recording dropouts - these are grouped together with similar Mac problems
as a P4 issue, but they might not be related

* Crashes when recording full duplex?

A user writing to feedback@ suggests that in 1.3.12 there are sometimes crashes when using the Stop button after record, in the case where other applications besides Audacity are connected to JACK. Don't have more detail than that at the moment.

(In reply to comment #3)
Running Audacity 1.3.13 with Jack in Ubuntu 10.04/10.10 is much improved though some issues still exist.

The following steps 'should' enable Audacity to run well with Jack, however this is not safe against user error. Setting up Audacity incorrectly to use Jack can still cause Audacity to crash.

Before starting Audacity, Jack must be running and must be stable - for trouble free running the latency should be high enough to safely avoid xruns.

Open Audacity and in Preferences > Devices set the Host to Jack and the Recording/Playback devices to 'system'. 

* For some reason the number of channels defaults to '1 (mono)' but this may be specific to this computer set-up.

* The default sample rate in Audacity should be set the same as jack otherwise Audacity may crash during record. If the default sample rate in Audacity is changed, Audacity should be restarted or it will probably not connect correctly and may crash.

When Recording or Playback are selected, Audacity automatically connects to the system input/output sockets.


When NOT using jack patchbay:

If connection to other sockets are required, (for example connecting the output from Audacity to Jack Rack) the other jack enabled application must be started before launching Audacity if their sockets are to be visible in Audacity. Assuming that the other applications have been started before launching Audacity, the input/output sockets of these applications may be selected in the Devices Preferences or with the 'Device Toolbar'.


When using jack patchbay:

As the PA sockets are non-persistent, to use the Jack Patchbay, the PA sockets must be defined using regex.

For the input sockets:
^in_\d*[02468]$
^in_\d*[13579]$

For the output sockets:
^out_\d*[02468]$
^out_\d*[13579]$

Both input and output sockets would normally be set up for Exclusive access so as to avoid duplicate connections.

Audacity must be restarted after adding and applying new sockets to the patchbay settings or it will probably crash. Once this has been set up, routing may be configured for any of the defined sockets using the patchbay. It would often be useful to configure a patchbay profile for recording and another patchbay profile for playback.

The patchbay is only required for convenient patching to ports other than the system ports.

When using the patchbay, it is not necessary to start Audacity last. If the ports of another application are defined in the patchbay profile then the patchbay settings can be used even if Audacity is not aware of the other application.


There is still a degree of instability when using the rt-kernel, but I suspect that this is more to do with the rt-kernel (which is currently a bit behind the generic kernel) than with Audacity.

The remaining issues are primarily that Audacity is not robust against incorrect set-ups.

(In reply to comment #4)
Thanks, Steve. I've in fact saved most of your tips for using JACK which I've pulled from your Forum posts. I lack the time right now to do it but I think the existing Wiki section
http://wiki.audacityteam.org/wiki/Linux_Issues#JACK

should be updated for current understanding of user-facing JACK issues and tips like yours on "how to run Audacity with JACK". Perhaps it even warrants a separate page now. 

You've highlighted some general instabilities in Comment 4 but they aren't easy to pick out from the "tips". Perhaps you could summarise these in a new comment? Also I'm not clear if the issues in Comment 2 are still valid - can you confirm and also include any still valid ones in a new comment?   

* JACK has to be shut down before starting Audacity (this seems to be invalidated by your saying that JACK must be running before starting Audacity - does anything bad happen if you start JACK after starting Audacity?)  

* Recording dropouts - these are grouped together with similar Mac problems
as a P4 issue, but they might not be related

* Crashes when recording full duplex?

Is it a "bug" (something we should address) that JACK should be running before starting Audacity, or is it expected with JACK or when adding another host like ASIO ? If it's not expected, is that another variant of Bug 41?

(In reply to comment #5)
The current instabilities appear to be related to changing the way that Audacity connects. 

For example, if the default sample rate in Audacity is changed, then this affects Audacity's connection when recording - consequently it is likely to crash on Record.

Another example is if an active jack patchbay is edited while Audacity is running, then Audacity becomes unstable. This problem does not seem to occur when changing from one patchbay profile to another (presumably because the patchbay is safely disconnected when changing to a new profile) but does occur if sockets in the current profile are edited.

To avoid such problems in such situations, Audacity should be restarted.


The other thing that can cause instability is if a feedback loop is inadvertently created, though this seems to be a fairly common problem that is not limited to Audacity.

Jack does not need to be shut down before starting Audacity.
If Jack is not running when Audacity is started there is no option to select Jack as the host.

It is normal that Jack needs to be running when starting a Jack aware application.


The problem with 'crashing when enabling the record meter before recording' still applies to Audacity 1.3.12 but has improved in 1.3.13.
If there is an active patchbay profile to connect Audacity, then the issue (with 1.3.13) does not occur, provided that Audacity has used the connection within the current jack session. In other cases the problem still exists.


I've not noticed any real problems with dropouts.

There may still be a problem recording "full duplex" but I'm still testing that.

(In reply to comment #6)
I'm not seeing problems with recording full duplex.

(In reply to comment #7)
Most of the issues with Jack appear to be resolved. The remaining issues are:

* Clicking in the input meter to start monitoring will crash Audacity if it
hasn't previously recorded or played with JACK in that session. 
(Workaround: Before recording the first track in a session, click "Pause" then "Record" to enable the recording meter.)


New issues are:

* Audacity does not respond to Jack Patchbay. However, connections to available inputs/outputs can now be made through the Device Toolbar.

* Switching from ALSA to Jack can be very slow and Audacity may appear to freeze.

* Switching from Jack to ALSA if there are no available devices can cause Audacity to freeze. (user error?)

* Steve also noted on the Wiki http://wiki.audacityteam.org/wiki/Linux_Issues#JACK and others have reported that launching Audacity for the first time when JACK is running may be very slow. Restart seems to cure this. 

* Also when opening jackd and Audacity, the Audacity connections in qjackctl are only available while playback or recording are in progress. This is included in the Release Notes for information, but is it correct that this is a JACK problem that affects other apps too?

There seems possibly a couple of sluggishness issues. A couple of people report
general, persistent sluggishness the first time Audacity detects JACK, but not on restart, even if the host is still ALSA. Steve finds that the hang is when JACK is not the current host and devices are queried.

Steve finds that the only major issue remaining is that enabling the recording meter before any recording or playback has occurred will usually crash Audacity.

On Mac, there is a report that 1.3.13 freezes if JACK is launched by QjackCtl 
then Audacity is launched. Not a problem if JACK is launched by JackPilot or if QJackCtl is launched after Audacity and JACK are running. All other applications work OK with QjackCtl. Audacity seems to make excessive connection and disconnection requests which show in QJackCtl's connection panel and the terminal logging of Audacity e.g 83000 lines output for 1.3.13 against 1800 lines for Ardour which does "ActivateClient" just once. See:
http://audacity.238276.n2.nabble.com/3-13beta-and-QjackCtl-problem-td6629391.html

Comments received on feedback@ added here for completeness:
> Based on my observations, the problem is due to the basic data structure 
> owned by AudioIO not having been instantiated yet under the above 
> circumstances and so we end up with a reference through a pointer that 
> is still NULL. I have looked at the sources, but since I don't know the
> underlying conventions, I don't know where the above instatiation should
> be coming from, or if we are talking audacity or jackd, but clearly the
> user shouldn't be able to cause a crash.
> 
> Here is the traceback without the debuginfo installed:
> #0  0x08306207 in Meter::IsMeterDisabled() ()
> #1  0x08126c57 in audacityAudioCallback(void const*, void*, 
> unsigned long, PaStreamCallbackTimeInfo const*, unsigned long, void*) ()
> #2  0x0840d39d in ?? ()
> #3  0x0840e43d in PaUtil_EndBufferProcessing ()
> #4  0x08405c48 in ?? ()
> #5  0x00c9a98e in ?? () from /usr/lib/libjack.so.0
> #6  0x00c9f612 in ?? () from /usr/lib/libjack.so.0
> #7  0x008159e9 in start_thread () from /lib/libpthread.so.0
> #8  0x00757f3e in clone () from /lib/libc.so.6
> 
> Here are the particulars of my configuration:
>     kernel:   kernel-2.6.32-71.29.1.el6.i686 from Centos
>     audacity: audacity-1.3.12-0.6.beta.el6.i686 from epel
>     jackd:    jack-audio-connection-kit-0.118.0-1.el6.i686 from epel
> I also have installed the following due to requirements by other programs,
> but don't believe that it is being used in this case:
>     pulseaudio:pulseaudio-libs-0.9.21-13.el6.i686 from Centos

(In reply to comment #12)
> Here is the traceback this time with debug info:
> kernel:   kernel-2.6.32-71.29.1.el6.i686 from Centos
> audacity: audacity-1.3.12-0.6.beta.el6.i686 from epel
> jackd:    jack-audio-connection-kit-0.118.0-1.el6.i686 from epel
> pulseaudio:pulseaudio-libs-0.9.21-13.el6.i686 from Centos

#0  0x08306207 in Meter::IsMeterDisabled (this=0x23) at widgets/Meter.cpp:1135
#1  0x08126c57 in audacityAudioCallback (inputBuffer=0x8eeb5c8, outputBuffer=
    0x8eed5d0, framesPerBuffer=1024, timeInfo=0xb695d138, statusFlags=0, 
    userData=0x0) at AudioIO.cpp:2977
#2  0x0840d39d in NonAdaptingProcess (bp=0x8e915b0, streamCallbackResult=
    0x8e916ac, hostInputChannels=0x8e917d8, hostOutputChannels=0x8da9cb0, 
    framesToProcess=1024) at src/common/pa_process.c:822
#3  0x0840e43d in PaUtil_EndBufferProcessing (bp=0x8e915b0, streamCallbackResult=
    0x8e916ac) at src/common/pa_process.c:1505
#4  0x08405c48 in RealProcess (frames=1024, userData=0x8c34aa0)
    at src/hostapi/jack/pa_jack.c:1403
#5  JackCallback (frames=1024, userData=0x8c34aa0)
    at src/hostapi/jack/pa_jack.c:1544
#6  0x00c9a98e in ?? () from /usr/lib/libjack.so.0
#7  0x00c9f612 in ?? () from /usr/lib/libjack.so.0
#8  0x008159e9 in start_thread () from /lib/libpthread.so.0
#9  0x00757f3e in clone () from /lib/libc.so.6

On Linux I am no longer getting the crash when clicking on the recording meter. I'm unsure what or when this was fixed, but I've not seen this problem for quite a while.

I think that just leaves the issue of ports disappearing when audio I/O is stopped.

(In reply to Steve Daulton from comment #14)
Scratch that. The problem does still occur but I unknowingly discovered another workaround.

If Audacity is launched with ALSA host and then the host is changed to Jack, the crash does not occur. However, if Jack is already selected as host, then the crash 'may' still occur but is less repeatable than previously.

I am trying out Jack on Mac and I find assertion violations with stacks like these when Jack is chosen in device toolbar for input and out, and I simple mouse-over the track control panel (I think it's the Gain slider in particular).

I think I can fix this.  If I do, can the various other points in this bug be reexained for marking as resolved?

#0	0x9240ff96 in __kill ()
#1	0x9240d678 in kill$UNIX2003 ()
#2	0x93fe7cf4 in raise ()
#3	0x0272d31a in wxTrap() ()
#4	0x0272fe40 in wxDefaultAssertHandler(wxString const&, int, wxString const&, wxString const&, wxString const&) ()
#5	0x0272de07 in wxOnAssert(char const*, int, char const*, char const*, char const*) ()
#6	0x0280d4cd in wxFormatString::ArgumentType (anonymous namespace)::DoGetArgumentType<wchar_t>(wchar_t const*, unsigned int) ()
#7	0x0280ce65 in wxFormatString::GetArgumentType(unsigned int) const ()
#8	0x00181dfe in wxArgNormalizer<float>::wxArgNormalizer(float, wxFormatString const*, unsigned int) at /usr/local/include/wx-3.0-debug/wx/strvararg.h:451
#9	0x00181d96 in wxArgNormalizerWchar<float>::wxArgNormalizerWchar(float, wxFormatString const*, unsigned int) at /usr/local/include/wx-3.0-debug/wx/strvararg.h:471
#10	0x00181d26 in wxArgNormalizerWchar<float>::wxArgNormalizerWchar(float, wxFormatString const*, unsigned int) at /usr/local/include/wx-3.0-debug/wx/strvararg.h:471
#11	0x0032719a in int wxString::Printf<float>(wxFormatString const&, float) at /usr/local/include/wx-3.0-debug/wx/string.h:2302
#12	0x003248e2 in LWSlider::GetTip(float) const at /Users/paullicameli/GitHub/audacity/src/widgets/ASlider.cpp:1052
#13	0x00324dd4 in LWSlider::OnMouseEvent(wxMouseEvent&) at /Users/paullicameli/GitHub/audacity/src/widgets/ASlider.cpp:1147
#14	0x0032648e in ASlider::OnMouseEvent(wxMouseEvent&) at /Users/paullicameli/GitHub/audacity/src/widgets/ASlider.cpp:1684

Actually the problem was mousing over the Mixer toolbar, and a fix is here.
This caused assertion violations in Mac but only in the debug build.  But maybe
the same caused crashes in the Linux build.

dc0bbf96d37c310c24906049de960dada6e0fd30

Paul's fix from last year needs testing on Linux

This summary bug is still open, even if the fix in comment 17 has helped.
REOPENED

Re-Rated P3.

Residuals made into new bugs, bug 1974 and bug 1975.