SQA devlog - week 2
This is the third of a series of posts about SQA, my pet audio project. I’m rebuilding it from the ground up, for reasons explained here.
This week’s commit log
Commits are given in reverse chronological order, with the most recent appearing first.
sqa-jack
- b9631ef on 2017-01-05: 0.4: Add logging handler support
- adc7432 on 2017-01-04: Add Coveralls CI
- 3c85afa on 2017-01-04: Allow disabling xrun testing, pretty badges
- 9be4a89 on 2017-01-04: test on all rust channels
- dda8575 on 2017-01-04: 0.3: fix import problems that broke stable
- ce4e4a4 on 2017-01-04: I copypasted wrong, third time’s the charm..?
- b8f6fde on 2017-01-04: second stab at Travis CI support
- 0d41210 on 2017-01-04: first stab at Travis CI support
- 3fdafa1 on 2017-01-04: 0.2: add more handlers, fix panic unsoundness
- a85a6a3 on 2017-01-04: Allow opening with OpenOptions, add some fns
sqa-engine
- 0bf5773 on 2017-01-07: fix compiler features, add 128-channels
- 4e69fa8 on 2017-01-06: add README
- 4e72155 on 2017-01-06: Added license and info to Cargo.toml
- f0d230d on 2017-01-06: Depend on sqa-bounded-spsc-queue as a stopgap
- 2df54f8 on 2017-01-06: Add humorous documentation, fix forgetting bug
- 27dbee7 on 2017-01-05: It’s a proper library now!
This week’s changes in detail
sqa-jack
- Version 0.2 of the library fixed an unsoundness bug where Rust code could panic and unwind across the C FFI (foreign function interface) boundary, causing Undefined Behaviour. This still needs some work - it would be a good idea to “poison” the callback handler after one panic to prevent more panics, as objects still existing after a panic isn’t something that usually happens.
sqa-jack
now has Continuous Integration via Travis CI, meaning that the library will run its tests for every new commit and report back if something fails. We also have a fancy test coverage dashboard showing how well the code is tested!- Version 0.3 fixed some problems highlighted by CI that made the library refuse to work on stable.
- Version 0.4 added support for changing the JACK logging routines, so that you can direct the rather verbose JACK logs somewhere other than stdout/stderr.
sqa-engine
- This week, I worked on making the SQA Engine into a usable library, as opposed to the proof-of-concept mess that we had last week. It now has, as the commit log says, “humorous documentation”, so other people can figure out what the hell is going on. It’s still not complete, though, so I haven’t released it on crates.io yet.
- It gained the ability to report back to the main thread about events such as XRUNs, player buffers needing to be refilled, and players being removed.
- I fixed a problem where the audio thread would glitch/XRUN when a player was removed, due to deallocating its buffer in the
audio thread. It’s now sent to the main thread for proper disposal (and, if that cannot happen due to the message queue being
full, it gets
std::mem::forget()
ted).
Screenshot of the week
So, on last week’s devlog, we showed SQA Engine playing 32 channels of audio, under moderate load (30%). This week, I decided to kick things up a notch. (Warning, 12 MB image incoming!)
That’s SQA Engine playing 128 channels of audio. This time, I compiled the library with --release
mode on (enabling the
Rust compiler optimizations) - meaning that it managed to play this test with a DSP Load value of 1%, down from last week’s
30% value. QLab can’t even do 128 channels of audio (although, there’s no real reason you’d want to, so I sort of get their
point).
Wow, Rust is fast!
That’s it for this week - stay tuned for next week’s devlog!