[LAU] A surprisingly stupid RT priority question

[Aaron Krister Johnson]

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 at restivo.org> wrote:

> 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:
> > > 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.
> >
>
>
> 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 at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-user
>



-- 
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20121203/9600c001/attachment.html>