Hi,
I tried playing a mp3 with noatun via artsd. Starting dbench 32 I get the
same kind of dropouts - and no indication with my latency profiling patch =>
no process with higher prio is waiting to run!
One of noatun or artsd is waiting for something else! (That is why I included
Stefan Westerfeld... artsd)
I noticed very nice improvement then reniceing (all) artsd and noatun.
(I did also change the buffer size in artsd down to 40 ms)
(This part most for Stefan...
So I thought - lets try to run artsd with RT prio - changed the option
HOW can it get RT prio when it is not suid? I guess it can not...
So I manually added suid bit - but then noatun could not connect with
artsd... bug?, backed out the suid change... but is behaves as it works,
could be that it has so short bursts that prio never get a chance to drop)
I have been doing some stracing but on noatun. It does some strange things...
It does some non blocking IO...
Then I tried to run Bennos latencytest, with generated output (sine).
pages locked, SCHED_FIFO prio - killed artsd before testing... (so it won't
do secondary buffering)
Result - did only get some very short skips.
Let artsd start - tried again after artsd had started.
Still getting very good results - I have a SB Live (kernel),
it can mix on board...
am I using that or do the sound pass artsd in all cases???
My conclusion is that it is noatun that is waiting for something.
Maybe the priorities can be the cause:
noatun runs => priority goes down over time (increased when all running
processes has zero prio)
many dbench some with more prio than noatun => blocks the bursty, but CPU
consuming, noatun
=> dropouts...
Look at top - one artsd stays on top (of top). But noatun drops...
dbenches comes and goes in between...
If this analysis is correct:
We really need to run RT processes with RT priorities!
It is also possible that multimedia applications needs to be rewritten to
this new situation, i.e. remove some workarounds...
/RogerL
-- Roger Larsson Skellefteå Sweden - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/