MacOS render thread issues with Audio Unit API

Having problems with building or using CEF's C/C++ APIs? This forum is here to help. Please do not post bug reports or feature requests here.

MacOS render thread issues with Audio Unit API

Postby rudolfsb » Tue Feb 13, 2018 5:05 pm

Hi,

We are developing a product using CEF which so far has been great until today I ran into a strange issue which most likely comes from not understanding something.

The core issue is - when I try to do a call to Audio Unit API to create a component (to be more precise I am calling AUGraphAddNode), I always get OSStatus value -3000. This is happening in C++ by invoking a function that has been exposed to JS via V8, the call stack is something like

... my c++ stack frames ...
#6 0x00000001002c25f6 in (anonymous namespace)::v8handler_execute(_cef_v8handler_t*, _cef_string_utf16_t const*, _cef_v8value_t*, unsigned long, _cef_v8value_t* const*, _cef_v8value_t**, _cef_string_utf16_t*) at /Users/Rudolfs/Downloads/cef_binary_3.3202.1683.gb095524_macosx64/libcef_dll/cpptoc/v8handler_cpptoc.cc:72
#7 0x0000000100c3155b in ___lldb_unnamed_symbol2357$$Chromium Embedded Framework ()
#72 0x0000000100be1ba0 in cef_execute_process ()
#73 0x000000010036d297 in CefExecuteProcess(CefMainArgs const&, scoped_refptr<CefApp>, void*) at cef_binary_3.3202.1683.gb095524_macosx64/libcef_dll/wrapper/libcef_dll_wrapper.cc:199
#74 0x00000001001064b8 in main at ProcessHelper.cpp:14
#75 0x00007fffe8e45235 in start ()

I initially though this had something to do with codesigning or entitlements, some restrictions on the child process. But if i simply run the child process standalone and do the call first thing in main, everything is fine. Even when running normally (CEF client app + helper app) if the call is the first thing in main of the helper app, everything is fine, but if the call comes from the V8 callback (which looking at the stack runs on the same thread) I get -3000. Are there any restrcitions that are set to the renderer thread after CefExecuteProcess is called? Are there simply some restrictions on the V8 callback? This does not happen on Windows (of course there is no Audio Unit there, but we are dispatching calls to WASAPI from the rendering thread and everything is fine). Since the Windows part is already done, I would not be very happy to rework everything to dispatch the calls to some other thread (not sure if that solves this, but I'll check it out). The main reason for posting here is to check if anyone can just tell me some known limitations/restrictions that are set to this thread because of which my AudioUnit calls would fail.
rudolfsb
Newbie
 
Posts: 3
Joined: Tue Feb 13, 2018 4:53 pm

Re: MacOS render thread issues with Audio Unit API

Postby magreenblatt » Wed Feb 14, 2018 9:14 am

Likely your call is being blocked by the sandbox. On Windows you're probably building without the sandbox enabled. You can try passing the --no-sandbox command-line flag to confirm.

You should instead be making these types of calls from the main process using IPC to communicate with JavaScript bindings. See https://bitbucket.org/chromiumembedded/ ... t-bindings
magreenblatt
Site Admin
 
Posts: 12382
Joined: Fri May 29, 2009 6:57 pm

Re: MacOS render thread issues with Audio Unit API

Postby rudolfsb » Wed Feb 14, 2018 10:24 am

Thank you for the reply. I was thinking about IPC but I need to report some results back to javascript - I know I could do that via some callbacks, I'll think about it. If I had encountered that on Windows in the first place, I most likely would have designed the calls in an asynchronous manner. On the other hand, none of the stuff that I'm doing is blocking or heavy so it should be fine. If I remember correctly then I can turn of the sandboxing via CefSettings as well, I'll give that a shot ,thanks :)
rudolfsb
Newbie
 
Posts: 3
Joined: Tue Feb 13, 2018 4:53 pm

Re: MacOS render thread issues with Audio Unit API

Postby rudolfsb » Wed Feb 14, 2018 10:41 am

Yes, disabling the sandbox fixed it, thanks:) I'll consider if I can switch the calls to async mode, but at least for now I'm able to move on.
rudolfsb
Newbie
 
Posts: 3
Joined: Tue Feb 13, 2018 4:53 pm


Return to Support Forum

Who is online

Users browsing this forum: Google [Bot] and 24 guests