5 Jun
2008
5 Jun
'08
4:34 p.m.
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/instrument track (as most do), is it OK to share a lock between
real time scheduled tracks? I ran into this question after
implementing a scripting engine for our commercial audio plugin using
python, which uses a global lock to serialize access to it's data
structures.
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?
I hope I worded these well enough. Cheers!
5 Jun
5 Jun
4:48 p.m.
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.
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.
--ll
5:01 p.m.
On Thu, Jun 5, 2008 at 10:47 AM, Lars Luthman <lars.luthman(a)gmail.com> wrote:
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.
On Thu, 2008-06-05 at 10:34 -0800, Patrick Stinson
wrote:
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 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. 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.
--ll
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
6 Jun
6 Jun
7:51 a.m.
El dj 05 de 06 de 2008 a les 11:01 -0800, en/na Patrick Stinson va
escriure:
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.
On Thu, Jun 5, 2008 at 10:47 AM, Lars Luthman
<lars.luthman(a)gmail.com> wrote:
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.…
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
On Thu, 2008-06-05 at 10:34 -0800, Patrick
Stinson wrote:
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 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. 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.
--ll
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
4:17 p.m.
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(a)iua.upf.edu> wrote:
El dj 05 de 06 de 2008 a les 11:01 -0800, en/na
Patrick Stinson va
escriure:
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.
On Thu, Jun 5, 2008 at 10:47 AM, Lars Luthman
<lars.luthman(a)gmail.com> wrote:
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.…
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
On Thu, 2008-06-05 at 10:34 -0800, Patrick
Stinson wrote:
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 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. 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.
--ll
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
6011
days inactive
6012
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
Lars Luthman -
Patrick Stinson -
Pau Arumí Albó