"Patrick Stinson":
>
> I know that the rule is to never block in a real time audio thread,
> but what about blocking for resources shared between real-time
> threads? In the case of a sequencing app that uses one thread per
> audio/instrument track (as most do), is it OK to share a lock between
>
Well, commercial music software is soft realtime, so it's more about
common case than worse case". In most cases the finished product is
rendered to disk with low-pri anyway. I didn't even think about the GC
though. I'll have to check that out.
Otherwise, I like this quote from the comments:
"""T
El dj 05 de 06 de 2008 a les 11:01 -0800, en/na Patrick Stinson va
escriure:
> On Thu, Jun 5, 2008 at 10:47 AM, Lars Luthman <[EMAIL PROTECTED]> wrote:
> > On Thu, 2008-06-05 at 10:34 -0800, Patrick Stinson wrote:
> >> I know that the rule is to never block in a real time audio thread,
> >> but wha
On Thu, Jun 5, 2008 at 10:47 AM, Lars Luthman <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-06-05 at 10:34 -0800, Patrick Stinson wrote:
>> I know that the rule is to never block in a real time audio thread,
>> but what about blocking for resources shared between real-time
>> threads? In the case of a
On Thu, 2008-06-05 at 10:34 -0800, Patrick Stinson wrote:
> I know that the rule is to never block in a real time audio thread,
> but what about blocking for resources shared between real-time
> threads? In the case of a sequencing app that uses one thread per
> audio/instrument track (as most do),
I'm just asking these out of curiosity. I know you guys love these
kinds of questions :)
I know that the rule is to never block in a real time audio thread,
but what about blocking for resources shared between real-time
threads? In the case of a sequencing app that uses one thread per
audio/instru
