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ó <[EMAIL PROTECTED]> 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 <[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 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 >> > [email protected] >> > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev >> > >> > >> _______________________________________________ >> Linux-audio-dev mailing list >> [email protected] >> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev > > _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
