Sonic Pi: Scalability Analysis

Key Scalability Scenario and Challenge

Scalability is an important issue when we need to deeply evaluate a software’s architecture. It shows its ability to handle the increased workload or reduced recources. In this article, we elvaluate Sonic Pi’s scalability mainly based on the a multi-threading scenario, which is very common in music production.

Sonic Pi is a software for producing sounds. It works locally without connecting to the internet and it does not use any database. The main workload lies in the server in which users’ codes are compiled and then sythesized by the SuperCollider. The CPU and RAM usage consist of the main scaling parameters in evaluating the performance of Sonic Pi.

Sonic Pi enables creating music where different instruments playing at the same time. In a band, usually there are guitar players, bass players, drumers, etc. Sonic Pi plays the role of the whole band and produces these sounds in a multi-threading envioronment. In this scenario, the number of the running threads is the key component that scales the CPU and RAM usage of Sonic Pi. In addition, Sonic Pi also works on micro-controllers such as Raspberry Pi, the limited RAM space should also be taken into consideration. In the following section, we will analyze Sonic Pi’s solution to this challenge and evaluate its scalablity in this scenario.

Test upon scalability

To test the software’s scalability, we used Sonic Pi on Windows 10, and monitored its performance in terms of CPU memory usage via the Windows Task Manager, as shown in the figure below.

In our configurations, for the sake of time, we use only one piece of music and replay it several times together to imitate the scenario which Sonic Pi processes multiple sound buffers at a time. We think this is feasible since Sonic Pi will treat all buffers in seperate threads and send them to the Supercollider to synth in the latter case, which is the same procedure as replaying a piece repeatedly. We tried to clicked the “run” button from 1 to 10 times. The results are shown as below:

In the experiment, we only measure the peak CPU usage for Sonic Pi in total since it is representative of the processing efficiency. We also only measure the memory usage of the Ruby interpreter, since it is the component we observed to be mainly changing due to increasing input. From the plots we can see that, both peak CPU usage and memory usage are linear to the amount of input in the range of 10 simultaneously played input files. This may pose a threat of Sonic Pi when it is required to play decades of sound tracks at a time.

Current solutions to the scalabiilty problem

In Sonic Pi’s architecture there are two main parts that is related to the scalability problem mentioned in the first section. They are the multi-threading design and the SuperCollider synthing tool.

Multi-threading is a main feature of Sonic Pi’s functions. It not only provides the users with a very simple command “in_thread” to play music within the code block simultaneously with other running threads, but also gives the software the ability to handle multiple pieces of music at a time. It is realised by using Ruby’s “thread” class ¹. Sonic Pi implements this multi-threading idea to handle multiple inputs from user’s codes on the Ruby server instead of using a single thread. This can help alleviate the burden of CPU cores.

On the other hand, the SuperCollider synthing tool is at the end of the Sonic Pi server, handling the music producing jobs. It is written mainly in C++ language, which has high hardware efficiency among other programming languages. Although there are issues on Github complaining about the limited synths of the SuperCollider ², SuperCollider still provides very efficient synthing on its available resources.

Proposals for architectural changes

As the issue mentioned in the previous section, audio synthesis server “Scsynth”³ runs on one core and the rest of the cores in a multi-core device can not be leveraged for the audio synthesis in this case. It means that there could be higher latency if multiple threads are running simultaneously, which could degrade the usability of a real-time application. To overcome this issue, Scsynth in the current architecture can be replaced by Supernova⁴, a parallelable audio synthesis server. Supernova is also written in the same audio synthesis programming language as Scsynth but it is more scalable than Scsynth due to the parallelism ability. Since there is the probability of data races while achieving a larger throughput by parallelism. To ensure thread safety and high performance, there are some specific policies applied in the Supernova. For instance, the main shared data structures are only buses and buffers and each of them is assigned a reader-writer spin-lock. To reduce the probability of deadlock, there is a specified lock order since unit generators sometimes need to get access to multiple resources sequentially and if there is a lock that cannot be obtained in the lock order, the locks obtained before will be released. But due to the high requirement on low latency, there could be a higher CPU recourses consumption on Supernova because all helper threads will be wakened up and pushed into a lock-free stack due to the infeasibility of the blocking primitive usage in the real-time application⁴.

Diagrams of current and proposed architectural designs

As shown in the figure “Current architectural design”, the current version is based on the Scsynth audio synthesis server, which limits the possibility of parallelism of Sonic Pi. To integrate the proposed solution into the architecture, the Supernova can replace the Scsynth used for audio server in current architecture as shown in figure “Proposed architectural design”. In this case, it is likely that more cores can be utilized for the audio synthesis and more threads can be handled in the meanwhile.

An argument of proposed change

The proposed solution aims to overcome the issue of single-core usage caused by the property of Scsynth. By replacing Scsynth with Supernova, Sonic Pi runs a parallel implementation of the SuperCollider server. It is impossible to receive a concrete experiment result about how different the performance of Sonic Pi would be after the solution is applied, but an argument can be made based on the conclusion in the paper “Supernova - A scalable parallel audio synthesis server for supercollider”⁴, from the aspects of feasibility and possible influences. First, the high feasibility of this solution is beneficial from the rapid development of the computer industry, multi-core CPU computers becoming the mainstream. Sonic Pi can expect most of its users’ devices to be able to adapt to this improvement. At the same time, Supernova is available in the Server object of the current version of SuperCollider. The cost of transformation is relatively lower than other structure changes.

⁵

If we turn into the aspect of possible influence of performance, the performance of Sonic Pi is expected to be retained. In the above mentioned paper, the audio synthesis execution times in a different number of threads are measured and the evaluation result shows that the execution time with multiple threads decreased significantly when compared to the one with one thread or of the sequential group, which are 250ms and 650ms respectively. And this result also represents carrying out the audio synthesis in parallel can reduce the latency of the software and there is the possibility of tackling more threads by leveraging the Supernova. Therefore, we proposed with switching to Supernova, Sonic Pi can still keep its current performance in the real-time audio synthesis aspect, or even owns shorter execution time as Supernova can scale well with the number of CPUs.

Obviously, we are not the first one who mentioned this change, there is already a discussion of implementing Supernova in Sonic Pi⁶ . This discussion happened in 2015, and the main concerns were about the problematic performance on macOS, less test cases and drift from sclang over large periods of time. In the reply, there are comments that state positive attitudes to the performance of Supernova itself, and a comment in 2016 replied that an issue of platform adaptation is proposed in issues of Supercollider, and an updated instruction⁷ of Supercollider seems to solve the adaptive problem between Supernova and macOS. Therefore, we still consider this proposed change as a feasible solution to the scalability issue of Sonic Pi.

---

1. Documentation of Ruby Thread class, https://ruby-doc.org/core-2.5.0/Thread.html ↩︎

2. Issue regarding Super_collider, https://github.com/sonic-pi-net/sonic-pi/issues/2411 ↩︎

3. Scsynth, https://manpages.org/scsynth ↩︎

4. Supernova, https://tim.klingt.org/publications/icmc2011_supernova.pdf ↩︎

5. Server object, https://doc.sccode.org/Classes/Server.html ↩︎

6. Issue #1359, https://github.com/supercollider/supercollider/issues/1359 ↩︎

7. Supercollider setup of macOS, https://github.com/supercollider/supercollider/blob/develop/README_MACOS.md ↩︎