Audacity application abnormally quits when:
This occurs both on:
PowerMacG5 Quad, MacOS 10.4.11, Audacity 2.0.0
MacPro 2010 Quad core, MacOS 10.6.8, Audacity 2.0.3.
It seems like that Audacity abnormally quits when clock toggles on/off while recording.
Is there any workaround ?
I doubt it. S/PDIF is a very close cousin to the AES-EBU broadcast bitstream and you can’t interrupt one of those at all without very serious resyncing and possible show damage.
Audacity application abnormally quits
I think it normally quits.
Someone will correct me.
Koz
Thank you for your reply.
In the above condition, when I powered On/Off the connected playback device, or plugged In/Out the S/PDIF cable, Audacity quits with unexpected quit dialog, with all sound files opening at that time also forced to be closed. I can see the recovery selection dialog on the next startup of the Audacity.
Additionally I found that my MacMini is OK on the same case.
MacMini 2010, MacOS 10.7.5, Audacity 2.0.0, with built-in S/PDIF:
Audacity simply record silence while S/PDIF cable is plugged out, and continue recording when after plugged in.
Following is a part of the error information.
=======
Process: Audacity [47421]
Path: /Applications/Audacity/Audacity.app/Contents/MacOS/Audacity
Identifier: net.sourceforge.audacity
Version: 2.0.3.0 (2.0.3.0)
Code Type: X86 (Native)
Parent Process: sh [47418]
Date/Time: 2013-08-18 09:49:50.413 +0900
OS Version: Mac OS X 10.6.8 (10K549)
Report Version: 6
Interval Since Last Report: 2432877 sec
Crashes Since Last Report: 6
Per-App Interval Since Last Report: 2234301 sec
Per-App Crashes Since Last Report: 3
Anonymous UUID: 8FC8A005-3C22-4601-9792-EE4CEE889DCC
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread: 5
Application Specific Information:
abort() called
....
....
Thread 5 Crashed:
0 libSystem.B.dylib 0x91e940ee __semwait_signal_nocancel + 10
1 libSystem.B.dylib 0x91e93fd2 nanosleep$NOCANCEL$UNIX2003 + 166
2 libSystem.B.dylib 0x91f0efb2 usleep$NOCANCEL$UNIX2003 + 61
3 libSystem.B.dylib 0x91f306f0 abort + 105
4 Audacity 0x0080e29d __eprintf + 77
5 Audacity 0x007c5a63 AudioIOProc + 3811
6 ...pple.audio.units.Components 0x7000c2dc AUGenericOutputEntry + 8443
7 com.apple.audio.CoreAudio 0x99092028 HP_IOProc::Call(AudioTimeStamp const&, AudioTimeStamp const&, AudioBufferList const*, AudioTimeStamp const&, AudioBufferList*) + 374
8 com.apple.audio.CoreAudio 0x99091d8e IOA_Device::CallIOProcs(AudioTimeStamp const&, AudioTimeStamp const&, AudioTimeStamp const&) + 370
9 com.apple.audio.CoreAudio 0x99091b7e HP_IOThread::PerformIO(AudioTimeStamp const&, double) + 620
10 com.apple.audio.CoreAudio 0x9908ef40 HP_IOThread::WorkLoop() + 2506
11 com.apple.audio.CoreAudio 0x9908e571 HP_IOThread::ThreadEntry(HP_IOThread*) + 17
12 com.apple.audio.CoreAudio 0x9908e488 CAPThread::Entry(CAPThread*) + 140
13 libSystem.B.dylib 0x91e54259 _pthread_start + 345
14 libSystem.B.dylib 0x91e540de thread_start + 34
....
I know this is going to be no help, but I think the Mini is the error. One sure way to dig a hole with Audacity’s face is to unplug the USB or Firewire cable when Audacity is standing on it.
Audacity is a complete slave to the computer that’s running it. It will try to lock to what ever comes down the line. If zero comes down the line, that’s the end of the rodeo and the horses can go home.
It’s possible that the Mini goes into self-sync at the disruption of the bitstream and the other two don’t. That’s a research trip about how they did the hardware in the different machines. That has little or nothing to do with Audacity.
I’m still waiting for one of the other elves to appear and argue with me, but I think what you have is perfectly normal – except for the Mini.
Koz
I have a mental picture of Mr Audacity standing on a rug with “S/PDIF” written on it, and someone giving the rug a sharp tug. Mr Audacity falls over.
The flippant answer is: don’t pull the rug from under Audacity 
Audacity is not able to sync to devices on the fly. When you start Audacity, it probes the computer sound system and looks for audio devices that appear to be working. Those devices are listed in the device toolbar and may be selected as recording/playback devices.
Probing the sound system to find audio devices is relatively slow, so Audacity does not do this again unless either, you restart Audacity, or you specifically tell Audacity to rescan the audio devices.
To rescan audio devices, ensure that playback is stopped (not just paused) and select “Rescan Audio Devices” from the Transport menu.
Save the Audacity project before you do this. Rescanning may not always be 100% stable because it may cause the computer sound system to reconfigure itself at the same time that Audacity is trying to configure itself. I’ve only seen this problem on Linux - I don’t know if it applies to other platforms, so save your project just in case. It would be interesting/useful if you could tell us if this works reliably on your Mac.
The safest way to change the available audio devices is to save your current project, then close Audacity, then change the devices and wait a few moments for the computer sound system to sort itself out, then restart Audacity. Audacity should then be able to correctly identify the new configuration.
have a mental picture…
Painting with words.
Jackson Pollock is not a good role model.
Koz
Rescan doesn’t crash on my Windows machines, or Mac Mini, or Ubuntu 13.04.
I’ve heard of disconnecting and reconnecting devices on Mac while stopped causing a crash but it does not create a crash on my Mac mini (or Windows). On those machines I can record from a USB device, stop, unplug the device, reconnect it, then record from the USB device. If I did not reconnect I would get error opening sound device.
On Windows I would usually get a freeze if I pulled out the USB cable while recording. I might be able to get control back by pressing Stop, but not always.
Gale
Have you tried running Audacity on Linux with Jack, then shutting down Jack, then rescanning?
No. Do I assume that crashes for you?
I don’t have JACK in Ubuntu 13.04.
In Ubuntu 12.04 I somehow acquired JACK without installing it, I think after installing an optional pulseaudio component. I don’t understand it but there were many audio weirdnesses on my copy of 12.04.
When you search for “jack” in “Ubuntu Software Centre” on 13.04, Ubuntu hide it behind “80 technical items” then there are numerous JACK choices which don’t seem to be the complete program so I would be surprised if many Ubuntu newbies have it. Synaptic is barely any easier to see what JACK components you would be supposed to install.
An offered program called “Jack” is nothing to do with JACK audio connection kit.
Are there any explanations somewhere of how exactly you install JACK on Linux? On my review I would say don’t bother, install Ubuntu Studio instead which includes JACK 
Gale
Yes.
I’m not really surprised that it does. Not only do we have the unresolved issues in bug 56, but the sound system is doing some spectacular gymnastics when the Jack server is switched off. Normally, if using Jack, you would start it at the start of the session (or earlier) and it would be running until the end of the session, log out or shut down.
For Ubuntu, the easiest way is, as you say, install Ubuntu Studio.
The easiest way to install Jack on Debian is to install qjackctl. This small utility is a QT interface for configuring and starting the Jack server. The dependencies for qjackctl should install all of the essential components. Additional components are required for advanced configurations (such as recording from multiple sound cards, streaming across a network or integrating with applications that are not jack-aware), but just installing qjackctl should be enough for a working jack system. Configuring Jack to run reliably may require tweaking, depending on the system hardware, especially if you need low latency (same for ASIO on Windows). There are alternatives to qjackctl, but this is the most popular GUI application for controlling the Jack server.
Yes, that’s unfortunate - someone did not protect their trademark very well.