Project Logs

Collapse

• 3.35ms latency on real hardware. Looking for 3-5 co-builders to scale the architecture

  Francesco Nano • 5 hours ago • 0 comments

  OLMS (Open Live Mixing System https://openlivemixingsystem.org/ ) Proof Of Concept is running stable. Latest tests on Focusrite Scarlett Solo confirm 3.350ms real-world latency (hardware loopback) with only 1.650ms USB/converter overhead against theoretical buffer size. This isn't a weekend experiment—it's a professional live mixing infrastructure: headless, deterministic, RT-optimized.

  The Gap We're Filling Hardware digital mixers: expensive, closed, fixed capabilities. Standard DAWs: not designed for headless reliability in critical live contexts. OLMS bridges this: a distributed, modular mixing engine optimized for RT kernel, turning commodity hardware into professional-grade low-latency audio processing.

  What We Need (Specifically) We're assembling the founding contributor core (3-5 people) to scale the architecture over the next 4 weeks. Requirements:

  • System competence: Daily Arch Linux user, RT kernel experience, advanced bash scripting, comfortable with JACK2/Ardour stack.
  • Hardware: USB Class Compliant audio interface to replicate tests across different environments.
  • Time commitment: 4-6 hours/week for 4 weeks.

  NOT looking for: Passive testers, people who "want to learn", or those expecting plug-and-play software. This requires getting your hands dirty in code and system tuning.

  What You Get

  • Co-Contributor status: Real ownership. You're not helping—you're building.
  • Technical impact: Direct influence on architecture decisions (Xvfb strategy, master/slave topology, routing patterns).
  • Permanent credits: Your name in the core system and visibility on the official platform.
  • Direct access: 1:1 collaboration with founder on milestone definition.

  How to Join We are looking for experts to define the pro-audio Linux standard. If you are ready to contribute, CONTACT US follow these steps:

  1. Review the Technical Docs: https://github.com/Open-Live-Mixing-System-OLMS/Open-Live-Mixing-System/tree/main
  2. Visit the Project Site: https://openlivemixingsystem.org/
  3. Join the Discussion: https://t.me/openlivemixingsystem

  If you understand why we're isolating cores via taskset, how to manage IRQ affinity for USB controllers, and why DMA latency=0 is critical to avoid xruns under load—you're exactly who we're looking for.

• ​POC1.0​ release!

  Francesco Nano • a day ago • 0 comments

  Hello everyone! I just released the POC1.0 version. Please have a look. In the next days i'll send a couple of tutorial and screenshot. I would need help for testing on your devices to see if we get comparable results.

  https://github.com/Open-Live-Mixing-System-OLMS/Open-Live-Mixing-System/releases/tag/POC1.0

  Thank you for being with me and helping and supporting!
  Francesco Nano

• Still debugging the startup

  Francesco Nano • 5 days ago • 0 comments

  Hello everyone! I'm in the middle.of hard debugging of my launcher script. It worked when everything was hardcoded (user, path..). Since when I tried to make it universal I found several issues. So with gigantic patience.. I'm on it in the last 3 days. I hope to let you know news as soon as possible. When my script will be ready you'll be able to launch it on your PC and test by yourself the latency and engine resilience. Then we'll move forward to other pieces of this project. Please let me know you are here, reading and waiting for upcoming news!

  PS; please e support this project helping me bringing the right people into my telegram official channel:

  https://t.me/openlivemixingsystem
  
  And the developing community;

  https://t.me/openlivemixingsystemchat 

• audio engine startup is working!

  Francesco Nano • 02/05/2026 at 13:29 • 0 comments

• Startup process close to the goal

  Francesco Nano • 02/03/2026 at 23:43 • 0 comments

  Hi guys, I'm keep working hard on the audio engine startup process. It's very difficult because I'm going di do it avoiding systemd and trying to do everything on a started and running machine.

  The main challenge is we have 3 pieces which have to run together but with different privileges and starting users.

  Asla, jack and ardour.

  Very technical issues and solutions. In true I don't know exactly everything. The main part is AI driven. I'm the ai chief. I'm like a music producer that feels music but isn't able to explain musicians what to do because he's not understanding music theory, chords, and so on...

  I know what I want but I have no idea how to reach it. A lot of time is invested onto fails and bad ways.. make, come back, try again.

  Some times things goes right, after 1 minute anything is working anymore.

  Anyway... I'm at99% of a really important piece of this work: startup process running to start asla, jack and ardour all together in a very high performance high tuned machine.

  This assure ardour will run in a real time kernel in the best way possibile to match live low latency mixing needs with a standard PC. 

  I'm going to keep working alone till the POC will be closed. Then for sure I'll need some help from you guys.

  All the best and thank you for support.

• Very high frustration level

  Francesco Nano • 02/01/2026 at 16:37 • 0 comments

  Audio engine startup seems working but... Isn't!! 😲🤬😡🤬

• OLMS Core Refactoring: Modular Architecture and Enhanced Launchers

  Francesco Nano • 01/29/2026 at 07:57 • 0 comments

  A comprehensive refactoring of the Open Live Mixing System (OLMS) Core scripts by implementing a modular architecture with enhanced launcher capabilities for both development and production environments.

  Key Improvements

  1. Modular Script Architecture

  Before: Monolithic scripts with unclear responsibilities

  After: Hierarchical, modular architecture with clear separation of concerns

  New Script Structure:

  olms-startup.sh (Main Coordinator)
  ├── Phase 1: rt_tuning.sh
  ├── Phase 2: irq_pinning.sh  ├── Phase 3: prepare_machine.sh [args]
  │   ├── Phase 1: rt_tuning.sh
  │   ├── Phase 2: irq_pinning.sh
  │   └── Phase 3: olms-apply-affinity.sh
  └── Phase 4: audio_engine.sh [args]
  

  2. New Specialized Scripts

  irq_pinning.sh - Hardware IRQ Pinning

  • Detects audio hardware and identifies IRQ numbers
  • Pins audio card IRQs to dedicated CPU cores
  • Configures IRQ affinity for optimal audio performance
  • Verifies IRQ pinning configuration

  olms-apply-affinity.sh - CPU Affinity Configuration

  • Sets CPU affinity for audio processes (JACK, Ardour)
  • Configures process priorities (nice/renice values)
  • Allocates dedicated CPU cores for audio processing
  • Verifies CPU affinity settings

  disk_guard.sh - Disk Space Monitoring

  • Monitors disk space on critical paths (/var, /tmp, /home)
  • Provides warning and critical thresholds (configurable)
  • Performs automatic cleanup of temporary files and logs
  • Runs as a background service for continuous monitoring

  3. Enhanced Launcher System

  Launchers Directory Structure:

  scripts/launchers/
  ├── olms-test-launcher.sh     # Development/testing environment
  └── olms-prod-launcher.sh     # Production/headless environment
  

  Test Launcher Features:

  • GUI-enabled startup for development and debugging
  • Comprehensive system verification
  • Verbose output and monitoring capabilities
  • Detailed error handling and status reporting
  • Development environment instructions

  Production Launcher Features:

  • Headless operation for automated performance/recording
  • Optimized startup sequence for live environments
  • Minimal user interaction required
  • Production-focused monitoring and logging
  • Resource optimization for stable operation

  4. Desktop Integration

  New Desktop Shortcuts:

  • OLMS Test Launcher: Icon applications-multimedia for development
  • OLMS Production Launcher: Icon applications-system for production
  • Direct access to appropriate startup modes
  • Clear visual distinction between environments

  5. Documentation and Synchronization

  Updated Documentation:

  • SCRIPTS_IMPLEMENTATION_SUMMARY.md: Complete architecture documentation
  • OLMS_specs.md: Updated with new script references and architecture
  • Clear usage examples for all scenarios
  • Synchronization guidelines for systemd services

  Systemd Service Integration:

  • Updated ardour.service to use audio_engine.sh
  • Synchronized script paths and parameters
  • Maintained compatibility between testing and production

  Architecture Benefits

  Separation of Concerns

  • Each script handles a specific aspect of system preparation
  • Clear boundaries between development and production workflows
  • Independent testing and debugging capabilities

  Flexibility and Reusability

  • Scripts can be used individually or in combination
  • Modular design allows for easy customization
  • Clear upgrade path from development to production

  Enhanced Error Handling

  • Comprehensive error checking at each phase
  • Graceful fallback mechanisms
  • Detailed status reporting and logging
  • Clear error messages for troubleshooting

  Development Workflow Optimization

  • Dedicated test launcher with GUI support
  • Verbose output for debugging and monitoring
  • System verification and health checks
  • Development environment instructions

  Production Readiness

  • Headless operation for automated environments
  • Optimized startup sequences
  • Resource monitoring and management
  • Minimal user interaction requirements

  Usage Examples

  Development Environment:

  Bash

  # Launch in testing mode with GUI
  ./scripts/launchers/olms-test-launcher.sh
  
  # Launch with verbose output for debugging
  ...

  Read more »

• Auto codec usb detecting

  Francesco Nano • 01/28/2026 at 10:34 • 0 comments

  I'll make the script intelligent to automatically detect the USB audio codec and use dummy as fallback, plus add session cleanup functionality.

• Fighting with test graphic interface

  Francesco Nano • 01/28/2026 at 08:39 • 0 comments

  Trying to open Ardour in my Ardour Laucher script

• ACK Backend Issues Identified and Tested

  Francesco Nano • 01/27/2026 at 21:06 • 0 comments

  We are currently focusing on the audio core, specifically the JACK audio server integration and the automatic hardware detection system. While the detection logic is solid, testing has identified critical backend compatibility issues.

  ⚠️ Identified Issues

  1. JACK Dummy Backend Incompatibility

  • Problem: The dummy backend (used for virtual audio) does not support the -S (server name) parameter.
  • Root Cause: The script incorrectly attempts to pass server-naming arguments to a backend with a limited parameter set.
  • Error Log: JACK command: jackd -d dummy -S olms_dummy -r48000... Unknownage with option 'S'

  2. Persistent JACK Server Sockets

  • Problem: Socket files persist even after cleanup, blocking new instances.
  • Root Cause: Current cleanup routines fail to clear all system resources (sockets/semaphores) across multiple locations.
  • Status: ❌ Failed after 5 cleanup attempts in testing.

  3. Audio Hardware Detection

  • Status: ✅ FUNCTIONAL
  • Result: Correctly identifies and prioritizes USB devices, built-in codecs, and loopback devices.

  📊 Testing Summary

  🛠️ Technical Implementation Progress

  Completed Work:

  • Intelligent Detection: Automatic codec identification with conflict management.
  • Priority Logic: USB Audio → Built-in Audio → Loopback → Virtual.
  • Service Management: Temporary suspension of PulseAudio to avoid hardware locks.
  • Optimization: Dynamic buffer and sample rate configuration.

  🚀 Next Steps & Resolution Plan

  1. Refactor Dummy Config: Remove -S from dummy backend launch strings.
  2. Aggressive Cleanup: Expand the script to purge /dev/shm and all known JACK socket paths.
  3. Resource Handling: Improve management of shared memory segments.
  4. Final Validation: Re-run full test suite across all three modes.

  Conclusion: The core logic is sound. Once the JACK-specific technical hurdles (parameters and cleanup) are cleared, the system will be ready for operational use.
  
  

View all 12 project logs