# Backend Audio Fundamentals **URL:** \ **Category:** Getting Started\ **Created:** [October 30, 2024, 4:12am UTC](https://forum.juce.com/t/backend-audio-fundamentals/64003 "2024-10-30T04:12:48Z")\ **Posts on this page:** 14\ **Page:** 2
**Author:** ![xenakios](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/xenakios/32/4047_2.png) [@xenakios](https://forum.juce.com/u/xenakios)\ **Post date:** [November 2, 2024, 9:27pm UTC](https://forum.juce.com/t/backend-audio-fundamentals/64003/21 "2024-11-02T21:27:29Z")
You make it sound like C++ modules are actually a usable thing now? That’d be news to me. The commonly used compilers now actually support it? ---
**Author:** ![jaxrowe](https://avatars.discourse-cdn.com/v4/letter/j/f9ae1b/32.png) [@jaxrowe](https://forum.juce.com/u/jaxrowe)\ **Post date:** [November 2, 2024, 9:36pm UTC](https://forum.juce.com/t/backend-audio-fundamentals/64003/22 "2024-11-02T21:36:03Z")
I mean don’t take my word on anything x) I just got the impression to use them when I first started researching cpp. How they hold up in a real world scenario, no idea. I know clang++ 18.1.3 supports it and CMake 3.30 as well (since 3.28 I believe), I been using it all along. If anyone is curious how to build with them I can share a doc I have. I’ll spare dumping it here for now, but will on request 😛 edit : For Clang, install LLVM/Clang 16.0 or newer. For GCC, install GCC 14 and GCC 14 2023-09-20 daily bump or newer. > **[import CMake; the Experiment is Over!](https://www.kitware.com/import-cmake-the-experiment-is-over/)** > > At last the experiment is over, and CMake 3.28 has official support for C++ 20 named modules enabled without having to set the CMAKE\_EXPERIMENTAL\_CXX\_MODULE\_CMAKE\_API variable. This has been a long adventure involving the coordination of the SG15... ---
**Author:** ![xenakios](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/xenakios/32/4047_2.png) [@xenakios](https://forum.juce.com/u/xenakios)\ **Post date:** [November 2, 2024, 9:45pm UTC](https://forum.juce.com/t/backend-audio-fundamentals/64003/23 "2024-11-02T21:45:26Z")
Well, maybe I will take a look some day soon. But I feel like the modules are still way too new to invest much time and effort in. Once they work properly across all the common compilers and platforms, they will no doubt be great. Working with C++ for almost 20 years has taught me to be relatively conservative about new things. 😉 ---
**Author:** ![jaxrowe](https://avatars.discourse-cdn.com/v4/letter/j/f9ae1b/32.png) [@jaxrowe](https://forum.juce.com/u/jaxrowe)\ **Post date:** [November 2, 2024, 9:56pm UTC](https://forum.juce.com/t/backend-audio-fundamentals/64003/24 "2024-11-02T21:56:14Z")
I seee… and cautious you should be, your probably doing real production work. By the time I have any real projects that would make me cautious of using the new shiny thing, they will probably be more trusted. Glad I could bump your interest tho 🙂 looking forward to them throwing a wrench in all my study projects I pushed the doc to the readme of my practice repo for the record, might spare someone the dig : > **[GitHub - jaxrowe/juce-qt-practice: for practicing juce, qt, and juce with qt](https://github.com/jaxrowe/juce-qt-practice)** > > for practicing juce, qt, and juce with qt ---
**Author:** ![jaxrowe](https://avatars.discourse-cdn.com/v4/letter/j/f9ae1b/32.png) [@jaxrowe](https://forum.juce.com/u/jaxrowe)\ **Post date:** [November 13, 2024, 11:19pm UTC](https://forum.juce.com/t/backend-audio-fundamentals/64003/26 "2024-11-13T23:19:35Z")
[![](https://us1.discourse-cdn.com/flex026/uploads/juce/original/3X/4/6/46981210edcb3e7d6c9532e17eebf0ab30cfb9b1.jpeg "Qt and C++20 | #QtWS22") ](https://www.youtube.com/watch?v=_XGFxQd9HWk&t=866) lol you were right…thats a wrap on modules if you want to use Qt. no big deal I guess ---
**Author:** ![LiamG](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/liamg/32/6844_2.png) [@LiamG](https://forum.juce.com/u/LiamG)\ **Post date:** [November 14, 2024, 4:13am UTC](https://forum.juce.com/t/backend-audio-fundamentals/64003/27 "2024-11-14T04:13:34Z")
Hi, This might be one of those annoying responses, but why not just use Juce for your UI instead of Qml? From skimming over this thread, it seems to me that you are trying to solve a lot of low-level problems that would simply vanish if you just used Juce and started with a standard template. That’s the beauty of having an integrated library. Is there something specific that you want to accomplish with your UI that you’re worried Juce can’t handle? BTW, you’re way ahead of where I was after 3 months of software development 😆 ---
**Author:** ![jaxrowe](https://avatars.discourse-cdn.com/v4/letter/j/f9ae1b/32.png) [@jaxrowe](https://forum.juce.com/u/jaxrowe)\ **Post date:** [November 14, 2024, 6:07am UTC](https://forum.juce.com/t/backend-audio-fundamentals/64003/28 "2024-11-14T06:07:48Z")
Ehh i dunno really, I never really gave JUCE a decent shot for gui. I’m sure its well capable of what I would want to do…I got annoyed with it early on tryin to make layout or somthing and just assumed Qt would be better in the long term since it’s the global standard for interfaces and has alot of bells and whistles. I figure it would pay off in the long run…obviously comes with a price to pay. Gives you a broader scope for employment also so kinda two birds one stone thing. not tryin to dump on juce in any way, but theres no turin back now x) and its given me a reason to dig into juce guts and thanks I been laid off so been going hard on it lol its been rough ---
**Author:** ![LiamG](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/liamg/32/6844_2.png) [@LiamG](https://forum.juce.com/u/LiamG)\ **Post date:** [November 14, 2024, 8:25am UTC](https://forum.juce.com/t/backend-audio-fundamentals/64003/29 "2024-11-14T08:25:49Z")
> [@jaxrowe](#): > > but theres no turin back now x) This may not be the case. I can’t tell you how much time I have invested into learning a new library and integrating it into my project, only to pry it out months (or years) later when I finally realized it was the wrong tool for the job. As you mentioned, it’s all about trying to figure out what will pay off in the long run. Sometimes you invest time in something that ends up paying 10x as soon as you get the hang of it. Other times it turns out to be a complete dead end. If only we could tell before-hand! Keep us updated with how its going. ---
**Author:** ![jaxrowe](https://avatars.discourse-cdn.com/v4/letter/j/f9ae1b/32.png) [@jaxrowe](https://forum.juce.com/u/jaxrowe)\ **Post date:** [November 15, 2024, 5:27am UTC](https://forum.juce.com/t/backend-audio-fundamentals/64003/30 "2024-11-15T05:27:51Z")
I just want to say I am writing these kinds of post as like a solilquy (a note to self), just to share and for anyone that comes after me… not tryin to act like I’m informing anyone, I’m the nublet here 🙂 > [@jaxrowe](#): > > AudioDeviceManager.audioDeviceIOCallbackInt About this, from my long post. I knew by looking at the code this is the only method that could return the samples, but couldn’t see how it was called. I attached a debugger to `getNextAudioBlock()`, trying to understand what was running on my audio thread and accidentally found this : ![debug](https://us1.discourse-cdn.com/flex026/uploads/juce/original/3X/6/c/6cb542b89bf6d90f9e74649ef8e0a985482917a6.png) So there it is. There is a subclass of juce::Thread that calls `AudioDeviceManager::CallbackHandler::audioDeviceIOCallbackWithContext` and then `AudioDeviceManager::audioDeviceIOCallbackInt` From there, you can follow the smaller diagram from my previous post to see the path to the samples. `juce::ALSAThread::run juce_ALSA_linux.cpp:726` So I think, this method is literally your audio thread. If you look into juce::Thread(), inside the run() method is what gets executed on the new thread. It created a ALSAThread because I’m on linux. When you ran `AudioDeviceManager.initialise()`, it probably created this in that chain reaction. My first guess would be when it hits `currentAudioDevice->open`, or somewhere around there. Anyways I’m putting a flag in the ground on this train of thought. I have alot of other stuff to get to, and this can’t be a priority (and those `threadEntryPoint()` calls is like looking over the edge of a cliff). Wayyy over my head here, but this might come into play like a year from now ---
**Author:** ![freekuency](https://avatars.discourse-cdn.com/v4/letter/f/b9bd4f/32.png) [@freekuency](https://forum.juce.com/u/freekuency)\ **Post date:** [October 5, 2026, 2:51pm UTC](https://forum.juce.com/t/backend-audio-fundamentals/64003/31 "2026-10-05T14:51:56Z")
I would like to use JUCE in combination with Qt-QML for the GUI too. I did notice that Qt now has official documentation specifically covering integration with other UI toolkits, including plugins: “Mixing Qt with other UI toolkits”. Will this change the story above and makes things more easy? ---
**Author:** ![joeloftus](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@joeloftus](https://forum.juce.com/u/joeloftus)\ **Post date:** [October 5, 2026, 8:03pm UTC](https://forum.juce.com/t/backend-audio-fundamentals/64003/32 "2026-10-05T20:03:12Z")
Makes no sense to use Qt for the GUI in conjunction with JUCE, especially plugins. JUCE is far superior imo. For one your binary size will be way bigger and your wallet much lighter, in fact if you’re planning on using Qt why even use JUCE at all? ---
**Author:** ![xenakios](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/xenakios/32/4047_2.png) [@xenakios](https://forum.juce.com/u/xenakios)\ **Post date:** [October 5, 2026, 8:55pm UTC](https://forum.juce.com/t/backend-audio-fundamentals/64003/33 "2026-10-05T20:55:10Z")
> [@joeloftus](#): > > in fact if you’re planning on using Qt why even use JUCE at all? There could be various reasons why people might want to mix different frameworks or make custom ones for a project. For example, I’ve myself grown more and more interested with the idea of using JUCE only for the GUI and drop out using the audio parts of JUCE. The AudioProcessor architecture in JUCE seems to have gotten quite stagnant/outdated. The JUCE team has promised that will be changed/upgraded in Juce 9, but that remains to be seen… ---
**Author:** ![joeloftus](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@joeloftus](https://forum.juce.com/u/joeloftus)\ **Post date:** [October 5, 2026, 9:33pm UTC](https://forum.juce.com/t/backend-audio-fundamentals/64003/34 "2026-10-05T21:33:24Z")
Yeah I think you missed my point, I also do the same. But coming from the perspective of using qt with juce seems kinda backwards as the main benefit of juce is the gui framework in my opinion. Whereas qt is bloated, expensive and not good for plugins ---
**Author:** ![freekuency](https://avatars.discourse-cdn.com/v4/letter/f/b9bd4f/32.png) [@freekuency](https://forum.juce.com/u/freekuency)\ **Post date:** [October 5, 2026, 11:04pm UTC](https://forum.juce.com/t/backend-audio-fundamentals/64003/35 "2026-10-05T23:04:02Z")
QML is far more superior compared to the GUI of Juce. So it makes perfect sense to use Juce as the plugin frame work but use Qt-QML for the GUI. [Previous page](https://forum.juce.com/t/backend-audio-fundamentals/64003.md?page=1)