Re: [LAD] basic RT-thread model questions

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:

"""That said, after three years in the embedded industry, I've noticed
one thing: most things people insist are hard real-time are, actually,
not. Often, they require guaranteed throughput, not latency, and when
hard real-time is required, the alleged hard real-time solution is
actually soft real-time with a low probability of failure. But nobody
cares, because it works anyway, and was a hell of a lot easier to
write and debug."""

On Fri, Jun 6, 2008 at 1:50 AM, Pau Arumí Albó <parumi@email-addr-hidden> wrote:
> 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 Sat Jun 7 00:15:37 2008