3 Dec
2012
3 Dec
'12
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