Re: DiskIO_UGen glitch

block on a different lock until the resource ir ready or taken? (I do the
same disclaimer as contact).

El lun., 17 feb. 2020 a las 18:46, <[email protected]> escribió:

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