Pleasant Software Blog | Support  

Launch issue with Übercaster on Lion

(… and Snow Leopard)

I received several reports from users, that Übercaster v1.6.6 still doesn’t launch on Lion: Übercaster’s icon bounces in the dock for a (long) while, but that’s it.

This issue seems to affect about 10% of the Lion users, but I even received reports from a few users still running Snow Leopard. Unfortunately, I wasn’t able to reproduce this issue on my computer (or any Mac I have direct access to).

Anyway, I tried for the last 4 weeks to get a fix on this issue. I built special versions of Übercaster, logging trace messages during launching (without any results, Übercaster’s code never got called), collected (and analyzed) information on the affected computers and OS installations, checked linked frameworks, permissions, and so on.

Eventually I contacted Apple’s Developer Technical Support with this issue, providing all information I gathered so far. About a week later I received a response from Apple. And here’s the central paragraph from this response:

… this is a bug in the system software.  AFAICT your code is not doing anything wrong.  I’m going to discuss this with the dyld and Objective-C runtime engineers to see what we should do about this. [...] It seems that this is a known issue.

So, here it is: It’s a bug in Mac OS X 10.6.8 and 10.7. When loading linked frameworks during the launch of Übercaster, the launch deamon seems to get caught in some kind of dead lock, waiting on it self.

Apple seems to have a fix for this for 64bit applications. Unfortunately Übercaster is still 32-bit, since it makes heavy use of Quicktime APIs (which weren’t (and I’m afraid, never will be) ported to 64-bit).

However, the friendly and helpful Apple engineer also mentioned a possible work around for this issue which should work with 32-bit apps. This work around involves some code changes in Übercaster.

I implemented the necessary changes in a new beta of Übercaster (v1.6.6 beta8). I’m still not able to reproduce the issue on my computer, but first tests on the computers of a few users, affected by this issue, look promissing.

Please give the new beta a try:

Übercaster v1.6.6 beta 8

This beta also fixes an issue with the “Save as” menu command (it should now work again).

Übercaster v1.6.6beta4 for Mac OS X 10.7

Übercaster v1.6.6beta4 is now available for download:

→ Übercaster v1.6.6beta4

Please note, that Übercaster v1.6.6 requires a Macs running Mac OS X 10.6.8 (Snow Leopard) or Mac OS X 10.7 (Lion)!

A known issue when running on Mac OS X 10.7 (GM, 11A511) is that edit windows for effect filters are viewing only the generic interface and not the custom Cocoa interface of the AUs. The reason for this is an (undocumented) change of behavior in Apple’s APIs.  This is very likely a bug in Mac OS X 10.7 and I hope, Apple will fix it soon. I already wrote a bug report on this issue at Apple. I also had to (temporarily) switch off support for PleasantConnect in this build.


A quick word on the state of Übercaster

I’m still working with Apple’s developer support on a solution of the current stability problems of Übercaster on Snow Leopard. After incorporating some code changes, I sent several beta builds to users for testing. Unfortunately, the results weren’t good (in some cases, the “fixed” code was even more unstable).
The main problem is still, that I’m not able to reproduce the problems on my computers. All I have to work with are the (crash) reports from users. The last response from Apple’s support was a request for sample code, reproducing the crashes. Of course, I already sent in source code pieces I was able to pin point by analyzing e crash reports. But since I’m not able to reproduce the crashes it’s more or less impossible to write a “working” crash sample.
Right now, I try to organize a meeting with the support engineer from Apple at WWDC in San Francisco next week. Maybe we can find the problem together…

Übercaster v1.6.5 beta2

Here’s another beta release of Übercaster v1.6.5:

This beta should fix all remaining issues, causing Übercaster to crash during playback under some circumstances. It also fixes a bug causing the released audio file to contain gaps of silence.

First results from a few testers look promising. Please give the new beta a try.

In case this version crashes on you, please be sure to include your email address in the crash reports (as always). It’s the only way I can assign the crash reports to known issues/tickets.

Übercaster v1.6.5 beta1

Today, we release “beta 1″ of Übercaster v1.6.5.

This version should take care of some of the crashing issues in Übercaster on Mac OS X 10.6 (Snow Leopard). It should also solve (crashing) issues in connection with Skype recordings.

In addition to that, this version contains a solution for an issue with Skype, where Skype recordings could run out of sync, causing buffer overflows. The main problem is, that Skype (as a completely independent process on the computer) might deliver audio data slightly out of sync to Übercaster’s internal CoreAudio engine. Übercaster tried to be prepared for that with relatively large ring buffers for Skype panels, but unfortunately this wasn’t enough when it came to recording Skype interviews longer than 20-30 minutes. Depending on a lot factors (inside and outside of Übercaster), even a slight (but constant) asynchronism could lead to several issues, including complete breakdown of the panels input signal.

In v1.6.5 beta 1, I try to avoid these problems by a new (experimental) approach in trying to figure out the current buffer states and by resetting the internal buffers if necessary (and before anything bad happens).

I received a lot reports on 2 other crashing bugs lately. Both bugs drove me almost crazy and forced me into some very frustrating bug hunting.

Eventually, after checking (and checking again) Übercaster’s source code without finding anything, I contacted Apple’s Developer Technical Support (DTS) with both issues.

Here’s an excerpt from the response to this DTS request:

There was a related bug that [AudioToolbox] MP4AudioFile::Close crashes writing large files, but it was fixed already since Mac OS X 10.6.3. Please ensure to upgrade to the latest Mac OS X.

The MP4AudioFile::FillGaplessString issue was the problem which caused crashes during AAC export (and probably other “large file” exports).

I double-checked the crash reports and they were indeed all sent from Macs running Mac OS 10.6.1 or 10.6.2.

So, if you’re working with Snow Leopard, please update your Mac to Mac OS X 10.6.3 (or newer)!

The other issue (which also came up with the Mac OS X 10.6.1 update) erratically occurs when playing back audio on the cut layer. Since I couldn’t find any bug in the source code, I also sent a DTS request to Apple on this one.

Apple already confirmed, that the crash is caused by a new function inside CoreAudio, they introduced (undocumented) in Mac OS 10.6. Unfortunately, after checking all possible reasons, Apple mentioned to be a possible reason for  causing  this new function to crash Übercaster, it’s still unclear what causes the crashes. Right now it doesn’t look like Übercaster is doing something wrong here. So this one is still pending.

Of course, I’ll let you know if  I (or Apple) find a solution for the issue!

Download Übercaster v1.6.5 beta 1 here.

The downloaded ZIP-archive contains only the application itself. It’s no problem to keep  your current version of Übercaster. Just be sure to launch the correct version (which is easy, when launching Übercaster by double-clicking on the application icon, but might be not that easy when launching Übercaster by double-clicking an Übercaster project file). If in doubt, just check the version number in Übercaster’s about dialog.

Shocking news

After stealing Delicous Library’s bookshelf design for iBooks, Apple now steals Birdie’s very unique counter view background for iPhone OS 4.0′s folder design!!

Here’s the proof:

Just kidding…

New web server

The website of Pleasant Software (and some of the server-side applications), for historical reasons, were distributed over 3 different web servers lately.  In addition to that, our main server strongly needed an OS update, which wasn’t possible without completely shutting down the server and install from scratch.

Last week, we finally took the chance to clean up the whole server setup: in the night from Wednesday  to Thursday, after a day of backing up all websites and databases, we shut down the main server, erased the hard disk and installed the long overdue OS upgrade.

About 10hrs later, the server was up again and all seems to work. So we started to relocate content, formerly hosted on other servers, to the main server (e.g. used to be hosted on a separate server).

If you run into problems on our website (broken links, missing images, dysfunctional  scripts etc.), please let us know. Thank you!

The principle of cause and effect

lynch mobOf course, I know that it’s extremely frustrating when an application crashes on you.

That’s why I tried to minimize the harm, done by a crash, in Übercaster as much as possible. Übercaster has a built-in autosave feature and it even recovers partial audio recordings after the application or the whole computer crashed. All editing is done in a non-destructive way (i.e. not changing the original audio).

As long as the computer didn’t explode, the hard disk didn’t melt and the project file is still there, Übercaster should be able to recover the project on the next launch and recover all audio recordings, even if it crashed in the middle of a recording session.

This doesn’t mean that Übercaster constantly crashes, is supposed to crash or that I tolerate crashing bugs! Not at all.

The thing is, that there’re a lot of wheels turning in Übercaster. And a lot of these wheels aren’t even part of Übercaster itself.

There’s a lot of external hardware involved: Microphones, Mixers, Audio In/Out boxes, you name it. Some of these come with their own drivers or firmeware. They can be unplugged (or plugged in) while Übercaster’s running or even during recording.

Then there are 3rd party products like Skype (connected via the Skype API framework), iChat or other applications, providing audio (or sometimes not providing it).

And of course there are 3rd party audio units, small (or not so small) audio plugins, running inside the host application (i.e. Übercaster) and processing audio. Or sometimes crashing…

In case of a crash, from the user’s point of view, Übercaster just crashes. The next thing they see is probably the Crash Reporter dialog from Apple, pointing it’s bony finger at Übercaster.

What the normal user doesn’t know: The crash reporter doesn’t really know what happened, or better: it doesn’t care. All it knows is that Übercaster was running and then something bad happend, resulting in Übercaster’s sudden death.

Sidenote: Unfortunately, Apple’s crash reporter doesn’t provide any way to send its reports to 3rd party developers. Thus, Übercaster contains its own crash reporter, which sends crash reports to our servers. Crash reports can help to fix bugs, but most of the time we need more information than just one single crash report. Therefor the Übercaster crash reporter contains a text field for comments. These comments are supposed to provide additional information on what happened before the crash or ideally a way to reproduce the problem.

The crash reporters comment field is not supposed to be used for support requests. Crash reports aren’t handled by our support system, the reports are collected separately and batch-reviewed frequently, but later. Please also don’t expect a reply to crash reports. However, providing your mail address in the crash reporter gives us a way to come back to you, if we need additional information and it also helps to categorize reports.

So please send the crash reports, but use our support mail address for support requests!

Last but not least, the crash reporter’s comment field is definitely not a good place for name calling. It doesn’t really help to solve the problem and rather kills the mood and our motivation.

Definitely not always, but quite sometimes, it turns out that the cause for a crash wasn’t Übercaster itself, but some code running inside Übercaster in form of a plugin, audio unit or framework.

For example, here’s a message I received from a Übercaster user:

I've bought Ubercaster a couple of months ago. [...] The problem is that
the program always crashes.
I really need some help !

Fortunately, the user also attached a crash report:

Process:         Ubercaster [741]

Thread 4 Crashed:
0   ???                            0000000000 0 + 0
1 0x08070fc8
GNAudioUnitWrapperViewEntry + 463264
2   libSystem.B.dylib              0x942de6f5 _pthread_start + 321
3   libSystem.B.dylib              0x942de5b2 thread_start + 34

Yes, the problem is that the program always crashes. But it’s not Übercaster’s fault! Obviously, a 3rd party audio unit had some problems when loading into Übercaster.

The solution for this is relatively easy: throw away the faulty audio unit and/or contact the customer support of the audio unit.

Unfortunately it’s not always that easy to tell who’s really to blame. For example: The following backtrace was part of a Übercaster crash report:

Application: Ubercaster
App Version:    1128
Mac os:    10.6.2


Thread 10 Crashed:
0   libAudiointerposingLeo.dylib  	0x002a2995 AudioController::writeToInputAudioFile(...) + 39
1   libAudiointerposingLeo.dylib  	0x002a6965 SkypeCapAudioDeviceIOProc::ioProc(...) + 73
2   libAudiointerposingLeo.dylib  	0x002a3a6b AudioDeviceIOProcInterpose::internalIoProc(...) + 163
3   libAudiointerposingLeo.dylib  	0x002a78e1 AudioDeviceIOProcesPool::callRealIOProc(...) + 83
4   libAudiointerposingLeo.dylib  	0x002a865c _AudioDeviceIOProcesPool_staticIoProc(...) + 68
5     	0x91ce15b4 HP_IOProc::Call(...) + 374
6     	0x91ce131a IOA_Device::CallIOProcs(...) + 370
7     	0x91ce1116 HP_IOThread::PerformIO(...) + 620
8     	0x91cde4fa HP_IOThread::WorkLoop() + 2506
9     	0x91cddb2b HP_IOThread::ThreadEntry(HP_IOThread*) + 17
10     	0x91cdda42 CAPThread::Entry(CAPThread*) + 140
11  libSystem.B.dylib             	0x90be4fbd _pthread_start + 345
12  libSystem.B.dylib             	0x90be4e42 thread_start + 34

Well, Übercaster crashed!

But wait, where’s Übercaster in this backtrace? Right: nowhere. The only thing, Übercaster did wrong in this case, was its kindness to play host for another process. Several paragraphs of crash reporter gibberish later, I found the following information:

Binary Images:
   0x1000 -   0x1bdffb +com.pleasantsoftware.ubercaster v1.6.4 (1128) <..>
 0x2a1000 -   0x2b0fff +libAudiointerposingLeo.dylib ??? (???) <...>

So, I looks like another application on the user’s computer was responsible for the crash. Unfortunately it was Übercaster’s process which was killed by this, resulting in the user’s conception that Übercaster’s ability to record Skype conversations is faulty…

I guess, you get the point…

One last, recent example (I’m still working on this one!):

I recently received crash reports from some users, having problems during releasing AAC files with Übercaster.

The backtrace in the crash reports (i.e. the location where Übercaster crashed), looked always like this:

0   libSystem.B.dylib              0x96fd0732 __kill + 10
1   libSystem.B.dylib              0x96fd0724 kill$UNIX2003 + 32
2   libSystem.B.dylib              0x9706398d raise + 26
3   libSystem.B.dylib              0x970799d9 __abort + 124
4   libSystem.B.dylib              0x9705c71c release_file_streams_for_task + 0
5 0x9317fe2f UInt32ToHexString(...) + 183
6 0x9317feee MP4AudioFile::FillGaplessString(...) + 110
7 0x93182d85 MP4AudioFile::Close() + 627
8 0x930de085 AudioFileClose + 77
9 0x93141380 ExtAudioFile::Close() + 206
10 0x931414c8 ExtAudioFile::~ExtAudioFile() + 40
11 0x93136d20 XExtAudioFile::~XExtAudioFile() + 92
12 0x931369d8 ExtAudioFileDispose + 37
13  ...pleasantsoftware.ubercaster 0x000f6624 CAAudioFile::Close() + 26
14  ...pleasantsoftware.ubercaster 0x000f5f31 CAAudioFileConverter::ConvertFile(...) + 3545
15  ...pleasantsoftware.ubercaster 0x000d6f5a -[ReleaseSlot encodeToAAC:] + 2748

That’s a rather weird location inside Apple’s CoreAudio framework (to be exact, the AudioToolbox framework). Especially since the crash seems to happen when closing the encoded file, i.e. after the whole thing is more or less done, all input files read, mixed, sampled, compressed and so on.

In addition to that, the code in Übercaster surrounding the CoreAudio AAC encoding, didn’t change since several versions and didn’t cause any problems before.

So I checked all other crash reports, we received in the last months, for similar issues.
It turns out, that there are several other reports on the same problem.

Interestingly, all these reports were sent from a computer running Mac OS X 10.6.2 (10C540). The oldest report was sent at December 29, 2009. I didn’t find any reports matching this problem before that date.
Mac OS X 10.6.2 was released at November 9, 2009.

I’m still not sure what’s wrong, but there appears to be a connection between the latest Mac OS X release and the AAC encoding problems, some users experience.

Unfortunately I don’t know what Apple changed in CoreAudio (or elsewhere) what might cause these problems (there’s no hint on this in the official release notes). But I definitely know, that Übercaster runs the very same code when encoding AAC since several months without any problems and there is no single crash report on this before December 29.

That said, I checked the reports again, this time looking for other crashes concerning encoding/releasing audio.
I found some crash reports, where the crash happened during encoding MP3.
Übercaster encodes MP3 with the LAME framework (an open source MP3 encoder, so definitely not Apple’s code).
Interestingly, Übercaster didn’t crash inside the LAME framework or any native Übercaster code, but again inside CoreAudio or more accurately the AudioToolbox framework. That’s the exact same framework (provided by Apple) which is also involved in the crashes in the other reports.

The oldest were from October 11, 2009 and all found reports were sent either from a Mac OS X 10.6.2 or 10.6.1 machine (Mac OS X 10.6.1 was released on September 10, 2009).

This might all be a coincidence, but I rather think not.

I’ll definitely try to find out as fast as possible what exactly Apple did change in CoreAudio recently and how these changes cause Übercaster to crash.

To sum things up:

  • send us crash reports from within Übercaster!
  • use the comment field to give as much details on the circumstances of the crash as possible.
  • if possible, describe a way to reproduce the crash.
  • don’t use the comment text field in the crash reporter for support requests.
  • don’t expect a reply to your crash report. Write an additional support mail for that.
  • remember that there’s a (not too small) possibility that it’s not Übercaster’s code, causing the crash.

Thank you!

Übercaster Love

Another great review of Übercaster was published recently on the Cast Medium site:

Hilden of the Drunken Gamer Radio wrote an amazing piece on their production setup for their podcast production and on how much they love Übercaster.

Read the full article here.

Thanks to Drunken Gamer Radio and Cast Medium!

Übercaster receives 5 stars from Macworld

We’re proud that Übercaster v1.6 was honored by Macworld with a 5 star review and is now officially “Macworld Editors’ Choice”.

Read the full review here:

Ubercaster 1.6 review - Pro-standard podcasting tool is like having a radio production studio on your Mac

By the way, the Übercaster v1.6.4 update is already on its way and should be available during the next few days.

Next Page »

Pleasant Software is proudly powered by WordPress and themed by Mukka-mu (customized)