2 Dec
2012
2 Dec
'12
10:01 p.m.
OK, I know I've been using Linux audio for 6 years now, and gigged and recorded with
it extensively for most of those, yadda yadda. But it seems I've had an embarassingly
huge hole in my knowledge the whole time.
I was under the impression that, in order to use real time priorities/permissions and Ingo
kernels, it was required for the process ITSELF early in the main() routine of its source
code, to make some system calls to claim RT priority. In fact, I specifically remember
reading or even writing source code in C which did that (probably based on JACK sample
code). I don't recall the name of the syscall, but it was something obvious and
well-documented.
Also, I remember that it was also required that the software behave properly in order to
be real-time capable, something about callbacks taking some predictable amount of time. Or
perhaps that was only a JACK requirement.
Why am I asking these dumb-ass questions now? Because I've been playing around with
Liquidsoap and Airtime for some radio stations, and I'm obsessed with getting them as
rock-solid on cheap/free/old hardware as I'd been able to get with my gigging and
studio synths.
It physically pains me to hear audio stuttering because Apache is running on the same box.
It seems an outrage to me. Shouldn't happen. Ever. I used to record and mix
multi-track songs in Ardour with tons of soft-synths WHILE A KERNEL COMPILE WAS GOING ON
THE SAME MACHINE without a single glitch. I expect no less.
So I asked on the Liquidsoap list, and I got only shrugs and a pointer to the Gentoo page
in response (why? I have no idea. I use Debian, and that's irrelevant to the question
at hand anyway.).
So what's the deal? Is there a way to give Ingo-approved preemptive RT priority to
things that aren't real-time apps and aren't specifically architected for that?
What, if anything, would break?
And, if I wanted to hack Liquidsoap (which would require learning ML, which wouldn't
be a bad thing to know anyway), is it even possible to get it RT-capable, or are there
low-level C system calls required in order to make that work?
Sorry for the long and obscure question, but it's been bothering me for a while, and I
figured someone here would know the answer, or where I might find it.
Thanks.
-ken
2 Dec
2 Dec
10:17 p.m.
simple answer: non-RT things need more buffering between them and the
hardware. find out how to do that.
On Sun, Dec 2, 2012 at 4:00 PM, Ken Restivo <ken(a)restivo.org> wrote:
OK, I know I've been using Linux audio for 6 years
now, and gigged and
recorded with it extensively for most of those, yadda yadda. But it seems
I've had an embarassingly huge hole in my knowledge the whole time.
I was under the impression that, in order to use real time
priorities/permissions and Ingo kernels, it was required for the process
ITSELF early in the main() routine of its source code, to make some system
calls to claim RT priority. In fact, I specifically remember reading or
even writing source code in C which did that (probably based on JACK sample
code). I don't recall the name of the syscall, but it was something obvious
and well-documented.
Also, I remember that it was also required that the software behave
properly in order to be real-time capable, something about callbacks taking
some predictable amount of time. Or perhaps that was only a JACK
requirement.
Why am I asking these dumb-ass questions now? Because I've been playing
around with Liquidsoap and Airtime for some radio stations, and I'm
obsessed with getting them as rock-solid on cheap/free/old hardware as I'd
been able to get with my gigging and studio synths.
It physically pains me to hear audio stuttering because Apache is running
on the same box. It seems an outrage to me. Shouldn't happen. Ever. I used
to record and mix multi-track songs in Ardour with tons of soft-synths
WHILE A KERNEL COMPILE WAS GOING ON THE SAME MACHINE without a single
glitch. I expect no less.
So I asked on the Liquidsoap list, and I got only shrugs and a pointer to
the Gentoo page in response (why? I have no idea. I use Debian, and that's
irrelevant to the question at hand anyway.).
So what's the deal? Is there a way to give Ingo-approved preemptive RT
priority to things that aren't real-time apps and aren't specifically
architected for that? What, if anything, would break?
And, if I wanted to hack Liquidsoap (which would require learning ML,
which wouldn't be a bad thing to know anyway), is it even possible to get
it RT-capable, or are there low-level C system calls required in order to
make that work?
Sorry for the long and obscure question, but it's been bothering me for a
while, and I figured someone here would know the answer, or where I might
find it.
Thanks.
-ken
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
10:23 p.m.
On Sun, Dec 2, 2012 at 9:00 PM, Ken Restivo <ken(a)restivo.org> wrote:
Also, I remember that it was also required that the
software behave
properly in order to be real-time capable, something about callbacks taking
some predictable amount of time. Or perhaps that was only a JACK
requirement.
I'll only try to answer this part of the question:
The audio processing call graph must not do anything indeterministic.
Anything like allocating memory, deallocating memory, grabbing a mutex lock
etc are *all* indeterministic. Any system call unless *explicitly* named
real-time safe, should be considered non-real time. Nice article providing
info on this:
http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-…
With JACK clients, JACK registers its audio threads as RT, and then calls
into your code with that thread. You don't have to acquire RT thread
priorities yourself in your program. It is advisable to do a memlock_all()
though, so the memory you're using won't ever be moved to swap.
These steps sound quite easy, but program design and resource creation /
destruction must all be carefully planned in such an environment. If the
program has been designed from the ground up for RT work, no problem. If it
hasn't it could prove difficult to make it RT safe. Buffering is the
nemesis of RT low-latency work: perhaps increasing your buffering will fix
your problems...
Bit of a techie answer, HTH anways. -Harry
PS: Just noticed Paul's said this in one sentence :)
10:26 p.m.
On Sun, December 2, 2012 1:00 pm, Ken Restivo wrote:
Why am I asking these dumb-ass questions now? Because
I've been playing
around with Liquidsoap and Airtime for some radio stations, and I'm
obsessed with getting them as rock-solid on cheap/free/old hardware as I'd
been able to get with my gigging and studio synths.
It physically pains me to hear audio stuttering because Apache is running
on the same box. It seems an outrage to me. Shouldn't happen. Ever. I used
to record and mix multi-track songs in Ardour with tons of soft-synths
WHILE A KERNEL COMPILE WAS GOING ON THE SAME MACHINE without a single
glitch. I expect no less.
I don't know if realtime would fix this. This is not a low latency
operation unless you are using the same machine for studio monitoring (not
the way I would do it for sure) but rather a matter of having a large
enough buffer to play with and setting buffer refill soon enough and with
the priority it needs to refill in time.
Having a bigger priority than apache may not be enough, the buffer needs
to be big enough that the largest packet apache sends to the NIC driver
has time to get gone and load the audio in. In other words once apache has
sent a packet to the network stack, the packet(s) that the network stuff
has in the queue has to be gone before your audio can get sent.
So if you are using Jack, try setting the latency twice or more and see if
that helps. Then if that doesn't help it is time to get Liquidsoap to have
a bigger packet size and maybe to try and get more packets into the
network queue at a time. There may be some settings in apache that makes
it send smaller packets too.
So I would envision a studio box with whatever is needed to make the
studio work with s/pdif out to s/pdif in on the server. The studio runs
jack with ~5ms latency and the server runs with ~200ms latency or
something like that. Some software that can have ~5ms latency in and
~200ms latency out would work too, but I don't know if such a thing
exists, though it doesn't sound that hard to make. (though Len hasn't done
any of this kind of programing at all so use the grain of salt thing)
There are lots of people here with much more experience in audio
programing who may have a better solution.
--
Len Ovens
www.OvenWerks.net
11:04 p.m.
On Sunday 02 December 2012 13:00:57 Ken Restivo wrote:
OK, I know I've been using Linux audio for 6 years
now, and gigged and
recorded with it extensively for most of those, yadda yadda. But it seems
I've had an embarassingly huge hole in my knowledge the whole time.
I was under the impression that, in order to use real time
priorities/permissions and Ingo kernels, it was required for the process
ITSELF early in the main() routine of its source code, to make some system
calls to claim RT priority. In fact, I specifically remember reading or
even writing source code in C which did that (probably based on JACK sample
code). I don't recall the name of the syscall, but it was something obvious
and well-documented.
You are probably talking about sched_setscheduler and friends
http://goo.gl/kTlOR
Desktop apps may use RealtimeKit instead of calling that API directly, but
Liquidaudio is not this kind of thing, if I've understood it correctly
http://git.0pointer.de/?p=rtkit.git;a=blob;f=README
The question is if Liquidsoap really needs low latency audio (small buffers +
high/RT priority) or it works better with bigger buffers and high latency so
you don't need to worry too much about priorities.
Regards,
Pedro
3 Dec
3 Dec
3:27 a.m.
On Sun, Dec 02, 2012 at 11:03:58PM +0100, Pedro Lopez-Cabanillas wrote:
On Sunday 02 December 2012 13:00:57 Ken Restivo
wrote:
Thanks everyone for the fantastic and detailed answers! Now it is all starting to make
sense to me.
Yes, sched_foo were the ones I was thinking of, SCHED_FIFO being the priority for Ingo-ish
RT, IIRC.
And yes, it was the requirement for determinsm (no malloc, blocking system calls, etc)
that I remember from JACK callbacks, and thanks for confirming that it is a general
requirement of RT audio in general, not of JACK in perticular.
Buffering indeed is what sounds like the main issue for Liquidsoap. But I have no way of
knowing how much buffer would actually be necessary to assure it NEVER skips. This is why
I was thinking along the lines of some kind of preemption to assure that never happens.
rtkit looks interesting, but if there were a way to this without it, I'd prefer that.
Low latency is NOT required for this application, just stability when starved for
resources. Liquidsoap spends almost all of of its time decoding MP3s from disk or reading
and decoding MP3 streams off of the internet.
-ken
OK, I know I've been using Linux audio for 6
years now, and gigged and
recorded with it extensively for most of those, yadda yadda. But it seems
I've had an embarassingly huge hole in my knowledge the whole time.
I was under the impression that, in order to use real time
priorities/permissions and Ingo kernels, it was required for the process
ITSELF early in the main() routine of its source code, to make some system
calls to claim RT priority. In fact, I specifically remember reading or
even writing source code in C which did that (probably based on JACK sample
code). I don't recall the name of the syscall, but it was something obvious
and well-documented.
You are probably talking about sched_setscheduler and friends
http://goo.gl/kTlOR
Desktop apps may use RealtimeKit instead of calling that API directly, but
Liquidaudio is not this kind of thing, if I've understood it correctly
http://git.0pointer.de/?p=rtkit.git;a=blob;f=README
The question is if Liquidsoap really needs low latency audio (small buffers +
high/RT priority) or it works better with bigger buffers and high latency so
you don't need to worry too much about priorities.
5:48 p.m.
Hi all,
Interesting thread, and thanks for the information.
I have a related question: I have an EEEPC 1000HE netbook (used to run Arch
but I got tired of having to compile, or failing to compile, some extra
pacakges) that runs Xubuntu, usually with XFCE of course, but sometimes
with Fluxbox. Also have a bigger laptop, and HP pavilion7, running Mint
with Maya Desktop (I also switch it to Fluxbox sometimes).
Anyway, it seems the EEE has suboptimal IRQ hardware settings for RT low
latency audio...doing less /proc/interrupts shows that there's a lot of
sharing, like the audio and video card being on the same IRQ. Indeed,
running Csound FLTK gui interfaces and moving them while processing the
csound orchestra sometimes makes pops and crackle dropouts, while the same
thing on the better IRQ set HP Pavilion shows flawless performance.
Even if I run an outboard USB audio interface (Lexicon Lambda) on the EEE,
there is still suboptimal USB Irq settings to contend with.
I've always suspected IRQ settings, which are unfortunately hard-wired in
laptops, to be profoundly influential in RT performance, but I wanted the
audio guru programmers to comment.
Thanks,
AKJ
On Sun, Dec 2, 2012 at 8:27 PM, Ken Restivo <ken(a)restivo.org> wrote:
On Sun, Dec 02, 2012 at 11:03:58PM +0100, Pedro
Lopez-Cabanillas wrote:
but
--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org
On Sunday 02 December 2012 13:00:57 Ken Restivo
wrote:
> OK, I know I've been using Linux audio for 6 years now, and gigged and
> recorded with it extensively for most of those, yadda yadda. But it
seems
> I've had an embarassingly huge hole in
my knowledge the whole time.
>
> I was under the impression that, in order to use real time
> priorities/permissions and Ingo kernels, it was required for the
process
> ITSELF early in the main() routine of its
source code, to make some
system
> calls to claim RT priority. In fact, I
specifically remember reading or
> even writing source code in C which did that (probably based on JACK
sample
> code). I don't recall the name of the
syscall, but it was something
obvious
and
well-documented.
You are probably talking about sched_setscheduler and friends
http://goo.gl/kTlOR
Desktop apps may use RealtimeKit instead of calling that API directly, Liquidaudio is not this kind of thing, if
I've understood it correctly
http://git.0pointer.de/?p=rtkit.git;a=blob;f=README
The question is if Liquidsoap really needs low latency audio (small
buffers +
high/RT priority) or it works better with bigger
buffers and high
latency so
you don't need to worry too much about
priorities.
Thanks everyone for the fantastic and detailed answers! Now it is all
starting to make sense to me.
Yes, sched_foo were the ones I was thinking of, SCHED_FIFO being the
priority for Ingo-ish RT, IIRC.
And yes, it was the requirement for determinsm (no malloc, blocking system
calls, etc) that I remember from JACK callbacks, and thanks for confirming
that it is a general requirement of RT audio in general, not of JACK in
perticular.
Buffering indeed is what sounds like the main issue for Liquidsoap. But I
have no way of knowing how much buffer would actually be necessary to
assure it NEVER skips. This is why I was thinking along the lines of some
kind of preemption to assure that never happens.
rtkit looks interesting, but if there were a way to this without it, I'd
prefer that.
Low latency is NOT required for this application, just stability when
starved for resources. Liquidsoap spends almost all of of its time decoding
MP3s from disk or reading and decoding MP3 streams off of the internet.
-ken
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
1:50 a.m.
You probably tried using the nice command,
maybe with most processes +10 and with -10 for
your music processes, yes?
On Sun, 2012-12-02 at 13:00 -0800, Ken Restivo wrote:
OK, I know I've been using Linux audio for 6 years
now, and gigged and recorded with it extensively for most of those, yadda yadda. But it
seems I've had an embarassingly huge hole in my knowledge the whole time.
I was under the impression that, in order to use real time priorities/permissions and
Ingo kernels, it was required for the process ITSELF early in the main() routine of its
source code, to make some system calls to claim RT priority. In fact, I specifically
remember reading or even writing source code in C which did that (probably based on JACK
sample code). I don't recall the name of the syscall, but it was something obvious and
well-documented.
Also, I remember that it was also required that the software behave properly in order to
be real-time capable, something about callbacks taking some predictable amount of time. Or
perhaps that was only a JACK requirement.
Why am I asking these dumb-ass questions now? Because I've been playing around with
Liquidsoap and Airtime for some radio stations, and I'm obsessed with getting them as
rock-solid on cheap/free/old hardware as I'd been able to get with my gigging and
studio synths.
It physically pains me to hear audio stuttering because Apache is running on the same
box. It seems an outrage to me. Shouldn't happen. Ever. I used to record and mix
multi-track songs in Ardour with tons of soft-synths WHILE A KERNEL COMPILE WAS GOING ON
THE SAME MACHINE without a single glitch. I expect no less.
So I asked on the Liquidsoap list, and I got only shrugs and a pointer to the Gentoo page
in response (why? I have no idea. I use Debian, and that's irrelevant to the question
at hand anyway.).
So what's the deal? Is there a way to give Ingo-approved preemptive RT priority to
things that aren't real-time apps and aren't specifically architected for that?
What, if anything, would break?
And, if I wanted to hack Liquidsoap (which would require learning ML, which wouldn't
be a bad thing to know anyway), is it even possible to get it RT-capable, or are there
low-level C system calls required in order to make that work?
Sorry for the long and obscure question, but it's been bothering me for a while, and
I figured someone here would know the answer, or where I might find it.
Thanks.
-ken
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
2:01 a.m.
nice has absolutely nothing to do with this, and if it has any effect, it
is accidental and should not be relied on.
On Sun, Dec 2, 2012 at 7:50 PM, jim <jim(a)well.com> wrote:
You probably tried using the nice command,
maybe with most processes +10 and with -10 for
your music processes, yes?
On Sun, 2012-12-02 at 13:00 -0800, Ken Restivo wrote:
OK, I know I've been using Linux audio for 6
years now, and gigged and
recorded with it extensively for most of those, yadda
yadda. But it seems
I've had an embarassingly huge hole in my knowledge the whole time.
I was under the impression that, in order to use real time
priorities/permissions
and Ingo kernels, it was required for the process
ITSELF early in the main() routine of its source code, to make some system
calls to claim RT priority. In fact, I specifically remember reading or
even writing source code in C which did that (probably based on JACK sample
code). I don't recall the name of the syscall, but it was something obvious
and well-documented.
Also, I remember that it was also required that the software behave
properly in
order to be real-time capable, something about callbacks taking
some predictable amount of time. Or perhaps that was only a JACK
requirement.
Why am I asking these dumb-ass questions now? Because I've been playing
around
with Liquidsoap and Airtime for some radio stations, and I'm
obsessed with getting them as rock-solid on cheap/free/old hardware as I'd
been able to get with my gigging and studio synths.
It physically pains me to hear audio stuttering because Apache is
running on the
same box. It seems an outrage to me. Shouldn't happen. Ever.
I used to record and mix multi-track songs in Ardour with tons of
soft-synths WHILE A KERNEL COMPILE WAS GOING ON THE SAME MACHINE without a
single glitch. I expect no less.
So I asked on the Liquidsoap list, and I got only shrugs and a pointer
to the
Gentoo page in response (why? I have no idea. I use Debian, and
that's irrelevant to the question at hand anyway.).
So what's the deal? Is there a way to give Ingo-approved preemptive RT
priority to things that aren't real-time apps and aren't specifically
architected for that? What, if anything, would break?
And, if I wanted to hack Liquidsoap (which would require learning ML,
which
wouldn't be a bad thing to know anyway), is it even possible to get
it RT-capable, or are there low-level C system calls required in order to
make that work?
Sorry for the long and obscure question, but it's been bothering me for
a
while, and I figured someone here would know the answer, or where I might
find it.
Thanks.
-ken
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
8 Dec
8 Dec
8:20 p.m.
On Sun, Dec 2, 2012 at 8:01 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
nice has absolutely nothing to do with this, and if it
has any effect, it is
accidental and should not be relied on.
I know that's your stock answer whenever someone mentions nice, but if
the OP is talking about SCHED_OTHER processes, nice does play a role.
But if the OP really wants to play with fire, try "chrt". Keep a
shell open with higher priority in case the process never blocks, so
you can kill it. "taskset" might also be useful for multicore
machines.
9:16 p.m.
On Sat, Dec 8, 2012 at 2:19 PM, Paul Coccoli <pcoccoli(a)gmail.com> wrote:
On Sun, Dec 2, 2012 at 8:01 PM, Paul Davis
<paul(a)linuxaudiosystems.com>
wrote:
nice alters the behaviour of scheduler with respect to SCHED_OTHER tasks
using an algorithm that is (almost) completely irrelevant for programs that
do very little interaction with the user and use most of their CPU time
streaming media.
applications that stream media should either (a) use enough buffering that
they do not run into xruns with respect to the delivery endpoint or (b) use
SCHED_FIFO/SCHED_RR (c) both. using nice is a bandaid that simply masks
design problems, if in fact it has the right effect at all.
nice has absolutely nothing to do with this, and
if it has any effect,
it is
accidental and should not be relied on.
I know that's your stock answer whenever someone mentions nice, but if
the OP is talking about SCHED_OTHER processes, nice does play a role.
4461
days inactive
4467
days old
linux-audio-user@lists.linuxaudio.org
10 comments
8 participants
participants (8)
-
Aaron Krister Johnson -
Harry van Haaren -
jim -
Ken Restivo -
Len Ovens -
Paul Coccoli -
Paul Davis -
Pedro Lopez-Cabanillas