Hello guys,

I've started to use OpenMP under Windows a few weeks ago and I've got it to work without much troubles.
I'm using it just to parallelize the stereo processing of my plug-ins, so that the main thread processes the left channel and a child thread processes the right one.
The code itself is nothing fancy, I'm simply using parallel sections around my processing loops.

As I've said, everything is running fine under Windows, but as soon as I've ported my code to OSX, I've been experiencing crashes whenever I've tried to run the parallelized sections.

I've been doing some research and found this:
http://osdir.com/ml/coreaudio-api/2009-05/msg00018.html

which is exactly the same issue I'm facing, according to the debugger (EXC_BAD_ACCESS on gomp_resolve_num_threads).
Reading that newsletter, it seems that there may be compatibility issues between OpenMP and CoreAudio threads (which run in time constraint thread context).

Has anybody been able to use OpenMP with CoreAudio? Or can anybody confirm that it is just not possible to use them together?

I'm using OSX 10.6 with XCode 3.2 (GCC 4.2)

Thanks in advance

I think you are using the wrong approach to improve performance of your plugins. I would avoid that kind of parallelization at all costs and prefer to use vectorized processing (http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions  ) instead. If you have already done that, the next step is not using a different thread for each channel. Managing different audio threads is the hosts responsibility and I'd prefer not to do anything that could interfere with it.

I get your point, but vectorized processing is not an option in my case, as it would require a complete rewrite of the DSP code and it may not even provide that much performance increase depending on the algorithms (even with 16byte aligned data, I've experienced performance decreases a lot of times because of the slow SSE registry data storing and loading).
I know that is better to let the host manage audio threads, but plug-ins are basically black boxes, so there is no way for the host to parallelize stereo processing inside of them.
It may interfere with other plug-ins processing, as you say, in fact my idea was to test the performance and potential issues and decide if it's worth it or not.

Just to clarify, my question is related to the OpenMP/CoreAudio compatibility, I'm not asking for the best solution to parallelize my code.

Thanks for your suggestions, anyway

I dont think that the problem is that OpenMP and CoreAudio is incompatible, but just that the basic approach is flawed and it will not always work. If you have tested it on windows with a particular host and it has worked without a problem, that's fine (with that host), but it may fail similarly with another host on windows.

In case someone is facing the same issue, I've got it to work by compiling the plug-in with GCC 4.7 from MacPorts.

Cheers

Hello,

I've tried to use OpenMP with CoreAudio and the main problem was that it did something that disturbed the Realtime-Thread the host was offering me.

We then decided to use boost::thread instead which works almost perfectly

Also I want to say that it is indeed better to use SIMD processing - when you can. But when the cpu is at max for a single plugin, it helps to give the users an option for multi threading!

Cheers,
- Clemens

Did it worked fine with low latency callbacks like with a buffer size of 128 ?

Thx

Sorry for the late reply, I just came back from vacation...

Yes I think it did but it was sort-of cpu dependent! Old cpus (before i5/i7 2nd gen or older amd) showed some limitations but that might have been due to the lack of an on-cpu memory controller.

Also, on windows, it only worked when keeping the threads alive all the time - stopping and opening new ones hurt the performance significantly. That said, it's smarter this way anyways

Cheers,
- Clemens

It make sense to use a pool of thread indeed.

Good to know that it works ok on modern CPU though.