Top all-time · #9828
timur.audio
Personal blog · timur.audioprogrammingsystems
timur.audio is a personal blog at timur.audio about programming and systems. Since 2021, 8 different Hacker News readers have linked it 8 times, most often “Locks in real-time audio processing”. It is still writing: the last post was on 2025-01-30, and you can follow it by feed.
Too few sampled comments (3) to say how often HN recommends it.?
Why HN links it
HN readers link timur.audio for its posts on real-time audio programming, especially locking and lock-free techniques, and a C++17 initialization chart. The comments cite the posts as sources and one calls a video series good.
Summarised by Claude from a sample of 3 HN comments that link here. Each comment is marked recommending, critical or neutral (citing without judging); how this works.
Most-linked posts?
- Locks in real-time audio processing3 people · 3 mentions · first linked 2022-11-20
- Contracts for C++ explained in 5 minutes2 people · 2 mentions · first linked 2025-01-30
What Hacker News says?
In a similar vein: I've had the "initialization in C++17" chart taped above my desk for a 3 years now[1]. [1]: https://timur.audio/initialisation-in-c17-the-matrix
Comment linking /initialisation-in-c17-the-matrix
on “C++ Cheat Sheets”Submitted dbl-word atomic cmpxchg that your CPU can do but your compiler won't as a story · 39 points
HN discussionGood set of videos. Here is the article version of the first: https://timur.audio/using-locks-in-real-time-audio-processin... The insight is that with two threads contending on one lock, there are efficient ways to build the lock that minimizes cpu on the non-realtime thread.
Comment linking /using-locks-in-real-time-audio-processing-safely
on “Real-time audio programming 101: time waits for nothing (2011)”Submitted How to make a container from a C++20 range as a story · 3 points
HN discussionIf putting the thread to sleep would be the problem, simple try_to_lock instead of blocking would be the solution. In practice, it looks like releasing the lock and potentially waking up threads that were blocking on it is another problem ( https://timur.audio/using-locks-in-real-time-audio-processin... ) For what it's worth, on macOS profiling audio apps shows that the OS itself is using mutexes on audio thread and…
Comment linking /using-locks-in-real-time-audio-processing-safely
on “An Introduction to Lockless Algorithms”Submitted Locks in real-time audio processing as a story · 2 points
HN discussionSubmitted Contracts for C++ explained in 5 minutes as a story · 1 points
HN discussionSubmitted Contracts for C++ explained in 5 minutes as a story · 1 points
HN discussion
