3 ms·
> So at least in this domain I have a hard time seeing how eBPF could practically help realtime scheduling. Right, because jack is a user space collection of p
by MisterTea 7y ago
> So at least in this domain I have a hard time seeing how eBPF could practically help realtime scheduling.
Right, because jack is a user space collection of programs. It's obvious that any real-time or low latency DSP audio processing pipeline would have to be moved to BPF in its entirety.
So yes, BPF would work just fine if a new DAW pipeline was designed to work with in it. User space programs would only function as GUI front ends to load and configure BPF audio modules. This way audio can be sourced or sinked via DAC/ADC devices, disk, and network devices without the user-kernel space latencies.
- PaulDavisThe1st 7y agoYou're never going to fit Ardour's engine into 1M instructions, nor is it going to work without unbounded loops. So that's not going to happen. More interesting would be using BPF for the driver and being able to directly invoke JACK (or some other user-space endpoint) in a way that essentially bypasses the scheduler. Put differently: rather than rely on the normal scheduler pathway to waking up JACK (or some other user-space endpoint), have BPF do it as soon as the device driver is ready. But I don't think BPF has any way to do this at present - it seems to rely on accumulation of data in kernel space and a user space poll-driven process to pick it up and push it at the user.
- jancsika 7y agoDoes the eBPF program need to communicate with userspace? For example, can there be an eBPF "hello world" Dalek modulator that just sits between ALSA's audio input and output?
- PaulDavisThe1st 7y agosure there could, but that's utterly unrelated in practical terms to what i think we're discussing, which is ways in which eBPF could impact full-scale audio software rather than limited inline DSP.