Re: DVCPROHDAudio.plugin freezes at instantiation
Re: DVCPROHDAudio.plugin freezes at instantiation
- Subject: Re: DVCPROHDAudio.plugin freezes at instantiation
- From: Brian Willoughby <email@hidden>
- Date: Tue, 20 Apr 2010 21:17:53 -0700
I believe that +initialize is not called until right before the first
message is sent to an ObjC class, so that might be a quick and easy
way to move your +load code to a later point in time. However, there
may be other, more definitive means for moving your initialization to
a later point in time.
(Yes, I realize ObjC is off-topic for CoreAudio, but I'd like to see
MTCoreAudio work)
Brian Willoughby
Sound Consulting
On Apr 20, 2010, at 20:53, Jeff Moore wrote:
The interesting part of this backtrace is, as you point out, the
initialization of the HAL prior entering main. While I don't
believe that this is going to be an issue for the HAL proper
because of the way the linkage works, it is possible that something
the AVC plug-in needs hasn't been loaded and/or initialized at this
point of the program execution.
It would make a good experiment to shift the initialization to some
point after entering the main() of the program. For library code,
you have a few options. You can make a class method that clients
need to call to initialize things. You could also implement lazy
initialization, but I'm less clear on how that would work with an
ObjC.
On Apr 20, 2010, at 3:47 AM, Martin Hairer wrote:
I was just wondering if this is a known problem or if there's a
fault somewhere with my software...
On some user's machines, my software freezes upon launch, which is
obviously rather annoying.
In every single instance where this happened, the problem was
resolved by removing the
"DVCPROHDAudio.plugin" from the user's Library folder. The problem
seems to be triggered
by this plug-in only under certain circumstances (certain devices
attached to the computer),
so I actually haven't been able to reproduce it myself on any of
my machines. However, I got
about a dozen or so user's reports and they can all generate
traces that are similar to the one
shown at the end of this email (essentially it gets stuck in
APW::Mux::DVCProHD::Muxer::Muxer).
If this is a known problem, does Apple have a fix for this or
should I try to file a bug report? Also,
does anyone have an idea why this doesn't cause every single Audio
related software on these
user's machines to freeze? After all, most of these would probably
make a call to
AudioHardwareAddPropertyListener at startup. The offending method
in MTCoreAudioDevice is
+ (void) load
{
_MTCoreAudioHardwareDelegate = nil;
AudioHardwareAddPropertyListener
( kAudioPropertyWildcardPropertyID,
_MTCoreAudioHardwarePropertyListener, NULL );
}
Is there anything wrong with calling
AudioHardwareAddPropertyListener in the "load" method of
an Objective-C class? (i.e. should I try to defer that call to a
later time?) Regards,
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden