When do I need a data structure without blocking for reading / writing data by streams in audio applications?

Question

In my scenario, there is something like: The user interacts with the GUI elements, the sound callback function reads the variables set by the user interface, calculates the samples and saves the samples in a buffer (or any other data structure), then the buffer is read by the user interface and draws a waveform (in a noose loop 60 times per second).

Now, according to some materials that I read (a stream in the list of Linux audio files, this and this ) I need some kind of data structure that can be read and written at the same time without requiring locking, or I need some kind of notification system with cross streams to pass variables around.

However, some examples I have seen using vanilla vectors from the std C ++ library, they read from one stream and write from another, and when I run the programs, they work fine.

• In what cases do I need to use a data structure that is free of blocking, do such a transfer of inter-thread streams?
• If I add another stream, such as a MIDI or OSC callback function, that receives a network IO and needs to pass data to the other two streams, do I need to worry about structures without blocking?
• What would be an adequate structure to use if the answer to the second number is yes?

Answer 1

If you have threads that access the same memory (read or write), you need to either use locks, or you need to use a blocking data structure. Otherwise, your data structures may be corrupted (or corrupted) when they are accessed by more than one thread at the same time.

It looks like the examples you are pointing to use a fixed-size vector that is distributed ahead of schedule. The audio stream is written to this buffer, and the user interface stream reads it, and the two are not synchronized. Since the two can be executed completely simultaneously, the user interface thread has no guarantee as to what data is actually being read; he could read some data from update N and some of updates N + 1. He could skip some data or read some data twice (or more). This is not a reliable way to create audio applications. It will “work” well enough for a simple visualization application, because the visualization results should not be perfect, but it would be completely unsuitable for a recording or playback application.

Audio applications often use blocking data structures (instead of using locks) because audio playback has real-time requirements. If your sound buffers contain 100 ms of sound, you need to fill these buffers 10 times per second, otherwise the sound will stutter. Another way of saying that you have a deadline of 100 ms is to fill the buffer each time.

There are all kinds of things that can make you skip this 100ms period; if the system is too busy, your process may not be scheduled, or a page error may result in a disk reading that has been blocking the process for too long, just to name a few examples. If you try to acquire a lock, but another thread holds it for more than 100 ms, it will force you to skip your deadline. This is why using locks can be harmful to audio applications; another thread that holds the lock for too long can cause you to skip your deadline.

With a locked data structure, there is no lock to wait, so other threads cannot stop your progress. This makes it easier to meet your I / O deadlines.

But before you get too excited about non-blocking algorithms, you should know that they are much more subtle and require much more experience to work properly than blocking. In principle, if you are not an expert in this field, you should not try to write blocking algorithms yourself. Perhaps there is a good open source library that has some blocking algorithms; I have not watched recently.

But understand that the extra work required to use non-blocking algorithms is more or less wasted if you are also not very careful in your audio stream to avoid other possible causes of the delay. In particular:

• your audio stream should not malloc() or free() any memory (most malloc / free implementations acquire a global lock inside)

• you must make sure that any memory accessed by your audio stream is not unloaded (e.g. mlock() )

• Your audio stream should not perform any I / O operations with the sound card, as I / O calls may be blocked.

If you are not very diligent and do not complete all these steps, you can also use a lock for data that is shared with other threads, but make sure that the lock is held for a very short time. For example, do not forget to execute malloc () / free () or block system calls in the user interface thread with a saved lock.