audio drop outs

i experience audio drop outs when scrolling large documents in
e.g. voyager. with anti-aliasing always on it is easy for the
drawing to starve the audio playback. how are the priorities
set? do all audio threads run at normal priority?

– martijn

io-audio’s interrupt thread is probably being pre-empted
by the hard disk driver. This has been fixed in cvs for a
couple of weeks, but is waiting for the next release to
filter out to the public. The default priority of io-audio’s
interrupt thread was changed from 15 (or 10 + 5) to 50 (absolute)
so that it is above the hard disk driver and network driver
threads (priority 21).

There is a work around that you could use in the meantime.
Try using nice or renice to bump up your io-audio process so that
its interrupt thread is higher than 21 and you should see your
audio hiccups go away.

root> slay io-audio
root> nice -n-9 io-audio -daudiopci &

or

root> pidin
(get io-audio’s pid and use it for the -p option)
root> renice -9 -p 20091

martijn sipkema <m.j.w.sipkema@student.tudelft.nl> wrote:

i experience audio drop outs when scrolling large documents in
e.g. voyager. with anti-aliasing always on it is easy for the
drawing to starve the audio playback. how are the priorities
set? do all audio threads run at normal priority?

– martijn

i tried renicing io-audio but that doesn’t help in my case. i doubt it is
the hard disk or the network since they aren’t really used. could it
be the media player not being able to supply the audio to io-audio?

– martijn


Audio Support <audio_support@qnx.com> wrote in message
news:9mga1r$pk7$1@nntp.qnx.com

io-audio’s interrupt thread is probably being pre-empted
by the hard disk driver. This has been fixed in cvs for a
couple of weeks, but is waiting for the next release to
filter out to the public. The default priority of io-audio’s
interrupt thread was changed from 15 (or 10 + 5) to 50 (absolute)
so that it is above the hard disk driver and network driver
threads (priority 21).

There is a work around that you could use in the meantime.
Try using nice or renice to bump up your io-audio process so that
its interrupt thread is higher than 21 and you should see your
audio hiccups go away.

root> slay io-audio
root> nice -n-9 io-audio -daudiopci &

or

root> pidin
(get io-audio’s pid and use it for the -p option)
root> renice -9 -p 20091

martijn sipkema <> m.j.w.sipkema@student.tudelft.nl> > wrote:
i experience audio drop outs when scrolling large documents in
e.g. voyager. with anti-aliasing always on it is easy for the
drawing to starve the audio playback. how are the priorities
set? do all audio threads run at normal priority?

– martijn

Probably not. How fast is your system?

E.


martijn sipkema <m.j.w.sipkema@student.tudelft.nl> wrote:

i tried renicing io-audio but that doesn’t help in my case. i doubt it is
the hard disk or the network since they aren’t really used. could it
be the media player not being able to supply the audio to io-audio?

– martijn



Audio Support <> audio_support@qnx.com> > wrote in message
news:9mga1r$pk7$> 1@nntp.qnx.com> …

io-audio’s interrupt thread is probably being pre-empted
by the hard disk driver. This has been fixed in cvs for a
couple of weeks, but is waiting for the next release to
filter out to the public. The default priority of io-audio’s
interrupt thread was changed from 15 (or 10 + 5) to 50 (absolute)
so that it is above the hard disk driver and network driver
threads (priority 21).

There is a work around that you could use in the meantime.
Try using nice or renice to bump up your io-audio process so that
its interrupt thread is higher than 21 and you should see your
audio hiccups go away.

root> slay io-audio
root> nice -n-9 io-audio -daudiopci &

or

root> pidin
(get io-audio’s pid and use it for the -p option)
root> renice -9 -p 20091

martijn sipkema <> m.j.w.sipkema@student.tudelft.nl> > wrote:
i experience audio drop outs when scrolling large documents in
e.g. voyager. with anti-aliasing always on it is easy for the
drawing to starve the audio playback. how are the priorities
set? do all audio threads run at normal priority?

– martijn

it’s an intel celeron 333 with 64mb ram. i will update this
sometime in the future, but this should be more than enough
to play one mp3 stream. i doesn’t use more than 10% of the
cpu time when just playing an mp3. yet only when i have a large
document open in the help viewer, and i drag the scrollbar up
and down, the system doesn’t respond smoothly and audio
stops. also the mouse pointer doesn’t move smoothly when i do
this. i wouldn’t expect the scrolling to be extremely smooth, but
i would expect the mouse the keep functioning normally under
these cirsumstances. hope this helps.

what priority does the thread reading the mp3 from disk run at?

– martijn

Hardware Support Account <hw@qnx.com> wrote in message
news:9miviq$g1q$1@nntp.qnx.com

Probably not. How fast is your system?

E.


martijn sipkema <> m.j.w.sipkema@student.tudelft.nl> > wrote:
i tried renicing io-audio but that doesn’t help in my case. i doubt it
is
the hard disk or the network since they aren’t really used. could it
be the media player not being able to supply the audio to io-audio?

– martijn


Audio Support <> audio_support@qnx.com> > wrote in message
news:9mga1r$pk7$> 1@nntp.qnx.com> …

io-audio’s interrupt thread is probably being pre-empted
by the hard disk driver. This has been fixed in cvs for a
couple of weeks, but is waiting for the next release to
filter out to the public. The default priority of io-audio’s
interrupt thread was changed from 15 (or 10 + 5) to 50 (absolute)
so that it is above the hard disk driver and network driver
threads (priority 21).

There is a work around that you could use in the meantime.
Try using nice or renice to bump up your io-audio process so that
its interrupt thread is higher than 21 and you should see your
audio hiccups go away.

root> slay io-audio
root> nice -n-9 io-audio -daudiopci &

or

root> pidin
(get io-audio’s pid and use it for the -p option)
root> renice -9 -p 20091

martijn sipkema <> m.j.w.sipkema@student.tudelft.nl> > wrote:
i experience audio drop outs when scrolling large documents in
e.g. voyager. with anti-aliasing always on it is easy for the
drawing to starve the audio playback. how are the priorities
set? do all audio threads run at normal priority?

– martijn
\

Hi Martijn,

Yes your system should be more than enough. What is the
version of the OS that you are currently running?

Thanks

E.


martijn sipkema <m.j.w.sipkema@student.tudelft.nl> wrote:

it’s an intel celeron 333 with 64mb ram. i will update this
sometime in the future, but this should be more than enough
to play one mp3 stream. i doesn’t use more than 10% of the
cpu time when just playing an mp3. yet only when i have a large
document open in the help viewer, and i drag the scrollbar up
and down, the system doesn’t respond smoothly and audio
stops. also the mouse pointer doesn’t move smoothly when i do
this. i wouldn’t expect the scrolling to be extremely smooth, but
i would expect the mouse the keep functioning normally under
these cirsumstances. hope this helps.

what priority does the thread reading the mp3 from disk run at?

– martijn

Hardware Support Account <> hw@qnx.com> > wrote in message
news:9miviq$g1q$> 1@nntp.qnx.com> …
Probably not. How fast is your system?

E.


martijn sipkema <> m.j.w.sipkema@student.tudelft.nl> > wrote:
i tried renicing io-audio but that doesn’t help in my case. i doubt it
is
the hard disk or the network since they aren’t really used. could it
be the media player not being able to supply the audio to io-audio?

– martijn


Audio Support <> audio_support@qnx.com> > wrote in message
news:9mga1r$pk7$> 1@nntp.qnx.com> …

io-audio’s interrupt thread is probably being pre-empted
by the hard disk driver. This has been fixed in cvs for a
couple of weeks, but is waiting for the next release to
filter out to the public. The default priority of io-audio’s
interrupt thread was changed from 15 (or 10 + 5) to 50 (absolute)
so that it is above the hard disk driver and network driver
threads (priority 21).

There is a work around that you could use in the meantime.
Try using nice or renice to bump up your io-audio process so that
its interrupt thread is higher than 21 and you should see your
audio hiccups go away.

root> slay io-audio
root> nice -n-9 io-audio -daudiopci &

or

root> pidin
(get io-audio’s pid and use it for the -p option)
root> renice -9 -p 20091

martijn sipkema <> m.j.w.sipkema@student.tudelft.nl> > wrote:
i experience audio drop outs when scrolling large documents in
e.g. voyager. with anti-aliasing always on it is easy for the
drawing to starve the audio playback. how are the priorities
set? do all audio threads run at normal priority?

– martijn
\

Hi,

allow me to say some words

martijn sipkema <m.j.w.sipkema@student.tudelft.nl> wrote in article <9mj0dv$soo$1@inn.qnx.com>…

it’s an intel celeron 333 with 64mb ram. i will update this
sometime in the future, but this should be more than enough
to play one mp3 stream. i doesn’t use more than 10% of the
cpu time when just playing an mp3. yet only when i have a large
document open in the help viewer, and i drag the scrollbar up
and down, the system doesn’t respond smoothly and audio
stops. also the mouse pointer doesn’t move smoothly when i do
this. i wouldn’t expect the scrolling to be extremely smooth, but
i would expect the mouse the keep functioning normally under
these cirsumstances. hope this helps.

I still have the same problem in QNX RTP 6.0 A,B,C and 6.1 GA. And more, under those circumstances
(drag the scrollbar) my mouse goes to madness: mouse cursor jumps to other position on the screen,
sometimes chaotic event occurs - resize of window, context menu appears, window jumps to other
position and so on. Of course, sound drops if phplay is launched. This seems to be in Package
Manager too for QNX RTP 6.1 GA.
Yes, I heard my system is too slow for QNX, it is p166mmx 64mb ram, I don’t beleave that. Another
OSes work maybe slow but predictable :wink:

Eduard.

6.1


Hardware Support Account <hw@qnx.com> wrote in message
news:9mj811$lck$1@nntp.qnx.com

Hi Martijn,

Yes your system should be more than enough. What is the
version of the OS that you are currently running?

Thanks

E.


martijn sipkema <> m.j.w.sipkema@student.tudelft.nl> > wrote:
it’s an intel celeron 333 with 64mb ram. i will update this
sometime in the future, but this should be more than enough
to play one mp3 stream. i doesn’t use more than 10% of the
cpu time when just playing an mp3. yet only when i have a large
document open in the help viewer, and i drag the scrollbar up
and down, the system doesn’t respond smoothly and audio
stops. also the mouse pointer doesn’t move smoothly when i do
this. i wouldn’t expect the scrolling to be extremely smooth, but
i would expect the mouse the keep functioning normally under
these cirsumstances. hope this helps.

what priority does the thread reading the mp3 from disk run at?

– martijn

Hardware Support Account <> hw@qnx.com> > wrote in message
news:9miviq$g1q$> 1@nntp.qnx.com> …
Probably not. How fast is your system?

E.


martijn sipkema <> m.j.w.sipkema@student.tudelft.nl> > wrote:
i tried renicing io-audio but that doesn’t help in my case. i doubt
it
is
the hard disk or the network since they aren’t really used. could it
be the media player not being able to supply the audio to io-audio?

– martijn


Audio Support <> audio_support@qnx.com> > wrote in message
news:9mga1r$pk7$> 1@nntp.qnx.com> …

io-audio’s interrupt thread is probably being pre-empted
by the hard disk driver. This has been fixed in cvs for a
couple of weeks, but is waiting for the next release to
filter out to the public. The default priority of io-audio’s
interrupt thread was changed from 15 (or 10 + 5) to 50 (absolute)
so that it is above the hard disk driver and network driver
threads (priority 21).

There is a work around that you could use in the meantime.
Try using nice or renice to bump up your io-audio process so that
its interrupt thread is higher than 21 and you should see your
audio hiccups go away.

root> slay io-audio
root> nice -n-9 io-audio -daudiopci &

or

root> pidin
(get io-audio’s pid and use it for the -p option)
root> renice -9 -p 20091

martijn sipkema <> m.j.w.sipkema@student.tudelft.nl> > wrote:
i experience audio drop outs when scrolling large documents in
e.g. voyager. with anti-aliasing always on it is easy for the
drawing to starve the audio playback. how are the priorities
set? do all audio threads run at normal priority?

– martijn


\

renicing the mpegaudio process with 3 solves the problem. i think
it is being starved by io-graphics running at 12.

– martijn

Hardware Support Account <hw@qnx.com> wrote in message
news:9mj811$lck$1@nntp.qnx.com

Hi Martijn,

Yes your system should be more than enough. What is the
version of the OS that you are currently running?

Thanks

E.


martijn sipkema <> m.j.w.sipkema@student.tudelft.nl> > wrote:
it’s an intel celeron 333 with 64mb ram. i will update this
sometime in the future, but this should be more than enough
to play one mp3 stream. i doesn’t use more than 10% of the
cpu time when just playing an mp3. yet only when i have a large
document open in the help viewer, and i drag the scrollbar up
and down, the system doesn’t respond smoothly and audio
stops. also the mouse pointer doesn’t move smoothly when i do
this. i wouldn’t expect the scrolling to be extremely smooth, but
i would expect the mouse the keep functioning normally under
these cirsumstances. hope this helps.

what priority does the thread reading the mp3 from disk run at?

– martijn

Hardware Support Account <> hw@qnx.com> > wrote in message
news:9miviq$g1q$> 1@nntp.qnx.com> …
Probably not. How fast is your system?

E.


martijn sipkema <> m.j.w.sipkema@student.tudelft.nl> > wrote:
i tried renicing io-audio but that doesn’t help in my case. i doubt
it
is
the hard disk or the network since they aren’t really used. could it
be the media player not being able to supply the audio to io-audio?

– martijn


Audio Support <> audio_support@qnx.com> > wrote in message
news:9mga1r$pk7$> 1@nntp.qnx.com> …

io-audio’s interrupt thread is probably being pre-empted
by the hard disk driver. This has been fixed in cvs for a
couple of weeks, but is waiting for the next release to
filter out to the public. The default priority of io-audio’s
interrupt thread was changed from 15 (or 10 + 5) to 50 (absolute)
so that it is above the hard disk driver and network driver
threads (priority 21).

There is a work around that you could use in the meantime.
Try using nice or renice to bump up your io-audio process so that
its interrupt thread is higher than 21 and you should see your
audio hiccups go away.

root> slay io-audio
root> nice -n-9 io-audio -daudiopci &

or

root> pidin
(get io-audio’s pid and use it for the -p option)
root> renice -9 -p 20091

martijn sipkema <> m.j.w.sipkema@student.tudelft.nl> > wrote:
i experience audio drop outs when scrolling large documents in
e.g. voyager. with anti-aliasing always on it is easy for the
drawing to starve the audio playback. how are the priorities
set? do all audio threads run at normal priority?

– martijn


\

Hi,
Renicing the mpegaudio process makes a trick, but mpegaudio process priority resets to original
value (10) when phplay plays every next mpeg file from the playlist :frowning:. I hope this issue will be
solved in the next patch.
Regards,
Eduard.

martijn sipkema <m.j.w.sipkema@student.tudelft.nl> wrote in article <9mlj9i$heg$1@inn.qnx.com>…

renicing the mpegaudio process with 3 solves the problem. i think
it is being starved by io-graphics running at 12.

– martijn

Hi,
I’ve found curious thing. I launch phplay to play mpeg file, then I launch helpviewer. Then I drag
the scrollbar up and down. It causes audio drop out and… increase of volume. I guess +3 db
minimum :wink:. It happens only first time (the second drop out does not increase the volume of this
mpeg audio) and only for phplay (I’ve tried plaympegaudio_noph: audio drop outs but volume does not
increase). I cannot imagine any explanation of this effect. My soundcard is PCI Creative Live, it’s
autodetected by QNX RTP 6.0 A and works fine under pathes B, C and 6.1 GA.
Regards,
Eduard.

“ed1k” <ed1k@yahoo.com> wrote in message
news:01c131f6$82dfb7a0$396fa8c0@ED1K…

Hi,
I’ve found curious thing. I launch phplay to play mpeg file, then I launch
helpviewer. Then I drag
the scrollbar up and down. It causes audio drop out and… increase of
volume. I guess +3 db
minimum > :wink:> . It happens only first time (the second drop out does not
increase the volume of this
mpeg audio) and only for phplay (I’ve tried plaympegaudio_noph: audio drop
outs but volume does not
increase). I cannot imagine any explanation of this effect. My soundcard
is PCI Creative Live, it’s
autodetected by QNX RTP 6.0 A and works fine under pathes B, C and 6.1 GA.

It could be that SBlive reloads some ‘volume control’ register in the
prepare() entry point (which gets called on every ‘drop out’ or UNDERRUN in
driver terms). I had this very effect in Maestro driver when ported it…

  • igor

Hi Martijn.
You said it!
Indeed, renice 2 -p <pid of “io-graphics”> makes my system nice. Mouse cursor freezes and jumps
when I drag the scrollbar. But cursor jumps to the right place and I have no chaotic events.

Cheers,
Eduard.

martijn sipkema <m.j.w.sipkema@student.tudelft.nl> wrote in article <9mlj9i$heg$1@inn.qnx.com>…

renicing the mpegaudio process with 3 solves the problem. i think
it is being starved by io-graphics running at 12.

– martijn