Re: A surprisingly stupid RT priority question

[Aaron Krister Johnson <aaron@xxxxxxxxxxxx>]

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

--
Aaron Krister Johnson
http://www.akjmusic.com
http://www.untwelve.org

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user