14 ms·
Elk OS – Audio Operating System
- uvesten 5y agoLooks cool! …but what is it? Software, hardware or both? (And is the software part a Linux distro with a tweaked kernel?)
- protoman3000 5y agoIt’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 https://github.com/elk-audio/elk-pi/releases
- matheusmoreira 5y agoSo the real time kernel patches have been mainlined? How comprehensive are the real time features of Linux now?
- PaulDavisThe1st 5y agoAlmost 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 range. That can be thwarted, however, by a variety of hardware features (SMI being the worst offender, plus devices that hog the PCI bus for too long), so you are not guaranteed this performance just by running that kernel.
- zamadatix 5y agoDumb question inbound are those features boot/runtime toggable or compile time options?
- PaulDavisThe1st 5y agoCompile time.
- snvzz 5y ago>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.
- PaulDavisThe1st 5y agoEven 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.
- jeffreygoesto 5y agoRight. 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.
- zurn 5y ago100% handled with N*2 would be hard realtime.
- kbumsik 5y agoNo. 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.
- vinkelhake 5y agoElk is using Xenomai, it's not just PREEMPT_RT. https://elk.audio/audio-latency-demystified-part-ii/ https://elk.audio/audio-latency-demystified-part-ii/
- phlakaton 5y agoWhen I read things like this, I really wish BeOS, with its already pervasively multithreaded kernel, had won the audio OS wars. _Le sigh._
- andai 5y agoDoes Haiku share these qualities?
- doublerabbit 5y agoYes.
- yosamino 5y agoIt'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
- pjmlp 5y agoNot only because of that, being fully written in C++ and multimedia oriented, for me it had a feeling of second coming of Amiga. Oh well.
- fierro 5y agowhat is a real time kernel vs a normal kernel? just "faster"?
- mutagen 5y ago'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 https://wiki.archlinux.org/title/Realtime_kernel_patchset
- jmiskovic 5y agoArch 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.
- froh 5y ago"graybeard forums" = ?
- jmiskovic 5y agoI'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.
- froh 5y agoah so grey haired as in experienced people think John Maddog Hall. got it. thanks.
- 5y ago
- 1vuio0pswjnm7 5y agoIs 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 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.
- crest 5y agoFreeBSD includes a realtime scheduler priority class (round robin per priority level).
- twic 5y agoThe 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.
- cmiller1 5y agoInteresting, I was actually looking into distros set up for audio recently because I was hoping to build a little jukebox r-pi or similar but noticed you'd have to recompile the kernel on the official pi distro to get full support for high-resolution audio
- PaulDavisThe1st 5y ago"high resolution audio" is a bit of a weasel phrase. My RPi4 is quite happy doing what any audio engineer would consider "high resolution audio", no kernel recompile required.
- cmiller1 5y ago192 khz/24 bit
- deleted 5y ago[deleted]
- PaulDavisThe1st 5y agoJust put a hifiberry card in there. Done.
- cmiller1 5y agoI already have a DAC that can do it, but I was hesitant about trying to use the pi after seeing this forum thread https://www.raspberrypi.org/forums/viewtopic.php?t=25810 https://www.raspberrypi.org/forums/viewtopic.php?t=25810
- PaulDavisThe1st 5y agoThat thread is rather old, and seems to be concerned with using HDMI, which I don't think anyone concerned about high resolution audio should be doing. The last comment confirms "working fine" back in 2013, more than 7 years ago.
- jancsika 5y ago> 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... :)
- deleted 5y ago[deleted]
- hsbauauvhabzb 5y agoI’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?
- p1necone 5y agoDifferent use case - consumer gear is generally only used for listening to recordings, whereas professional gear is often used for real time recording of someone who's playing an instrument while listening to the output.
- tigeba 5y agoIt 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.
- Scramblejams 5y agoInteresting, 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_tomayko.pdf 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.)
- snvzz 5y agoSo basically linux-rt + jack. I have that already.
- ctoth 5y agohttps://news.ycombinator.com/item?id=8863 https://news.ycombinator.com/item?id=8863
- slownews45 5y agoHahah.. Funny to see this same comment about dropbox ($10B company)
- snvzz 5y agoThe same Dropbox that once had a broken login form where a blank password let people in to any account? Somebody's effort being successful isn't necessarily a good thing. See Facebook.
- slownews45 5y agoBut it illustrates that "that's easy" or "I can do that by setting up Linux with an X and Y and router rules Z and a dynamic IP Q" isn't the same as user friendly and isn't a bar to commercial success.
- snvzz 5y agoWhy is everything about commercial success? As for easy, this is generally achieved by installing the relevant packages, in whatever distribution you're using. True for at least Debian, Ubuntu, Arch.
- mastrsushi 5y ago"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 you can dream that compatibility allows more open platforms, but we all know hardware companies always end up making the end product proprietary anyway. To be fair, I don't know a lot about hardware. I'd also like to guess that the world of music electronics has been longing for some sort hardware medium to sort out the mess of obscure ISA's and poor documentation that hardware engineers have to put up with.
- InitialLastName 5y agoI 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, incomprehensible instruction pipelines, assembly code, and (as you say) poor documentation. Moving to ARM, GCC/LLVM support, and (eventually) Linux makes all the things other than making neat sounds (UI, interconnect, networking, power management, etc) easier, so that developers can spend more time on the creative bits.
- pjmlp 5y agoLooking 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.
- InitialLastName 5y agoThere'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).
- ssfrr 5y agoReminds me a lot of the Bela project [1]. The idea is that they expose the raw audio device interrupt handler so applications can do DSP processing without the kernel being involved at all. Wonder if this is doing something similar? [1] https://bela.io/ https://bela.io/
- PaulDavisThe1st 5y agoBela does not expose the audio device interrupt to applications. Your code runs in the Xenomai RT kernel, which functions somewhat like a hypervisor. That means that your RT code doesn't run as part of Linux at all. It also means that you need to use Xenomai-specific techniques if you need to communicate with regular Linux application code. You'd get more or less the same thing by writing a kernel module for Linux, which would also have to use somewhat specialized techniques for interacting with user space application code.
- ssfrr 5y agoI stand corrected - thanks for the clarification.
- nitrogen 5y agoCookie consent by scrolling doesn't seem like a legitimate way to obtain user consent.
- casmclas 5y agoI mean, it's no worse than the standard antipatterns, which are designed to be so easy to click "accept" and so hard to follow the "don't accept" flow. None of them are about coming to an agreement with the user; all of them are about obtaining as much data as possible. Until the EU mandates a handwritten letter to obtain permission for tracking cookies, these demonstrations of bad faith will be our friends on the internet.
- henryackerman 5y agoI just hit agree and let my browser extensions handle the rest by blocking tracking cookies.
- MisterSandman 5y agoThis is awesome, this has been one of my bucket list projects. Audio on most devices sucks \.
- dokem 5y agoCould I use this with PTP clock synchronization to create my own wireless speakers?
- PaulDavisThe1st 5y agoElk seems to be pushing the RPi as the h/w platform. You will likely have a difficult time finding an RPi with an ethernet chipset capable of correctly doing PTP.
- dokem 5y agoI don't think you need the sub-microsecond resolution PTP compatible PHYs offer. I was hoping to get away with software timestamping which I believe should still give you sub ms synchronization. My real question, I guess, is how in sync do the speakers need to be? Just on the order of human perception, or do we need them to be in phase?
- PaulDavisThe1st 5y agoI have some aging Slim Devices units in my house system that I've been contemplating replacing with a custom system. However, I would just use wifi to an RPi with a suitable DAC installed. There'd be no per-speaker sync, since the DAC->speaker connection is analog, and before the DAC there'd be essentially streaming code that would always be handling both channels.
- andrewflnr 5y agoWhen I saw the headline, I wondered/hoped if it was an OS with an audio/only UI. I'm sure this is cool, but a fully thought-out audio-only UI would be fascinating.
- LeoPanthera 5y agoI started developing a blind computing system in the late 80s based on a BBC Micro and a very early speech synthesizer. It never went anywhere, and I'm no longer in contact with the blind friend who was helping me, but I often wonder if today's solutions such as Apple's Voiceover aren't the ideal solution. They seem to be trying to adapt the GUI for the blind, rather than trying to build a text/voice based system from scratch, like I was doing. Siri / HomePods and similar appliances are getting there, I suppose, but they still feel like computing accessories, rather than fully fledged computers themselves.
- mwcampbell 5y agoAs a legally blind developer who has worked on accessibility for a while (see my HN profile for more), I'm inclined to agree with you. We use screen readers like VoiceOver because, practically, we often need to access mainstream applications. But I think we tend to get too dogmatic about going mainstream, to the point that some of us are disdainful toward systems designed specifically for blind people, particularly if they involve custom hardware. I've thought about developing a Linux desktop environment with a shell that's designed specifically for TTS, but that also includes a more conventional screen reader for running GUI applications. Do you remember which speech synthesizer you were working with in the 80s?
- LeoPanthera 5y agoYes it was a software synthesizer called "Speech!" by Superior Software, blown into a ROM.
- mwcampbell 5y agoAh, must have been a BBC Micro-only thing, because I never heard about it.
- senbarryobama 5y agoWhy wouldn't someone use FreeRTOS?
- PaulDavisThe1st 5y agoAlthough things may change a bit with the arrival of Apple M1 systems, the marketing mentions of VST in this context are fairly weasely. For users, good look finding more than a couple of plugin developers that make their plugins available for (a) a Linux based system AND (b) the ARM architecture. For developers, VST is just an SDK, and doesn't require OS support in any meaningful way. So sure, if you want to create VST(3) plugins for a Linux+ARM platform, you can do that, with or without Elk.
- MrMan 5y agoIts a great project. It's intended to help hardware makers bring pro audio gear to market with less cost and less risk. Not as a retail vst host.
- PaulDavisThe1st 5y agoYeah, it is a great project (though it's not a new idea in any sense). But the positioning of being "endorsed" by Steinberg bothers me, because it means nothing.
- MrMan 5y agoWhy does it bother you? Why not focus on technical substance. It’s not a new idea but if you explore the project you will say many excellent features. The fact that there is a raspberry pi based dev board is simply to speed adoption and provide a reference implementation. It’s an excellent project.
- fit2rule 5y agoNo need to bother, LV2 is well supported by a growing mass of developers, and work very well together in, for example, ZynthianOS: https://zynthian.org https://zynthian.org
- dimovich 5y agoOne such project is REAPER. It includes a lot of useful VST plugins. https://www.reaper.fm/download.php https://www.reaper.fm/download.php
- twobitshifter 5y agoI remember Ubuntu studio being geared towards musicians. Does Elk have its own proprietary components? I noticed that the raspberry pie image is noted as open source but not the OS in general. https://ubuntustudio.org/tour/audio/ https://ubuntustudio.org/tour/audio/
- michaelpb 5y agoLooks like it uses a "Yocto" script - https://github.com/elk-audio/elkpi-sdk https://github.com/elk-audio/elkpi-sdk - https://www.yoctoproject.org/ https://www.yoctoproject.org/ I thought of Ubuntu Studio as well, but it looks like Elk is intended to be more lower-level / for appliances. I'm not totally sure though, but I'm guessing it doesn't come with the full suite of Ardour etc. I do wish there was something like Ubuntu Studio, except focused on audio-only (and more polished / supported). Mostly just because JACK + low-latency kernels are an ordeal to set-up and maintain on a normal desktop, so it's much easier to just install a pre-configured distro on a studio computer and be ready to jam whenever inspiration strikes. Unfortunately KXStudio as a separate distro isn't around any more. I still use a KXStudio 14.04 install on an old (airgapped) DAW computer.
- Namidairo 5y ago> Mostly just because JACK + low-latency kernels are an ordeal to set-up and maintain on a normal desktop I wouldn't call linux-rt from the AUR too hard to install, but I can see how it would be a pain for someone who just wanted to pick up their software and do their thing without a long setup. (Since there would probably be more things to setup aside from just the realtime kernel)
- michaelpb 5y agoYeah, JACK / ALSA / PulseAudio is probably the harder thing to straighten out, and if you are using the computer in normal usage as well switching back and forth is a perpetual head-ache filled with edge cases and incompatibilities. A turn-key audio-only OS like what KXStudio 14.04 was truly perfect for pro audio, since it had Ardour + 100s of plug-ins and tools all pre-installed and configured.
- neolog 5y ago> Working with our 5G partner Ericsson, Elk will open up completely new products and network services to connect musicians and equipment remotely over the internet in real time. This seems difficult. What is the 5G latency chain like in practice?
- cahooon 5y agoMy guess is that they don’t mean audio.
- wmwmwm 5y agoI think they do - 5G seems to have the prospect of some realtime low latency guarantee features (though I don’t think it’s rolled out yet). With this in place and an RT audio device you could build an all in one remote jamming box without having to insist on wired internet or deal with the wifi jitter. Currently the user’s network is often the bane of things like Jamulus that try to do this in software + your internet connection
- fit2rule 5y agoMeh. I prefer Zynthian: https://zynthian.org https://zynthian.org Easier to use, and out of the box absolutely crammed with great synth engines and FX plugins and other neat tools to explore. Very easy to use with its standardised interface, also.
- yayr 5y agoIt would be awesome, if they could integrate with an existing AVB network, i.e. just use one network port of the device as AVB port
- conradfr 5y agoIf 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 :)
- atoav 5y agoThe 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/ http://wesaudio.com/_prometheus/>
- conradfr 5y agoThat'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.
- haywirez 5y agomix:analog do that: https://mixanalog.com https://mixanalog.com
- capableweb 5y ago> 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.
- conradfr 5y agoYes, I also know about Chase Bliss pedals, I think they use midi. It's been done but it's not really "mainstream" and standardized. Imagine a standard where all your pedals etc can be recalled / automated from another (central) unit, with a protocol that the hardware can adapt to, motorized faders, rotary faders with leds, or basic components etc. Maybe that's what Wes Audio is doing with the gcon protocol that has been linked below.
- croon 5y agoI haven't looked around very much, but getting VSTs on something other than a desktop DAW has been something I've wanted for a while, to enable audio from a dumb keyboard, Without a dedicated (limited) synth or a full desktop/laptop. This looks like it supports it on an RPi, which is great! I'll have to look into this.
- matthew_kuiash 5y ago1 sample latency or it didn't happen.
- ajxs 5y agoI 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.
- capableweb 5y ago> - 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.
- Sebb767 5y agoCan I use this with commodity audio interfaces? The website does not state that, as far as I could find.