In the last week, I created the
sqa-engine crate, and got it up and running playing a WAV file with
sqa-jack. Progress is
This week’s commit log
Commits are given in reverse chronological order, with the most recent appearing first.
- d1068a2 on 2016-12-31: Allow registering/deregistering ports anytime
- 2a54e1f on 2017-01-02: volume, more strenuous tests
- 064307e on 2016-12-31: use skip_n() method of bufs, cargo updates
- 35b2f00 on 2016-12-31: added chan system & sadistic tests
- 4a52a1d on 2016-12-31: removed warnings, added plain senders, press Enter
- 1b59918 on 2016-12-31: Proof of concept: it plays back a WAV file!
- I made a pull request to the
bounded_spsc_queuerepo to add some functionality I’m now using in
This week’s changes in detail
The big change this week, as mentioned in the title, is that we now have a
crate in the mix. This handles all the actual audio playing - making sure that the audio arrives at its destination on time,
playing at the correct volume, etc.
Consumers of this crate get the following
struct to play with:
Yup, lots of atomics! Essentially, how it works is you set
start_time to when you want the audio to start playing (ideally, you
do this in advance), set the
output_patch to a channel number (which you can create with the main
active to true, then start feeding data into the
buf (which is a
Ideally, you’d spawn a dedicated spooler thread to feed data in as fast as possible. The point is, you don’t have to worry about
dealing with the scary realtime audio callback (which you get with other APIs that requires you to provide data in
or your audio glitches) - you just send your data in and it plays it on time. This will prove instrumental for SQA - and I’ll be
documenting and publishing the library next week, so that other Rustaceans can make use of it.
Screenshot of the week
This week’s screenshot shows the new SQA Engine being put under a 32-channel stress test: it was playing one WAV file across 16 left and 16 right channels, to see how it would cope under the load.
This test was conducted using a buffer size of 256 samples - meaning the SQA engine had roughly 5 ms to process each buffer. It handled this well, with there being no buffer underruns (that means no audio glitches at all) and taking only 30% of the time it had to perform this task.
That’s it for this week - stay tuned for next week’s devlog!