I’ve reported audio drop outs when scrolling in the help
viewer under qnx rtp 6.1. io-graphics is starving other
processes.
The new patch does not solve this problem.
How can audio be reliable when processes running at
a higher priority use that much cpu time?
Is it normal for io-graphics to use that much cpu time
at such high a priority?
will/does qnx rtp support non-realtime scheduling? am
i right in thinking that might help solving this issue?
–martijn
martijn sipkema wrote:
I’ve reported audio drop outs when scrolling in the help
viewer under qnx rtp 6.1. io-graphics is starving other
processes.
The new patch does not solve this problem.How can audio be reliable when processes running at
a higher priority use that much cpu time?Is it normal for io-graphics to use that much cpu time
at such high a priority?will/does qnx rtp support non-realtime scheduling? am
i right in thinking that might help solving this issue?
io-graphis works with a priority of 12r … let the audio stuff also
run at 12r and set the ticksize to a smaller amount (1ms e.g. leads to a
smaller time slice).
Armin Steinhoff
–martijn
\
martijn sipkema wrote:
I’ve reported audio drop outs when scrolling in the help
viewer under qnx rtp 6.1. io-graphics is starving other
processes.
The new patch does not solve this problem.How can audio be reliable when processes running at
a higher priority use that much cpu time?Is it normal for io-graphics to use that much cpu time
at such high a priority?will/does qnx rtp support non-realtime scheduling? am
i right in thinking that might help solving this issue?
A more practical aproach 
Armin Steinhoff
–martijn
\
Armin Steinhoff <a-steinhoff@web_.de> wrote in message
news:3BCEC12B.5000100@web_.de…
martijn sipkema wrote:
I’ve reported audio drop outs when scrolling in the help
viewer under qnx rtp 6.1. io-graphics is starving other
processes.
The new patch does not solve this problem.How can audio be reliable when processes running at
a higher priority use that much cpu time?Is it normal for io-graphics to use that much cpu time
at such high a priority?will/does qnx rtp support non-realtime scheduling? am
i right in thinking that might help solving this issue?
A more practical aproach >
- open a terminal window
- pidin and look for your pid of your shell
- slay -P 30 sh … say yes for your shell
- start phplay at the command line → gives mpegaudio a priority of 30!
(the priority of mpegaudio seems to be the problem …)- start playing and listen to the dropout-free musik >
running mpegaudio at priority 30 might indeed solve the problem, but
i don’t think this is a long term solution. with a realtime scheduler like
rtp’s, some thought has to go in chosing the right priority for all
processes. if 10 is the normal priority, then io-graphics running at 12
schould not use a lot of cpu time. (at least on my system) it does however
consume up to about 80% or more when scrolling, especially with font
anti-aliasing always enabled, and the user interface becomes unresponsive
and audio output stops.
an audio player could use a normal priority thread to read data from the
disk and then decode it in a high priority thread. this would prevent
the player from starving other processes when decoding can’t be handled
by the cpu (which is more likely to happen with video).
but for this to work, processes running at a higher than normal priority
should not keep the cpu for too long. io-graphics does.
what does io-graphics do exactly? is it really necesary for it to use that
much cpu time at such high a priority?
–martijn
“martijn sipkema” <m.j.w.sipkema@student.tudelft.nl> wrote in message
news:9qmg16$as1$1@inn.qnx.com…
[cut]
what does io-graphics do exactly?
Handles all graphic operation 
If you have
a VGA card this is to be expected, with VGA CPU
has to do everything. For example if you scroll
a 800x600 windows one pixel at a time you are
actually moving around 500k of data. Again depending
on the video card, that data has to be read by
the CPU and written back somewhere else. That
means 500k read and 500k write. Then there is the
overhead of moving on VGA. Then add font redering.
I just tried it on a PC with an ATI 128 at 1280x1024x16.
I setup the helpviewer to take almost the entire screen.
I scrolled by pressing on the scroll bar arrow and got 25% CPU
usage use by io-graphics. I was expecting less but I guess
that’s ok.
If I pressed on the keyboard arrow key, scrolling wasn’t
much faster, but now io-graphics was taking 25% and
phFontFA taking another 25%. This is probably an issue
with the helpviewer itself.
Bottom line is with the combinaison of software and hardware
your have it takes 80% of the CPU 80% to scroll data.
To solve the sound and performance issue, play with priorities
or get different hardware.
Handles all graphic operation >
a VGA card this is to be expected, with VGA CPU
has to do everything. For example if you scroll
a 800x600 windows one pixel at a time you are
actually moving around 500k of data. Again depending
on the video card, that data has to be read by
the CPU and written back somewhere else. That
means 500k read and 500k write. Then there is the
overhead of moving on VGA. Then add font redering.I just tried it on a PC with an ATI 128 at 1280x1024x16.
I setup the helpviewer to take almost the entire screen.
I scrolled by pressing on the scroll bar arrow and got 25% CPU
usage use by io-graphics. I was expecting less but I guess
that’s ok.If I pressed on the keyboard arrow key, scrolling wasn’t
much faster, but now io-graphics was taking 25% and
phFontFA taking another 25%. This is probably an issue
with the helpviewer itself.Bottom line is with the combinaison of software and hardware
your have it takes 80% of the CPU 80% to scroll data.
To solve the sound and performance issue, play with priorities
or get different hardware.
scrolling shouldn’t use that much cpu normally since i think my matrox
g200 should support blitting from its framebuffer to another location in
the framebuffer. but even if it does use that much, why does io-graphics
have that high a priority? shouldn’t the default priorities for rtp be the
best solution? is it wise to have drawing done at 12?
i say this because apart from the audio problem the qnx photon gui isn’t
that responsive. i have used beos a lot, and that was much better, so there
must be some way to improve photon. when for instance dragging a window
with the default setting of drawing window content while doing so this
does not works as smoothly as on other operating systems or as should
be possible i think.
–martijn