March 17, 2007


by Chris Randall

Has anybody had problems with their AudioUnits after upgrading to 10.4.9? We're experiencing some weird issues here, and are trying to build a consensus so we know what's wrong.

PLEASE NOTE: It's a simple question, with a simple answer. It doesn't need to devolve in to a Mac v. PC or Intel v. PPC or OSX v. OS9 debacle. Quite frankly, I could give a fuck, and will be liberal with my kill button.



Page 2 of 3

Mar.17.2007 @ 7:58 PM
thanks emulsion, i can now eject again...


Mar.18.2007 @ 1:08 PM
I have some Audio units that failed validation, some Ohmforce ones (ones I seldom use) but to me the biggy is Cyanide2 which I use a lot. Fortunately for me I also use a VST wrapper and the ones that fail via AU vaildaton I can use their VST counterparts.

I don't use Waves so I don't know about issues there.

All the Native Instrument ones seem to work and I'd say easily 95% of the ones I have passed.

If you need a list I could make one.


Mar.18.2007 @ 2:27 PM
Chris Randall
No need for a list. I think the general consensus we've built is that Apple Fucked Up The AU Kit Yet Again. This only makes the fourth time? Fifth?

The way we discovered it was that Adam was working on a Dubstation maintenance release to fix some minor automation issues in Logic, and make it able to do any sample rate (yay! for some people) and the build he made in 10.4.9 didn't work on my 10.4.8 machine.

This actually brings in to light how difficult it is to develop AudioUnits. There was NO announcement on the CoreAudio list at all about maintenance releases to the AU kit. And now that everyone is having troubles, there has still been no comment from Apple at all.

In any case, we'll hopefully get to the bottom of it, but we, like other companies, recommend not moving to 10.4.9 until this is sorted out.



Mar.18.2007 @ 3:08 PM
Artemiy Pavlov
Here Reverence and Discord 2 work normally, as are other plugins including my own.

BTW my AU Lab is 1.0.3 like it used to be before 10.4.9. Can anyone confirm which exact new version they have?


Mar.18.2007 @ 9:08 PM
When the second-to-last QT update killed my Darbuka soft-instrument, I started to sniff trouble. Whenever Apple gets to the end of a development branch, this sort of crap crops up. Their main focus is 10.5 right now, and it shows.

Mar.18.2007 @ 9:19 PM
Chris Randall
I think their plan is to make the previous point unusuable, so you have to buy the next one. That's just a stab in the dark, of course.



Mar.18.2007 @ 10:34 PM
I think I'm gonna freeze at PPC/10.4.8/Logic 7.1 for a few years, let the world roll by, and just keep getting my work done (and the Logic 8 rumors are rather disquieting, to say the least). Hell, I know plenty of mastering engineers who still use OS9 every day. If Sequoia makes it to OSX or Linux, that will really get my attention, but my main interests these days are microphones and acoustic instruments. And Dr. Device. And a Resonator with that too, please - straight, no chaser.

Mar.19.2007 @ 3:27 AM
Moyashi, I'm with you on this (well, just get the 7.2.3).

And it's a shame music software developers are treated in such a way by Apple.


Mar.19.2007 @ 9:59 AM
It isn't only pure-software developers, hardware guys too.
Here's the head engineer at Metric Halo writing yesterday about new incompatibilities with their Firewire interface drivers. The last line says it all. Sorry for so egregiously highjacking the thread:

"There is a problem between the Mac Pro on 10.4.8 and newer (not on 10.4.7 though) where the driver can get into an error condition that causes audio to stop and requires a reboot of the Mac Pro. We have determined the cause of this problem and have fixed it; we will be posting a new driver this week that eliminates the issue.

Basically, the problem is that the Firewire HW is 32-bit, but the Mac OSX kernel on the Mac Pro is 64-bit, and extra care must be taken to ensure that all buffers for Firewire are constrained to be in the memory accessible with 32-bit addresses. This, unfortunately was never documented by Apple -- so it took us by surprise."


Mar.19.2007 @ 1:25 PM
Adam Schabtach
Thanks for the info, everyone. We appreciate your help and patience with this stuff.

Artemio: what kind of Mac are you running? Intel or PPC? I haven't yet caught up with the latest grapevine chatter but it appears that part of the problem may be that the Software Update control panel does not install the 10.4.9 update correctly on Intel Macs. I'm using an Intel iMac for AD work these days. The version of AU Lab on my machine says 1.0.2; however, AU Lab is usually not installed by the OS installer. The version of auval _has_ changed, however. It's not clear whether something to do with AUs has really changed, or whether just auval itself changed. The latter implies the former, however.

In any case, I posted a query on the coreaudio-api list and hopefully someone at Apple will manage to say something useful sooner or later. For the moment this effectively kills our AU development. I don't know what has happened to my machine and I have no way of reverting to 10.4.8 aside from wiping the hard drive and rebuilding from scratch, and obviously I'm putting that off as long as I can. (Yes, I know, I should have a complete backup. I have a documents backup but not a complete disk backup.)

Peter K: thanks for the posting on CDM. IMHO it needs to be pointed out more often that these problems ARE APPLE'S FAULT while it's the third-party developers that take the hit from the irate customers. Regarding the assertion (not by you, by someone else) that we should be testing against seed releases, here is my experience doing exactly that in the past: First, it takes a huge amount of time. There are typically several seed releases for any given OS update. They are always accompanied by scary warnings about not using the seed for production work, not using it on any system that contains data you don't want to lose, etc. These are all sensible warnings for a pre-release version of an OS. Basically you have to start with a bare drive to test every single seed release, and that means installing whatever base version of the OS you have handy, installing the seed, installing whatever apps you need to test against, installing all of your products, testing all of your products against all of the apps. We're talking about days of work for each seed release. Now, that might be viable for, say, the very last seed prior to the official release of the final version. However, there is no guarantee that the official release will be the same code as the last seed! So it's entirely possible--and it has happened--that Apple will publicly release an update that has never been provided to anyone outside of the company, Select developers included. So in other words, those days of testing against the seeds are not guaranteed to do anyone any good at all.

Next, why should this testing responsibility fall upon shoulders outside of Apple? Apple provides the operating system and the documentation and code frameworks needed for third-party developers to create products that work with the operating system. Why is it our responsibility to test Apple's work? Shouldn't they be testing their own work? I know that the Logic team has copies of our AU products, so I presume they have copies of the products from higher-profile companies such as Waves. Did anyone on the Logic team test 10.4.9 before its release?

Let me illustrate my point with an analogy: The operating system is the infrastructure upon which programs run. Think of the OS as roads, bridges, highways, etc. and the programs as automobiles, trucks, etc. Suppose the California Department of Transportation said "hey, we're doing maintenance work on the Golden Gate bridge, so to test our work we'd like everyone who plans to drive across this bridge in the future to come drive their current cars and trucks across the bridge. Make sure you don't have anything valuable in the car, though, because this isn't the final bridge so it may collapse during this testing and your car may end up in the bay. Oh, and there will be several more of these tests before we finalize the bridge, so please come to all of them." How many people do you think would show up to participate in the test? If you didn't participate in the test and later, the final version of the bridge collapsed when you drove across it, would you take responsibility for the collapse because you didn't do the testing?



Page 2 of 3



Sorry, commenting is closed for this blog entry.