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

121–130 of 165 posts

Re: Elk OS – Audio Operating System

#121

Post by 1vuio0pswjnm7 »

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

Re: Elk OS – Audio Operating System

#122

Post by ajxs »

I don't work in the industry this OS is marketed towards. I do however have some experience in embedded development and synthesiser programming. Can someone more familiar with the field answer a few questions for me?

- The website says: "With Elk hardware companies can move away from dedicated chips and use general purpose ARM and x86 CPUs without any compromise in terms of latency, performance and scalability". Is this intended as a ready-made OS for hardware synthesisers, or as a way to host VSTs on consumer SoCs?

- Assuming you're not targetting an obscure platform, or have a cumbersome toolchain, is writing a bare-metal executive the most difficult or expensive aspect of engineering a synthesiser? I've done some experiments breadboarding simple synthesisers with Arduino and STM development boards plus a 16-bit DAC. In my case the most challenging aspects weren't getting a real-time executive loop or handling I/O. Mind you, I didn't go as far as implementing a GUI.

- Is real-time Linux not overkill for most synthesisers? From the outside looking in, it looks like it would add more overhead and complexity than solve problems. If your objective is just to host a VST, this might be a decent trade-off. Or maybe if you intend to use high-level languages for the GUI.

Re: Elk OS – Audio Operating System

#123

Post by michaelgrafl »

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?

Not sure what you mean by average consumer gear, but when I'm performing, anything higher than a 15ms round-trip latency is starting to have a negative effect on my ability to play tightly. I can do with more latency, but that's the point where it starts being unsettling or more tiresome.

Re: Elk OS – Audio Operating System

#124

Post by capableweb »

conradfr wrote: post #94

If I get it right this is digital effects controlled by analog controls. Whereas the holy grail of the audio world would be analog effects controlled digitally :)

> If I get it right this is digital effects controlled by analog controls.

Yes, but also more. For me, the greatest feature is the ability of running VST plugins without having to use a full computer/laptop, since my setup doesn't include any traditional computers.

> Whereas the holy grail of the audio world would be analog effects controlled digitally :)

That's been done for a long time already, bunch of Elektron Analog machines does this already, just one example.

Re: Elk OS – Audio Operating System

#125

Post by mixmastamyk »

fierro wrote: post #60
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

what is a real time kernel vs a normal kernel? just "faster"?

"More responsive," is the typical simplified description.

Re: Elk OS – Audio Operating System

#126

Post by tecleandor »

jcelerier wrote: post #116
froh wrote: post #104

Earlier quoted context omitted.

which is interesting but not the point?

But it's in part because of the latency due to the distance to loudspeakers, which isn't an issue with headphones

I think the loudspeaker part was a comparison to understand it a little bit better.

"If the system processing your signal introduces a 20ms delay, it would be the same as standing 20feet away the loudspeaker you're using as reference."

Re: Elk OS – Audio Operating System

#127

Post by capableweb »

ajxs wrote: post #122

I don't work in the industry this OS is marketed towards. I do however have some experience in embedded development and synthesiser programming. Can someone more familiar with the field answer a few questions for me? - The website says: "With Elk hardware companies can move away from dedicated chips and use general purpose ARM and x86 CPUs without any compromise in terms of latency, performance and scalability" . Is…

> - The website says: "With Elk hardware companies can move away from dedicated chips and use general purpose ARM and x86 CPUs without any compromise in terms of latency, performance and scalability". Is this intended as a ready-made OS for hardware synthesisers, or as a way to host VSTs on consumer SoCs?

Seems like both and more.

> is writing a bare-metal executive the most difficult or expensive aspect of engineering a synthesiser?

Likely being a big part of the expense, yes. Obviously the hardware parts being a big chunk of it too, programming the software side of things are also expensive and sometimes makes the product receive less updates in the future because programmers who did understand the platform left the company. See Octatrack as an example, where the code is so complicated it's unlikely to see any bigger features released to it now as the original programmer left the company.

Also, consider that many people have experience with general computing platforms while not having special expertise about particular chips, this solution on a general platform can help more people get started, learn more and maintain their own setups with skills that easily translate as well.

> Is real-time Linux not overkill for most synthesisers? From the outside looking in, it looks like it would add more overhead and complexity than solve problems

Probably, but probably not. Music making is more about having options available and use those in creative ways. Being able to use a general computing platform opens up more options than specially programmed OSes for particular instruments. Being able to revive old synths with new software would be wonderful.

Re: Elk OS – Audio Operating System

#128

Post by crest »

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…

FreeBSD includes a realtime scheduler priority class (round robin per priority level).

Re: Elk OS – Audio Operating System

#129

Post by lloeki »

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?

A kernel alone on a random hardware platform can't, but a kernel and a hardware core that watchdogs and flips the bird at a rt-violating driver+device, sure (I've toyed with VxWorks on devices that work this way).

Usually when you're entering that realm of such requirements, you're rarely talking about off-the-shelf devices.

Post reply on HN