Reported by camlorn on 2015-05-18 18:51
#4877, the speech refactor, is going to need some sort of new, higher-level mixer. This mixer will need to b implemented in C. The existing NVWave code is sufficient but is currently Python, necessitating a great deal of complexity and copying to be reused in this manner.
I propose moving the NVWave API into C, using a background thread for all audio processing which is communicated with via a threadsafe queue and a command structure. The background thread allows large delays when closing devices and, as discussed on IRC, the ability to insert blocks of zeros for Windows 8 audio ducking (something I cannot personally test).
I propose three changes to the interface of the API which should be discussed before I begin coding.
First, we should fix the bit depth at 16 bits. 8 is nearly useless and WaveOut does not provide straightforward ways to query for higher bit depths, meaning that most code should already be using 16-bit audio anyway.
Second, we should replace blocking on the last buffer with blocking for a configurable number of milliseconds.
Third, we should add and encourage code to call a finalize method.
I propose Powercores for the threadsafe queue. This is written by me, released under the Unlicense, and currently header only. It comes with tests and has been used in Libaudioverse for at least 6 months.
Internally, I want to mix in chunks. If we wish to block around 100 milliseconds, we can split the audio into 100 MS pieces internally, maintain exactly two buffers, fill both, and block until one of them becomes available for new data. This will allow lowering the buffer size in synths, as the API will refuse to block until it has at least 100 MS of audio (i.e. 64-sample chunks are fine, we'll append them together in C). This should result in increased callback accuracy in future. Because we are using a push-based API, blocking at slightly higher MS thresholds is acceptible.
Device enumeration stays as-is in Python. This is probably about 300-500 lines of C/C++. I plan to write the patch.
Let's talk about where I'm either being stupid or need to explain further. I'm sure I've missed something.
Reported by camlorn on 2015-05-18 18:51
#4877, the speech refactor, is going to need some sort of new, higher-level mixer. This mixer will need to b implemented in C. The existing NVWave code is sufficient but is currently Python, necessitating a great deal of complexity and copying to be reused in this manner.
I propose moving the NVWave API into C, using a background thread for all audio processing which is communicated with via a threadsafe queue and a command structure. The background thread allows large delays when closing devices and, as discussed on IRC, the ability to insert blocks of zeros for Windows 8 audio ducking (something I cannot personally test).
I propose three changes to the interface of the API which should be discussed before I begin coding.
First, we should fix the bit depth at 16 bits. 8 is nearly useless and WaveOut does not provide straightforward ways to query for higher bit depths, meaning that most code should already be using 16-bit audio anyway.
Second, we should replace blocking on the last buffer with blocking for a configurable number of milliseconds.
Third, we should add and encourage code to call a finalize method.
I propose Powercores for the threadsafe queue. This is written by me, released under the Unlicense, and currently header only. It comes with tests and has been used in Libaudioverse for at least 6 months.
Internally, I want to mix in chunks. If we wish to block around 100 milliseconds, we can split the audio into 100 MS pieces internally, maintain exactly two buffers, fill both, and block until one of them becomes available for new data. This will allow lowering the buffer size in synths, as the API will refuse to block until it has at least 100 MS of audio (i.e. 64-sample chunks are fine, we'll append them together in C). This should result in increased callback accuracy in future. Because we are using a push-based API, blocking at slightly higher MS thresholds is acceptible.
Device enumeration stays as-is in Python. This is probably about 300-500 lines of C/C++. I plan to write the patch.
Let's talk about where I'm either being stupid or need to explain further. I'm sure I've missed something.