Hacker News Reader

Comment by yobbo | Hacker News Reader

It depends on the application. More serious music applications have separate "render mode" which works in non-realtime. Also "real-time" apps will use a rendering buffer of say 100 ms. Someone would need to benchmark how small the buffer needs to be for RT to matter.

Time-resolution for midi-input is not high enough for it to matter; it will be quantized to midi-time anyway.

It is critical for audio-effects and synthesizers that are taking live input and emitting live output. These exist, but I'm not sure they are commonly used on linux or if it's wise running with low resources.

View on HN

> More serious music applications

I don't understand this perspective. I've seen musicians at all levels use all sorts of crazy instruments. The output of live audio processing may not be used in the final result, but it's very important for capturing a performance.

> not sure they are commonly used on linux or if it's wise running with low resources

Linux-based studios are the norm for many hobbyists and in educational settings where the goal is actually teaching and not just indoctrinating a new cohort of commercial software users. Also, who said anything about "low resources" and what does that even mean?

Linux-based studios are the norm for many hobbyists?

I don't think so. And what does that even mean?

There are some hobbyists using Linux for music production. But it's so far behind MacOS and Windows in that regards, that no sane person would use it for any other reason than prefering free software or using some esoteric piece of software that's only available on Linux.

I wish it was different, because than I could ditch Windows and move to Linux full stop.

100ms is too much. That's almost 1/16th at 120bpm. Anyone multitracking would try to use at most a 256 sample buffer, which gives a 6ms (extra) latency.

Yes, but you can set a heavy project to say 4096 samples (which is then 96ms) when playback latency doesn't matter.

Sound travels about 2m in 6ms. Iirc, it's difficult for humans to perceive time differences smaller than 20ms, so humans perceive sounds from within a radius of 6m simultaneously.

When my own voice arrives at my head 20ms late, my pitch performance suffers, as well as comfort. It feels very weird.

When playing an instrument, I can live with a 20ms roundtrip.

I don't care about playback performance. I usually have my playback buffers at 512 samples, but I could easily deal with 1024 samples.

I can believe that feels weird. That delay is like listening to the sound picked up from a directed mic 6m from your head.

> or if it's wise running with low resources.

It's not really a matter of how many resources a system has, without proper realtime scheduling a thread might still be randomly delayed for just a few milliseconds too many due to scheduling screwups.

Yes, but that may or may not be important.

For real-time performance, yes; but that doesn't represent the whole, or even the majority, of audio work.

Yes, but I want my DAW to have as much control over the scheduling, not the OS.

I don't want the OS to take away resources from my DAW at any point in time, exactly for the reason to avoid dropouts.

I am talking about realtime performance. I don't want any other process take a slice of my audio software's schedule.

Reply on news.ycombinator.com