Re: DiskIO_UGen glitch

Hi,

 > i think it's logical that all async tasks compete with each other,
and so one taking very long can cause another to not meet RT deadlines.

First, async tasks never have to meet any deadlines (that's why they run
on the so called NRT thread :-), and yes, it's not a problem that they
have to wait for each other. The problem is about the Disk IO thread,
which *does* have to meet (soft) deadlines.

 > the only solution would probably be to have more than one
asynchronous thread.

There are already two threads: the "regular" NRT thread and the private
disk IO threads shared by all DiskIn/DiskOut instances. The problem is
that the latter implicitly depends on the former, although it shouldn't
have to.

 > could you spawn another temporary thread just for that task

I could, but then I'm "outside" the scsynth architecture of async
commands and stuff like "s.sync" won't work anymore. Many VSTPlugins
load quite quickly, but some need more time. But this is really the same
with sound files: loading a 16 GB WAV file into memory isn't quick
either :-)

Christof

On 17.02.2020 22:29, [email protected] wrote:
> hi christof,
>
> (disclaimer: i don't know the server internals well)
>
> i think it's logical that all async tasks compete with each other, and
> so one taking very long can cause another to not meet RT deadlines. the
> only solution would probably be to have more than one asynchronous
> thread. in your case, i don't know how VST initialisation works, but
> perhaps you could avoid bottlenecks by breaking the process up into
> several steps, so that other async tasks like disk-in buffer updates can
> be interleaved in the async queue better? or, if it is not possible and
> really takes long, could you spawn another temporary thread just for
> that task (pardon me if this is not possible in the architecture, i have
> no idea).
>
> best, .h.h.
>
>
>
> On 17/02/2020 22:06, [email protected] wrote:
>> 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/
> _______________________________________________
> 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/

_______________________________________________
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/