Hi,
I bought the Blue Cat Oscilloscope product today to debug a Mac OS X Audio Unit project I'm working on (I'm inserting the oscilloscope plug-in into an Audio Unit Graph to monitor to illustrate filtered audio traffic passing through it).
The Oscilloscope's "Cocoa UI" NSView (full panel) launches, and I'm displaying it in an NSWindow. All the widgets & buttons work. It looks properly initialized and ready to go. But when audio moves through the Audio Graph, apparently traversing through the oscilloscope plugin, the wave forms don't show up like they do when it's loaded in AULab or Garageband. Nothing happens. Same for your FFT plugin.
However the native Mac OS X/Apple effects filters to work when I instantiate them using the same method. The oscilloscope and FFT plugin work excellently when hosted by AULab and GarageBand. They also pass auval tests with flying colors. Therefore I think I must be doing something wrong or omitting.
But the following definitely shows the depth of the problem: When I select any of the CURVE ROUTING buttons, the application crashes immediately (see machine code traceback below). It is a null-pointer exception in an unnamed Blue Cat oscilloscope function.
If you can run this by your engineers, or any developer's on the forum can give me any clue at all as to what might cause this and what I might do to resolve it, I would be grateful.
BC Oscilloscope Multi 2 AU`___lldb_unnamed_function26256$$BC Oscilloscope Multi 2 AU:
0x1096e4010: pushq %rbp
0x1096e4011: movq %rsp, %rbp
0x1096e4014: cvtsd2ss %xmm0, %xmm0
0x1096e4018: movss 68(%rdi), %xmm1
0x1096e401d: comiss %xmm1, %xmm0
0x1096e4020: ja 0x1096e4050 ; ___lldb_unnamed_function26256$$BC Oscilloscope Multi 2 AU + 64
0x1096e4022: movss 64(%rdi), %xmm2
0x1096e4027: movaps %xmm0, %xmm1
0x1096e402a: maxss %xmm2, %xmm1
0x1096e402e: subss %xmm2, %xmm1
0x1096e4032: mulss 72(%rdi), %xmm1
0x1096e4037: addss 3428445(%rip), %xmm1
0x1096e403f: cvttss2si %xmm1, %eax
0x1096e4043: cltq
0x1096e4045: movq 56(%rdi), %rdx
0x1096e4049: cvtss2sd (%rdx,%rax,4), %xmm0 <=== Crash's here dereferencing null ptr
0x1096e404e: leave
0x1096e404f: ret
0x1096e4050: movss 64(%rdi), %xmm2
0x1096e4055: jmp 0x1096e402e ; ___lldb_unnamed_function26256$$BC Oscilloscope Multi 2 AU + 30
0x1096e4057: nop
0x1096e4058: nopl (%rax,%rax)
Any idea why I can't completely launch Oscilloscope?
-
sounds_like_audio sounds_like_audio https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=321969
- KVRer
- Topic Starter
- 2 posts since 10 Feb, 2014
-
Blue Cat Audio Blue Cat Audio https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=39981 - KVRAF
- 5820 posts since 8 Sep, 2004 from Paris (France)
Hi,
Thank you for your message. This is indeed strange. Just to make sure we are on the same page:
- is your application fully Cocoa (no carbon involved)?
- is it running in 32 or 64-bit mode?
- are you doing anything special with OSX timers? Our plug-ins use timers to update the user interface, so if it does not get updated, maybe they are just blocked.
By the way, if no curve is selected, then you cannot see anything on the graph anyway... Is the crash ALWAYS occuring?
If this is the case, one reason could be that the Init() method has never been called on the Audio Unit. Not sure which method of the AUGraph initiates this, but maybe you are missing a call to AUGraphInitialize?
Thank you for your message. This is indeed strange. Just to make sure we are on the same page:
- is your application fully Cocoa (no carbon involved)?
- is it running in 32 or 64-bit mode?
- are you doing anything special with OSX timers? Our plug-ins use timers to update the user interface, so if it does not get updated, maybe they are just blocked.
By the way, if no curve is selected, then you cannot see anything on the graph anyway... Is the crash ALWAYS occuring?
If this is the case, one reason could be that the Init() method has never been called on the Audio Unit. Not sure which method of the AUGraph initiates this, but maybe you are missing a call to AUGraphInitialize?
-
sounds_like_audio sounds_like_audio https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=321969
- KVRer
- Topic Starter
- 2 posts since 10 Feb, 2014
> - is your application fully Cocoa (no carbon involved)?
Carbon framework included in the project but currently 0% utilized. I will remove the framework. In 10.9 Mavericks carbon seems *very* difficult to use at all, with more carbon deprecated in 10.8. Xcode doesn't cooperate with it much. Took hacking to use any of it so I gave up trying. Glad to know I don't need to waste time trying carbon interface that auval indicates that your plugins export as well as Cocoa. That will spare me endless grief.
> - is it running in 32 or 64-bit mode?
64-bit app. Is that an issue?
> are you doing anything special with OSX timers? Our plug-ins use timers to update the user interface, so if it does not get updated, maybe they are just blocked.
I am not using timers, but will review the threading/locking etc carefully with that in mind to see how I might be tripping up the plugins.
> By the way, if no curve is selected, then you cannot see anything on the graph anyway... Is the crash ALWAYS occurring?
I was aware of that so I tried substituting in the Blue Cat FFT plugin, which doesn't graph anything either, yet doesn't require pre-selection of curves to display activity. With the scope, the crash is 100% consistent and instantaneous, occurring the moment I click any of the number buttons to assign a curve to a channel/instance. The exception is that I can click the go-away [X] in the upper-right corner of the curve-assign UI panel, with no assign buttons pushed prior, and no crash occurs. Then the widgets then all respond as expected, but no graphing occurs, as you indicated, as per no curve assignments.
> If this is the case, one reason could be that the Init() method has never been called on the Audio Unit. Not sure which method of the AUGraph initiates this, but maybe you are missing a call to AUGraphInitialize?
Graph init and start are definitely called. Testimony to that fact is that audio data flows through the graph, which includes Apple's low-pass and peak-limiter effect units preceding your plugins (plural meaning I use your fft & scope interchangeably at the same position in the graph experimentally). The Mac OS X standard peak limiter effect unit's graphics window shows data is flowing through it because it dynamically responds to changes in the audio signal.
But I will review the construction of the graph again under a microscope to see if there's any way your plugin might not be getting initialized in the construction of the graph, and ensure the peak limiter's output really connects to your plugin's input (I have checked that but I will validate that carefully).
I'll keep digging with an eye on initialization, threading and blocking.
I will also start a simple project that loads your plugin with no other effects or shenanigans and try 32-bit and 64-bit to see if that makes a difference (unless you clarify that it only works with 32-bit). If you have any examples or can point to any docs that show how to bring up your plugins in a sandbox, that would be probably too much to hope for
If anything else occurs to you please let me know.
Thank you!!
Paul
Carbon framework included in the project but currently 0% utilized. I will remove the framework. In 10.9 Mavericks carbon seems *very* difficult to use at all, with more carbon deprecated in 10.8. Xcode doesn't cooperate with it much. Took hacking to use any of it so I gave up trying. Glad to know I don't need to waste time trying carbon interface that auval indicates that your plugins export as well as Cocoa. That will spare me endless grief.
> - is it running in 32 or 64-bit mode?
64-bit app. Is that an issue?
> are you doing anything special with OSX timers? Our plug-ins use timers to update the user interface, so if it does not get updated, maybe they are just blocked.
I am not using timers, but will review the threading/locking etc carefully with that in mind to see how I might be tripping up the plugins.
> By the way, if no curve is selected, then you cannot see anything on the graph anyway... Is the crash ALWAYS occurring?
I was aware of that so I tried substituting in the Blue Cat FFT plugin, which doesn't graph anything either, yet doesn't require pre-selection of curves to display activity. With the scope, the crash is 100% consistent and instantaneous, occurring the moment I click any of the number buttons to assign a curve to a channel/instance. The exception is that I can click the go-away [X] in the upper-right corner of the curve-assign UI panel, with no assign buttons pushed prior, and no crash occurs. Then the widgets then all respond as expected, but no graphing occurs, as you indicated, as per no curve assignments.
> If this is the case, one reason could be that the Init() method has never been called on the Audio Unit. Not sure which method of the AUGraph initiates this, but maybe you are missing a call to AUGraphInitialize?
Graph init and start are definitely called. Testimony to that fact is that audio data flows through the graph, which includes Apple's low-pass and peak-limiter effect units preceding your plugins (plural meaning I use your fft & scope interchangeably at the same position in the graph experimentally). The Mac OS X standard peak limiter effect unit's graphics window shows data is flowing through it because it dynamically responds to changes in the audio signal.
But I will review the construction of the graph again under a microscope to see if there's any way your plugin might not be getting initialized in the construction of the graph, and ensure the peak limiter's output really connects to your plugin's input (I have checked that but I will validate that carefully).
I'll keep digging with an eye on initialization, threading and blocking.
I will also start a simple project that loads your plugin with no other effects or shenanigans and try 32-bit and 64-bit to see if that makes a difference (unless you clarify that it only works with 32-bit). If you have any examples or can point to any docs that show how to bring up your plugins in a sandbox, that would be probably too much to hope for
If anything else occurs to you please let me know.
Thank you!!
Paul
-
Blue Cat Audio Blue Cat Audio https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=39981
- KVRAF
- 5820 posts since 8 Sep, 2004 from Paris (France)
64-bit is definitely supported, and it is actually much better since it means there cannot be any old Carbon calls involved...
Our plug-ins should actually run in a sandboxed environment (with a few limitations). We do not have any documentation about this though... I am afraid you may have to deal with Apple's!
Our plug-ins should actually run in a sandboxed environment (with a few limitations). We do not have any documentation about this though... I am afraid you may have to deal with Apple's!
