DiskIO_UGen glitch
[email protected] Mon, 17 Feb 2020 22:06:32 +0100
| Newsgroups | gmane.comp.audio.supercollider.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi, I just noticed a curious problem with the Disk IO UGens (DiskIn / DiskOut). First some background info: when the IO thread receives a message, it locks the NRT thread. This is done to make sure that the sound buffer is no (accidentally) resized, deleted or modified concurrently by an asynchronous command. As a consequence, the IO thread is basically tied to the NRT thread, leading to priority inversion: Although the IO thread has to meet deadlines, while the NRT thread does not, the former is forced to wait for the latter. The actual problem manifests when individual asynchronous tasks take longer than the DiskIO_UGen's buffer size: the UGen will read/write old data from the buffer or produce garbage. Here's a bug report by a user of VSTPlugin, who noticed that DiskOut fails when loading a large plugin: https://git.iem.at/pd/vstplugin/issues/58#note_5070. This seems very surprising at first, because VST plugins are loaded asynchronously on the NRT thread, and you would expect that it doesn't interfere with realtime tasks. One "solution" is to simply increase the buffer size, but it basically forces you to know in advance how long your asynchronous operations will take at maximum... The bad thing is that you don't notice the problem while playing, you only hear the glitches in the recording. IMHO, the design of disk IO streaming in SuperCollider is a bit flawed, but I don't see an easy solution... Any ideas? Or just live with it and document it in the help file? Christof _______________________________________________ sc-dev mailing list info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/