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/