Elk OS – Audio Operating System

Post by froh » Tue, May 25, 2021, 8:01 AM UTC

jmiskovic wrote: post #91

mutagen wrote: post #61

Earlier quoted context omitted.

'real time' generally means latency guarantees and trading some throughput for consistent low latency for interrupts and scheduling. So faster in some dimensions and slower in others. The Arch Linux wiki has some description of their real time patches: https://wiki.archlinux.org/title/Realtime_kernel_patchset

Arch wiki is an amazing source of practical information. It's like graybeard forums but distilled into a readable text. My last laptop ran Mint distro; whenever I searched around for HW issues it was always their wiki, fully stocked with useful info and steps how to fix stuff.

Post by froh » Tue, May 25, 2021, 8:05 AM UTC

jancsika wrote: post #73

hsbauauvhabzb wrote: post #29

Earlier quoted context omitted.

I’ve never understood the latency requirement for professional gear, are you able to articulate why there’s a need for lower latency than average consumer gear?

Three things come to mind-- 1. If you strum the strings of a guitar and want your laptop to make you sound like Jimmy Hendrix, it had better output sound quickly enough that you perceive it happening "immediately." (I.e., it should sound and feel just like an electric guitar that's hooked up to an amp.) 2. Such a laptop like the one above had better make you sound like Jimmy Hendrix for every moment you are playing t…

Post by zurn » Tue, May 25, 2021, 8:13 AM UTC

PaulDavisThe1st wrote: post #70

snvzz wrote: post #58

Earlier quoted context omitted.

>more-or-less hard real time Also known as soft realtime. For hard realtime, you need guarantees. Linux is too complex and cannot possibly offer them; this is the territory of formal proof, with complexity growing exponentially with code size. Look at seL4 for hard realtime.

Even with the "guarantees" offered by e.g. seL4, you still need cooperating hardware. SMIs on most mobos cannot be masked, and can take an eternity to be handled by the BIOS. Fortunately, for realtime audio, you don't need hard realtime unless you're very close to overloading the CPUs. Soft realtime (i.e. 99% of all interrupts handled within N usecs, 100% handled with N*2) is good enough.

Post by simonjgreen » Tue, May 25, 2021, 8:22 AM UTC

mikepurvis wrote: post #67

ssfrr wrote: post #63

Earlier quoted context omitted.

rule of thumb is that sound travels roughly 1ft per ms, so 5ms is the same as standing 5 extra feet from the speaker. Most musicians don't have much trouble up to around 10-20ms. Jitter is killer though - if the latency is randomly changing it's really annoying.

Is the speed of sound relevant in most recording scenarios? Assuming headphones and instrument/vocal mics that are within a few inches, then everything is traveling as electrical signals at the speed of light. Or is this just meant as a visualization of latency in these scenarios versus what it would be like with musicians playing x ft apart from each other in a room?

Post by schroffl » Tue, May 25, 2021, 8:25 AM UTC

mikepurvis wrote: post #67

ssfrr wrote: post #63

Earlier quoted context omitted.

rule of thumb is that sound travels roughly 1ft per ms, so 5ms is the same as standing 5 extra feet from the speaker. Most musicians don't have much trouble up to around 10-20ms. Jitter is killer though - if the latency is randomly changing it's really annoying.

Is the speed of sound relevant in most recording scenarios? Assuming headphones and instrument/vocal mics that are within a few inches, then everything is traveling as electrical signals at the speed of light. Or is this just meant as a visualization of latency in these scenarios versus what it would be like with musicians playing x ft apart from each other in a room?