Using JUCE for Software Defined Radio --> Could mixing JUCE with another framework cause trouble?



for a university project, I have to develop some Software Defined Radio (SDR) stuff. A first proof of concept was done in gnu radio, but I found out that the SDR-frontend manufacturer Ettus has a big C++ Library named uhd that can be used for developing applications for their USRP Transceivers.

This library depends on boost and uses some own implementation for real-time-threading and so on (I just scratched the surface until now). Now my question is: Could combining JUCE and uhd in one application cause troubles as both use their own - very different - threading functionality and probably some other things I haven’t come across until now? What would happen if for an example I wanted to build an audio app using the SDR, a simple FM Receiver for an example, using the RF samples coming in from the SDR Transceiver in an uhd realtime thread and outputting audio samples in a JUCE-way from a JUCE realtime audio thread?

Or should I try to build a JUCE-style wrapper around that Ettus stuff using as much JUCE functionality as possible (maybe even using a JUCE thread)?

Any experience with similar framework-mixture?


Okay, maybe I should ask the question in a more General way.
UHD seems to use boost::threads under the hood and has an own wrapper function to specify the thread priority throug a Double value with a range from -1 to 1. JUCE threads allow to specify an integer thread priority from 1 to 10.
In the end, both Implantations are pthread-wrappers (correct me if I’m wrong), but I’m not sure if two frameworks, both spawning their high priority threads in their own way could cause some kind of conflicts or unpredictable runtime behaviour?

Even if no one here has any experience in combining exactly these frameworks, are there experiences with similar framework mixture?


There’s no reason I can think of why there’d be any problems at all in using juce with any other library. Certainly no run-time problems, the worst you could expect would be a symbol linking clash or something, but that’s also unlikely.