Re: [LAD] basic RT-thread model questions

From: Patrick Stinson <patrickstinson.lists@email-addr-hidden>
Date: Fri Jun 06 2008 - 21:17:27 EEST

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

This archive was generated by hypermail 2.1.8 : Sat Jun 07 2008 - 00:15:39 EEST