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

141–150 of 165 posts

Re: Elk OS – Audio Operating System

#141

Post by vnorilo »

tgv wrote: post #139
vnorilo wrote: post #131

Earlier quoted context omitted.

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.

With a virtual instrument you would usually not face the full round trip latency, but rather control latency (MIDI?) and audio output latency (usually 50% of roundtrip). So in the VSTi case that might be closer to 25ms than 40ms in practice. Often the latency jitter is quite dreadful in this case as the control signal is not synchronous to audio.

Re: Elk OS – Audio Operating System

#142

Post by scoutt »

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…

> real-time executive loop or handling I/O

I did some audio implementations on MCUs of all kind, and if I managed to pull out multitracked real-time mixed audio players under 4ms latency, I learn that the real problem here is RAM (other than computing power).

Many audio effects requires lot of RAM. Think of how would you do a 5 seconds delay effect, or good quality pitch shifting (FT and inverse FT), reverb, echo, etc. Before you know it, 128KB of RAM is not enough any more. So now you are dreaming about 128MB of RAM (as minimum).

If you want to process or output audio from/to network, USB or save the output into a file then you have to add that overhead to the equation.

Before you notice it, you'll start looking at small processor like the i.MX28 or the like. Bare-metal BSPs for those processors are quite expensive in terms of code/time. You get what the manufacturer gives to you, and that is, a BSP for Linux.

Re: Elk OS – Audio Operating System

#143

Post by fogihujy »

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.

Yeah, I'm always amazed when I end up looking at the Arch wiki for a Debian issue, simply because the Arch wiki is more relevant and up to date.

Re: Elk OS – Audio Operating System

#144

Post by brandonmenc »

cesaref wrote: post #108
brandonmenc wrote: post #62

Earlier quoted context omitted.

Press a key on a real piano - instant sound. At 10ms (and possibly less), you will start to notice the lag and it will affect your performance. https://www.soundonsound.com/sound-advice/q-how-much-latency...

Nope, you sit 3 or 4 feet from the soundboard in a piano, so the latency is around 3 or 4ms.

The 10ms (or 5ms, depending on the source) is a threshold - under which a human perceives the sound as "instant", even though - yes, physically - it is not actually instant.

Re: Elk OS – Audio Operating System

#145

Post by boomlinde »

mastrsushi wrote: post #11

"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." Less diversity decreases competition and overall technological development. In the 1980s, some OS developers actually blamed Unix for stalling the progress of OS research. Wouldn't a world of Arm based synthesizer be kind of stagnant? Sure y…

> Wouldn't a world of Arm based synthesizer be kind of stagnant?

The computer in a digital synthesizer is an implementation detail to the consumer. What they're buying is the synthesis engine, the way it sounds, performs and interoperates, the case, the user interface etc. In that sense the CPU used seems about as relevant to stagnation as the screw heads used for the case.

Re: Elk OS – Audio Operating System

#146

Post by froh »

jmiskovic wrote: post #119
froh wrote: post #101

Earlier quoted context omitted.

"graybeard forums" = ?

I'm referring to the usenet, mailing lists, various issue trackers and distro-specific forums were knowledgeable people diagnose and solve problems for others. The arch wiki has some of same diagnostics/troubleshooting content in more approachable format and kept up to date. Quite a few times it pointed me in right direction even if I don't use Arch.

ah so grey haired as in experienced people think John Maddog Hall. got it. thanks.

Re: Elk OS – Audio Operating System

#147

Post by snvzz »

jcelerier wrote: post #89
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.

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

Sure. And you can also run an RTOS on a separate chip, elsewhere on the same PCB.

Linux is still Linux, and it is still fundamentally not capable of hard realtime.

Re: Elk OS – Audio Operating System

#148

Post by mikepurvis »

boomlinde wrote: post #140
mikepurvis wrote: post #67

Earlier quoted context omitted.

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…

That's a good point, and I'd imagine instruments like a church organ would suffer from this too, though I know in that case there are a bunch of other sources of delay, like the time it takes for the pipes to fill with air.

Re: Elk OS – Audio Operating System

#149

Post by InitialLastName »

pjmlp wrote: post #115
InitialLastName wrote: post #46

Earlier quoted context omitted.

I work in that industry; at this point most of the big players are on either ARM SOCs or SHARC, with a few plucky folks basically making x86_64 servers. Once performance is comparable for the workload, ARM-based synthesizers aren't inherently any more stagnant than DSP-based synths, in the same way that ARM-based tablet apps aren't necessarily stagnant; if anything, the freedom from crappy compiler lock-in, incompreh…

Looking at other FOSS OS efforts competing against Linux on the hardware space, I imagine that long term it might not be Linux per se, rather POSIX that will win out, with Linux being one among many. I mean stuff like Zephyr, NuttX, mbed, RTOS, Azure RTOS.

There's a range of capabilities for sure, depending on how close you want your device to get to "This is a PC". Mbed, FreeRTOS, and the other small RTOS's are nice for what they are, but their support for more advanced things like multi-core operations, filesystems, multi-tasking and multi-user functions are still limited (and, IMO should remain so as they expand their support for lower-performance devices).

Re: Elk OS – Audio Operating System

#150

Post by conradfr »

atoav wrote: post #97
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 :)

The holy grail would be analog effects controlled digitally with a direct analog control layer. Wesausio would be an example for this [1] [1]: http://wesaudio.com/_prometheus/ >

That's great! I wonder why it's not done more, why there is no kind of standard for this? I looked into it and it's complicated in the electrical side etc, also I guess costs.

Recall time is what forced a lot of professionals to totally move in the box.

Post reply on HN