Re: [LAD] basic RT-thread model questions

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 <lars.luthman@email-addr-hidden> 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 sequencing app that uses one thread per
> >> audio/instrument track (as most do), is it OK to share a lock between
> >> real time scheduled tracks?
> >
> > Maybe. In theory it should be OK, I don't know enough scheduler magic to
> > be certain.
>
> We haven't seen any drop in performance at all and are going to
> release, so I suppose that's "good enough for us". The cool thing is
> that python has been **AWESOME** (that's four starts, kids) in the
> real time threads. The python lib is only accessed from our audio
> kernel(s), with script source set with using downstream message
> passing, and exceptions and redirected stdout using upstream message
> passing.

I'm not sure to understand if your python code runs in the real-time
thread or not. But if it's the case I wouldn't relay on the non-blocking
performance of Python. Although garbage collector can be disabled the
main problem, as I understand, is that Python is calling malloc all the
time.
Some info about it
http://entitycrisis.blogspot.com/2007/12/is-hard-real-time-python-possible.html

Real-time is all about predictability and worst case. For example, an
audio file player that reads the file in the real-time thread will also
be "good enough" most of the times (I've tested it). Till the
very-important-demo day.

Pau

> >
> >> Also, I've gathered are that adding app-thread => RT-thread
> >> message-passing to avoid using locks while modify the application's
> >> basic shared data structures is useless, since the real-time thread
> >> will have to wait for execution of that code one way or another, given
> >> the overhead of acquiring the lock is negligable. This would mean that
> >> you should just use locks and assume the user will cope with hearing
> >> small overruns when adding/removing audio components. True? Not true?
> >
> > Not true. The point with message-passing instead of locking a shared
> > structure is that the RT thread doesn't access the shared structure in
> > the first place - it has its own copy of the parameters it needs and can
> > keep on producing audio until it receives a message, at which point it
> > just changes its parameters in some RT-safe way (pointer swap etc) and
> > goes on producing audio. No glitch.
> >
>
> That makes sense. We are using a pointer swap in the message queue
> using platform-specific atomic compare and swap functions. I wasn't
> the one that implemented it, but the concept seems to make sense now.
>
> >
> > --ll
> >
> > _______________________________________________
> > Linux-audio-dev mailing list
> > Linux-audio-dev@email-addr-hidden
> > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
> >
> >
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Fri Jun 6 16:15:04 2008