Re: [linux-audio-dev] Linux 2.6 not a latency panacea?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Linux 2.6 not a latency panacea?
From: Roger Larsson (roger.larsson_AT_norran.net)
Date: Thu Aug 14 2003 - 02:34:59 EEST


On Thursday 14 August 2003 00.09, Joshua Haberman wrote:
> I am distressed. It was my understanding that the 2.5/2.6 kernel branch
> was undergoing significant scheduler and latency work, and that 2.6
> would eliminate the kernel from the list of obstacles of low-latency on
> Linux. It will have the preemptable kernel patch, the new scheduler,
> and all of Ingo Molnar's low-latency work. Claims were being thrown
> around that 2.6 would be the lowest-latency operating system on the planet.
>
> So how is it that we're in the 2.6.0-test series and people are
> complaining about audio skipping in **XMMS**, which uses three second
> buffers by default?? If people are getting skips from high-latency
> playback, what hope is there for low-latency audio? A series of patches
> are coming from both Ingo and Con Kolivas attempting to address this,
> but the fact they are just now throwing around potential solutions
> erodes at my faith that they really understand the problem or how to
> solve it.
>
> Is 2.6.x going to be suitable for low-latency (or even reliable
> high-latency) audio? Or is it going to be more of the same: patching
> the kernel, tweaking parameters, reading magical incantations, and
> hoping for the best?
>
> Reassure me please!
>
> Josh

This is when running the default scheduler (as non root / non suid root).
Then you are not allowed to use SCHED_FIFO nor SCHED_RR

The problem such a process might run into is if it needs service or
a resource held by a blocked process...

BTW
        There have been discussions about a new scheduling class
        SCHED_SOFTRR. It would be available for all users.
        But the total usage would be limited.

        If SCHED_SOFTRR were overused those processes would run
        out of their timeslice (SCHED_RR never runs out of their timeslice)

        I think this feature would be pretty cool! And adding this for
        latency sensitive bandwith limited streaming applications could
        simplify lots of stuff for the default scheduler...

/RogerL

-- 
Roger Larsson
Skellefteċ
Sweden


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Aug 14 2003 - 02:33:46 EEST