Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elk OS – Audio Operating System

elk.audio

Post reply on HN
Print view View original

81–90 of 165 posts

Re: Elk OS – Audio Operating System

#81

Post by ComputerGuru »

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?

The latter. The point being that they are trained, comfortable, and proficient in those scenarios and the same translates to a (consistent!) software delay of up to 10ms.

Re: Elk OS – Audio Operating System

#82

Post by jeffreygoesto »

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.

Right. Also for hard realtime with 100% deadline guarantees (absence of soft and programming errors assumed, for a second) you would choose an appropriate CPU like the ARM Cortex-R series. You'd also take care of the peripherals, i.e. choose 801.2AS or even Flexray.

Re: Elk OS – Audio Operating System

#83

Post by scns »

spicybright wrote: post #54
moonchild wrote: post #31

Earlier quoted context omitted.

That's necessarily going to be aspirational in at least some respects, though—it's limited by the hardware.

I wonder if there's a way for computers to self-measure round trip. Even if you have to plug an aux cord between the speaker + mic jacks.

That is the way to do it. In Ardour it is part of the audio setup.

Re: Elk OS – Audio Operating System

#84

Post by redconfetti »

hsbauauvhabzb wrote: post #29
jancsika wrote: post #6

> 1ms round-trip Ooh, a rare latency claim that actually specifies which type of latency they mean! One millisecond round-trip latency, if true in practice, is quite impressive. I'm going to continue reading now... :)

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?

If you're trying to play along with something, synchronizing with the beat, the latency will completely destroy your ability to get into the grove right if what your playing is heard with a delay.

Re: Elk OS – Audio Operating System

#85

Post by tgv »

Scramblejams wrote: post #53
tigeba wrote: post #37

Earlier quoted context omitted.

It only takes a small amount of latency (5 ms or so) to noticeably impact performances by musicians. Latency is also an issue when you want to monitor a live signal along with other recorded audio, like in a DAW. It is not as big a deal with a playback only device.

Interesting, I wouldn't have expected it to be that low, though in the aircraft space, control harmony can be disrupted with as little as 20ms of delay between control input and control surface movement[0]. Do you have any research you can suggest for that 5ms number? [0] http://www.klabs.org/history/history_docs/reports/dfbw_tomay... (Keeping the delay at or under 10ms was the recommendation I got from the study P.I…

It's not that low. Up to 40ms (roundtrip) isn't a problem for solo playing, in my experience. And it's also a matter of training. Church organists learn to play with much larger delays.

Re: Elk OS – Audio Operating System

#86

Post by viraptor »

PaulDavisThe1st wrote: post #71
viraptor wrote: post #65

Earlier quoted context omitted.

If anyone wants to try the as-much-rt-as-possible build in a nice ready package, there's the Xanmod project https://xanmod.org/ which offers it precompiled with a few other tweaks. It's aimed at gamer crowd, but I had a really good experience using it with music processing.

The default xanmod kernel is still not using the PREEMPT_RT features. They do note that "Real-time Linux kernel (PREEMPT_RT) build available [5.10-rt]." and that's how you get "as much RT as possible". The features in the normal version of their kernel will improve the user experience of latency, but will not address "realtime" in the way that PREEMPT_RT does.

Correct, the 5.12 versions don't have the PREEMPT patches, you'll need the 5.10-rt version.

Re: Elk OS – Audio Operating System

#87

Post by yosamino »

phlakaton wrote: post #36
protoman3000 wrote: post #4

It’s a Linux distribution with real-time kernel. Here’s a download link if anybody is interested: https://github.com/elk-audio/elk-pi/releases

When I read things like this, I really wish BeOS, with its already pervasively multithreaded kernel, had won the audio OS wars. _Le sigh._

It's a bit weird but I have such a nostalgic connection to this very specific BeOS ability.

As a teenager I had heard about BeOS and I tried it out. I must have gotten it from a magazine's CD.

And by mistake, clicking around, I opened all of my mp3 collection's files at the same time. Each of the mp3s opened in their own little player window - and they all started playing at the same time, without the UI starting to lag at all.

It gave me an appreciation of what a computer can do

Re: Elk OS – Audio Operating System

#88

Post by gmueckl »

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…

And latencies add up when chaining hardware: 1ms for the effect pedal, 1ms for the amp, 1ms for the audio interface, etc..

Re: Elk OS – Audio Operating System

#89

Post by jcelerier »

snvzz wrote: post #58
PaulDavisThe1st wrote: post #19

Earlier quoted context omitted.

Almost all of the original PREEMPT_RT patchset are mainlined now, but the features are not (all) enabled by default. Low latency will always present a tradeoff with bandwidth, and Linux is used for so many different purposes that one is not clearly more important than the other. For more than 10 years, Linux with the PREEMPT_RT patch has been capable of more-or-less hard real time, with latencies in the 10's of usecs…

>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.

Linux has the ability of entirely freeing a few CPU cores with isolcpus though, so that you can implement your own real-time loop on it

Re: Elk OS – Audio Operating System

#90

Post by jcelerier »

ssfrr wrote: post #63
tigeba wrote: post #37

Earlier quoted context omitted.

It only takes a small amount of latency (5 ms or so) to noticeably impact performances by musicians. Latency is also an issue when you want to monitor a live signal along with other recorded audio, like in a DAW. It is not as big a deal with a playback only device.

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.

Most musicians use headphones / earplugs in professional settings
Post reply on HN