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

131–140 of 165 posts

Re: Elk OS – Audio Operating System

#131

Post by vnorilo »

tgv wrote: post #85
Scramblejams wrote: post #53

Earlier quoted context omitted.

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.

I can deal with 10ms roundtrip, but not much more.

One issue is when you get some acoustic sound too (open headphones, bone conductance, singing) and pretty much any delay in the headphone signal causes phase interference.

Re: Elk OS – Audio Operating System

#132

Post by snvzz »

kbumsik wrote: post #72
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.

No. Soft real time can miss some real time deadline. AFAIK Linux RT kernel is designed to hit every deadline, but they just cannot offer a formal proof. So "more-or-less" hard real time.

>AFAIK Linux RT kernel is designed to hit every deadline, but they just cannot offer a formal proof.

And that's why it is soft realtime. No guarantee, no hard realtime. It really is that simple.

Re: Elk OS – Audio Operating System

#133

Post by snvzz »

colonwqbang wrote: post #93
ComputerGuru wrote: post #80

Earlier quoted context omitted.

One of the problems is that the Linux RT kernel doesn’t stop you from using/writing devices/drivers that break those guarantees systemwide, as I understand it.

What kernel can give such a guarantee?

seL4[0]. I'm not aware of any other.

[0]: https://sel4.systems/

Re: Elk OS – Audio Operating System

#134

Post by vnorilo »

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 played with Bela [1] which uses the same real time kernel IIUC. It had super stable audio performance down to a 2 sample buffer, which felt like programming hardware. I'm very happy to see more work in this field.

1: https://bela.io/

Re: Elk OS – Audio Operating System

#135

Post by rjmunro »

follower wrote: post #110
LeoPanthera wrote: post #42

Earlier quoted context omitted.

It certainly was, yes. The BBC Micro had an optional hardware speech synth you could add, but it was very inflexible, limited to a fairly small set of pre-defined words. "Speech!" could render arbitrary phonemes which make it a lot more flexible.

Flexible enough to say the word "Citadel!" for example. :)

You can try it in your browser; Go to https://bbc.godbolt.org/?&disc1=sth%3ASuperior%2FSpeech.zip, then copy and paste this to the paste thing at the top right:

SPEECH SAY Hello *SAY How are you?

Re: Elk OS – Audio Operating System

#136

Post by twic »

1vuio0pswjnm7 wrote: post #121
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

Is it possible to make a BSD kernel real-time. (No, IIRC.) I notice Elk uses Xenomai. NetBSD has a utility called schedctl that purports to control the scheduling of threads and processes. An example in the manpage describes running top(1) with "real-time priority". https://man/netbsd.org/schedctl.8 The ability to compile a (close to) real-time kernel seems to be one difference between Linux and BSD not often discuss…

The approach of making general-purpose OS kernels realtime seems like hard work to me. Surely what we want is a realtime microkernel, on which the conventional operating system can run as a (large!) task. As long as there is a way for processes running under the kernel to start realtime tasks directly on the microkernel, you can support all your realtime use cases, without having to make the whole operating realtime.

Re: Elk OS – Audio Operating System

#138

Post by pohl »

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?

In consumer audio, you produce the sound and you're done. In devices used for musical performance, you produce audio, which then feeds into the brain of a musician, who then makes an decision to change their behavior in response to what they're hearing, which then effects the audio. Those constant round-trips through the brain make it very easy to notice latencies. (They pull you out of "the zone".)

Re: Elk OS – Audio Operating System

#139

Post by tgv »

vnorilo wrote: post #131
tgv wrote: post #85

Earlier quoted context omitted.

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.

I can deal with 10ms roundtrip, but not much more. One issue is when you get some acoustic sound too (open headphones, bone conductance, singing) and pretty much any delay in the headphone signal causes phase interference.

Yeah, I have to add that for me 40ms is ok when playing a virtual instrument.

Did you ever see people who try to sing with headphones with a delay of around 200ms? That really messes up your performance.

Re: Elk OS – Audio Operating System

#140

Post by boomlinde »

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?

> Assuming headphones and instrument/vocal mics that are within a few inches

It is relevant, and monitoring via headphones or a floor speaker is a mitigation.

It's also a problem for large orchestras. If everyone else just plays along with what they hear from the people near them, the timing is going to be inconsistent across the orchestra pit even if you have some obvious audible reference like loud percussion. The mitigation is to orient yourself as much as possible around the visual cues from a conductor.

Post reply on HN