Open Audio Live System is a highly customisable live audio environment meant to offer an open alternative for professional live audio context with real-world usage in mind.
This system is divided in four major parts :
- Hardware : IO Boards, DSP Boards, stagebox enclosures, Control surface...
- Control UI
- DSP implementation targeted for high performance ARM embedded systems
- L2 Network protocol that allows audio transport, node control, node discovery and PTP clock sharing across an Ethernet switched network
This repo contains the major "software defined" components of the console that rely on OpenDSP and OpenAudioNetwork. These components are the console UI, the console DSP and the plugin loader.
.
βββ OpenAudioNetwork # L2 Networking module
βββ OpenDSP # DSP base library
βββ coreui # Console UI
β βββ core # Wrappers for OALS objects around Qt framework
β βββ pipes # Baked-in pipes UI implementation
β βββ surface_config # Console settings
β β βββ pipes.json # Processing pipes templates config
β β βββ surface.json # Contains the surface networking and plugin configuration
β βββ ui # Generic UI code handling pages, basic menus, ...
βββ debugger # Small debugging app for networking
βββ engine # DSP engine
β βββ piping # Baked in pipes DSP implementation
βββ io_sim # (Deprecated) Small user-space virtual sound card
βββ plugins # Plugin loader and built-in plugins folder
βββ builtin # Builtin plugins code
βββ loader # Plugin loader and interface library
This console system software tries to minimise the count of external dependencies. The only needed dependency is the Qt 6 framework. Otherwise, it compiles like any standard cmake project.
$> git clone git@github.com:OpenSoundStack/OpenAudioLiveSystem.git --recurse-submodules$> mkdir ./build && cd ./build
$> cmake <path_to_cloned_repo>
$> cmake --build . --target allAs this project is made for specific hardware, it can be a bit tricky to get it running on your own machine. There are two ways to do that.
There are no kernel drivers developed yet for the networking part, because of that the engine and the UI must run as root because the network protocol is a L2 protocol relying on raw packet sockets.
Tip
If the setup is for development purposes, it is highly recommended to set up remote debug session with the console binaries not running on the host machine.
Warning
Don't forget to do a cmake install before running to ensure the plugins are properly compiled and installed. You'll encounter errors if there are mismatch between plugin lists on the DSP and the UI.
Caution
The network protocol is NOT routable. No IP tunnelling is provided at the moment. The network the console is working on must be switched.
There are no support (yet) for IO emulation. However io_sim can be used as a template to load and send in loop STEMs on
the console network.
That way is mainly for those who just wants a debugging environment. The DSP must run in a virtual machine running the Linux flavour of your choice, ideally using an RT patched kernel. The virtual machine must be connected on a virtual network with the host. The host will run the UI.
If everything went OK, both apps should see each-others on the network. It will be notified in the logs.
If you happen to have two physical machines running Linux, a network switch and optionally IO Boards β they can always be simulated in software β you can run the console in the way it was meant to.
Run the DSP engine on one machine, the UI on the other and connect them on the same switched network.