Have you seen...audio problem?

QNX Newsgroups (Archives) qdn.public.qnx4
1

Hello there,

I’m looking at my code, but this seems like an odd problem, and
with all the audio issues I’ve had, I wanted to check to see
if anyone else has dealt with this (ie. could it be the QNX
audio driver).

My audio interface uses the QNX audio driver to generate sound.
I’m playing WAV files. It works just fine except when it’s left
playing a sound overnight. This is very repeatable, but takes
a while to do (6 hrs). When it’s left on overnight, the QNX system
is slow and the mouse is jerky in the morning. There is no
audio coming from the system though there should be. It should be
playing
an alarm sound over and over. When the program is terminated, the
QNX system comes back to life (full speed).

Output from “sac” indicates that only priority 10 and 31 are getting
CPU time with 10 getting 20-30%. Audio and the interface of mine
are priority 10.

ps indicates that audioTsk (my interface) is in the REPLY state
blocked on “Audio sb -i7” the audio driver which is in the READY
state.

‘*’ marks the Audio and audio interface task (some content snipped)

sin -n3 format ntbp

PROGRAM START TIME UTIME STIME CUTIME CSTIME STATE
BLK PRI
sys/Proc32 Sep 18 15:24 2.450 0.630 1.870 0.720 READY
— 30f
sys/Slib32 — – --:-- 0.000 0.000 0.000 0.000
RECV 0 10r
/bin/Net — – --:-- 6.110 0.930 0.000 0.000 READY
— 23r
/bin/Net.ether2100 — – --:-- 0.000 0.000 0.000 0.000
RECV 0 20r
idle — – --:-- 24452 0.140 0.000 0.000 READY
— 0r
//4/bin/Dev32 Sep 18 15:24 0.100 0.040 0.000 0.000
RECV 0 24f
//4/bin/Pipe Sep 18 15:24 0.000 0.000 0.000 0.000
RECV 0 10r
//4/bin/Fsys Sep 18 15:24 0.040 0.010 0.000 0.000
RECV 0 22r
//4/bin/Fsys.eide Sep 18 15:24 11.049 0.000 0.000 0.000
RECV 0 22r
//4/bin/ksh Sep 18 15:24 0.020 0.010 0.040 0.210
REPLY 40 10o
//4/bin/Audio Sep 18 15:25 14272 28986 0.000 0.000 READY
— 10r *
//4//photon/bin/Photon Sep 18 15:25 0.730 0.290 0.000 0.000
RECV 0 17r
//4/bin/Input Sep 18 15:25 0.100 0.070 0.000 0.000
RECV 0 12o
//4//app/audioTsk Sep 18 15:26 0.040 0.000 0.000 0.000 REPLY
214 10o *

Looks like the audioTsk is waiting on Audio to respond, but Audio forgot
it
needed to respond. Sound right?

I also tried to ‘cat’ a file to /dev/dsp and the audioTsk’s state went
to SIGBL.

If you have any ideas or similar experiences, I’d love to know.

Thanks in advance,
Barry

2

Barry Robertson <brobertson@softwareremodeling.com> wrote:

Hello there,

I’m looking at my code, but this seems like an odd problem, and
with all the audio issues I’ve had, I wanted to check to see
if anyone else has dealt with this (ie. could it be the QNX
audio driver).

it is very likely the Audio driver.

please look at the binaries in /usr/free/qnx4/multimedia/ALSA2
grab the alsa-bin-qnx-0.2.tgz* files and try them out.

these are the recommended drivers for qnx4…
just be aware of the gpl license issues… we provide the src so you can use
the driver and utilities and also keep the src in a safe spot on your
system in case anyone wants to see it.

–
Randy Martin email: randy@qnx.com www.qnx.com
QNX Software Systems Ltd. QUICS: randy (613) 591-0934 (data)
(613) 591-0931 x287 (voice) mail: 175 Terence Matthews Cr
(613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8

3

“Randy Martin” <randy@qnx.com> wrote in message
news:8q83s7$p5$1@nntp.qnx.com…

Barry Robertson <> brobertson@softwareremodeling.com> > wrote:

Hello there,

I’m looking at my code, but this seems like an odd problem, and
with all the audio issues I’ve had, I wanted to check to see
if anyone else has dealt with this (ie. could it be the QNX
audio driver).

it is very likely the Audio driver.

please look at the binaries in /usr/free/qnx4/multimedia/ALSA2
grab the alsa-bin-qnx-0.2.tgz* files and try them out.

these are the recommended drivers for qnx4…

I don’t know if it was fix, but SoundBlaster 8 bit didn’t work.

just be aware of the gpl license issues… we provide the src so you can
use
the driver and utilities and also keep the src in a safe spot on your
system in case anyone wants to see it.

–
Randy Martin email: > randy@qnx.com > > www.qnx.com
QNX Software Systems Ltd. QUICS: randy (613) 591-0934 (data)
(613) 591-0931 x287 (voice) mail: 175 Terence Matthews Cr
(613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8

4

I’ve heard of a simpilar problem. The smaller the Audio
block size, the sooner the problem repeats. Closing and
reopening /dev/dsp nullifies the problem.


Previously, Barry Robertson wrote in qdn.public.qnx4:

Hello there,

I’m looking at my code, but this seems like an odd problem, and
with all the audio issues I’ve had, I wanted to check to see
if anyone else has dealt with this (ie. could it be the QNX
audio driver).

My audio interface uses the QNX audio driver to generate sound.
I’m playing WAV files. It works just fine except when it’s left
playing a sound overnight. This is very repeatable, but takes
a while to do (6 hrs). When it’s left on overnight, the QNX system
is slow and the mouse is jerky in the morning. There is no
audio coming from the system though there should be. It should be
playing
an alarm sound over and over. When the program is terminated, the
QNX system comes back to life (full speed).

Output from “sac” indicates that only priority 10 and 31 are getting
CPU time with 10 getting 20-30%. Audio and the interface of mine
are priority 10.

ps indicates that audioTsk (my interface) is in the REPLY state
blocked on “Audio sb -i7” the audio driver which is in the READY
state.

‘*’ marks the Audio and audio interface task (some content snipped)

sin -n3 format ntbp

PROGRAM START TIME UTIME STIME CUTIME CSTIME STATE
BLK PRI
sys/Proc32 Sep 18 15:24 2.450 0.630 1.870 0.720 READY
— 30f
sys/Slib32 — – --:-- 0.000 0.000 0.000 0.000
RECV 0 10r
/bin/Net — – --:-- 6.110 0.930 0.000 0.000 READY
— 23r
/bin/Net.ether2100 — – --:-- 0.000 0.000 0.000 0.000
RECV 0 20r
idle — – --:-- 24452 0.140 0.000 0.000 READY
— 0r
//4/bin/Dev32 Sep 18 15:24 0.100 0.040 0.000 0.000
RECV 0 24f
//4/bin/Pipe Sep 18 15:24 0.000 0.000 0.000 0.000
RECV 0 10r
//4/bin/Fsys Sep 18 15:24 0.040 0.010 0.000 0.000
RECV 0 22r
//4/bin/Fsys.eide Sep 18 15:24 11.049 0.000 0.000 0.000
RECV 0 22r
//4/bin/ksh Sep 18 15:24 0.020 0.010 0.040 0.210
REPLY 40 10o
//4/bin/Audio Sep 18 15:25 14272 28986 0.000 0.000 READY
— 10r *
//4//photon/bin/Photon Sep 18 15:25 0.730 0.290 0.000 0.000
RECV 0 17r
//4/bin/Input Sep 18 15:25 0.100 0.070 0.000 0.000
RECV 0 12o
//4//app/audioTsk Sep 18 15:26 0.040 0.000 0.000 0.000 REPLY
214 10o *

Looks like the audioTsk is waiting on Audio to respond, but Audio forgot
it
needed to respond. Sound right?

I also tried to ‘cat’ a file to /dev/dsp and the audioTsk’s state went
to SIGBL.

If you have any ideas or similar experiences, I’d love to know.

Thanks in advance,
Barry

–
Mitchell Schoenbrun --------- maschoen@pobox.com

5

I have heard this problem appears when an internal counter
for DMA related stuff wrap around 65535. So if this
what is happening there isn’t much you can do about it aside
give a try to ALSA

“Mitchell Schoenbrun” <maschoen@pobox.com> wrote in message
news:Voyager.000919122325.15300D@schoenbrun.com…

I’ve heard of a simpilar problem. The smaller the Audio
block size, the sooner the problem repeats. Closing and
reopening /dev/dsp nullifies the problem.


Previously, Barry Robertson wrote in qdn.public.qnx4:

Hello there,

I’m looking at my code, but this seems like an odd problem, and
with all the audio issues I’ve had, I wanted to check to see
if anyone else has dealt with this (ie. could it be the QNX
audio driver).

My audio interface uses the QNX audio driver to generate sound.
I’m playing WAV files. It works just fine except when it’s left
playing a sound overnight. This is very repeatable, but takes
a while to do (6 hrs). When it’s left on overnight, the QNX system
is slow and the mouse is jerky in the morning. There is no
audio coming from the system though there should be. It should be
playing
an alarm sound over and over. When the program is terminated, the
QNX system comes back to life (full speed).

Output from “sac” indicates that only priority 10 and 31 are getting
CPU time with 10 getting 20-30%. Audio and the interface of mine
are priority 10.

ps indicates that audioTsk (my interface) is in the REPLY state
blocked on “Audio sb -i7” the audio driver which is in the READY
state.

‘*’ marks the Audio and audio interface task (some content snipped)

sin -n3 format ntbp

PROGRAM START TIME UTIME STIME CUTIME CSTIME STATE
BLK PRI
sys/Proc32 Sep 18 15:24 2.450 0.630 1.870 0.720 READY
— 30f
sys/Slib32 — – --:-- 0.000 0.000 0.000 0.000
RECV 0 10r
/bin/Net — – --:-- 6.110 0.930 0.000 0.000 READY
— 23r
/bin/Net.ether2100 — – --:-- 0.000 0.000 0.000 0.000
RECV 0 20r
idle — – --:-- 24452 0.140 0.000 0.000 READY
— 0r
//4/bin/Dev32 Sep 18 15:24 0.100 0.040 0.000 0.000
RECV 0 24f
//4/bin/Pipe Sep 18 15:24 0.000 0.000 0.000 0.000
RECV 0 10r
//4/bin/Fsys Sep 18 15:24 0.040 0.010 0.000 0.000
RECV 0 22r
//4/bin/Fsys.eide Sep 18 15:24 11.049 0.000 0.000 0.000
RECV 0 22r
//4/bin/ksh Sep 18 15:24 0.020 0.010 0.040 0.210
REPLY 40 10o
//4/bin/Audio Sep 18 15:25 14272 28986 0.000 0.000 READY
— 10r *
//4//photon/bin/Photon Sep 18 15:25 0.730 0.290 0.000 0.000
RECV 0 17r
//4/bin/Input Sep 18 15:25 0.100 0.070 0.000 0.000
RECV 0 12o
//4//app/audioTsk Sep 18 15:26 0.040 0.000 0.000 0.000 REPLY
214 10o *

Looks like the audioTsk is waiting on Audio to respond, but Audio forgot
it
needed to respond. Sound right?

I also tried to ‘cat’ a file to /dev/dsp and the audioTsk’s state went
to SIGBL.

If you have any ideas or similar experiences, I’d love to know.

Thanks in advance,
Barry

\

Mitchell Schoenbrun --------- > maschoen@pobox.com

6

Hi guys, thanks for the responses. Here’s an update. I’ve
tried it three times, and it failed every time still. I tried
a few things, one of which was to put printouts “#in” “#out”
after all writes to /dev/dsp it goes into fwrite() and
never comes out.

Now, I followed Mitchell’s suggestion and put a counter in
the function which writes the buffer (which is 4096 bytes)
so that every 64000 times it closes /dev/dsp and reopens
it. Sadly that didn’t work. Is 64000 way too much? I’ll
try something smaller this morning.

Will I be able to substitute ALSA drivers for Audio
without code modifications on my end (well, obviously
the IOCTL calls will change, but can I still fwrite()
to the device). I considered it before but felt it
was too much trouble for what I needed. I’d like to find
a work-around for Audio.

Thanks again for your help,
Barry

Mario Charest wrote:

I have heard this problem appears when an internal counter
for DMA related stuff wrap around 65535. So if this
what is happening there isn’t much you can do about it aside
give a try to ALSA

“Mitchell Schoenbrun” <> maschoen@pobox.com> > wrote in message
news:> Voyager.000919122325.15300D@schoenbrun.com> …
I’ve heard of a simpilar problem. The smaller the Audio
block size, the sooner the problem repeats. Closing and
reopening /dev/dsp nullifies the problem.


Previously, Barry Robertson wrote in qdn.public.qnx4:

Hello there,

I’m looking at my code, but this seems like an odd problem, and
with all the audio issues I’ve had, I wanted to check to see
if anyone else has dealt with this (ie. could it be the QNX
audio driver).

My audio interface uses the QNX audio driver to generate sound.
I’m playing WAV files. It works just fine except when it’s left
playing a sound overnight. This is very repeatable, but takes
a while to do (6 hrs). When it’s left on overnight, the QNX system
is slow and the mouse is jerky in the morning. There is no
audio coming from the system though there should be. It should be
playing
an alarm sound over and over. When the program is terminated, the
QNX system comes back to life (full speed).

Output from “sac” indicates that only priority 10 and 31 are getting
CPU time with 10 getting 20-30%. Audio and the interface of mine
are priority 10.

ps indicates that audioTsk (my interface) is in the REPLY state
blocked on “Audio sb -i7” the audio driver which is in the READY
state.

‘*’ marks the Audio and audio interface task (some content snipped)

sin -n3 format ntbp

PROGRAM START TIME UTIME STIME CUTIME CSTIME STATE
BLK PRI
sys/Proc32 Sep 18 15:24 2.450 0.630 1.870 0.720 READY
— 30f
sys/Slib32 — – --:-- 0.000 0.000 0.000 0.000
RECV 0 10r
/bin/Net — – --:-- 6.110 0.930 0.000 0.000 READY
— 23r
/bin/Net.ether2100 — – --:-- 0.000 0.000 0.000 0.000
RECV 0 20r
idle — – --:-- 24452 0.140 0.000 0.000 READY
— 0r
//4/bin/Dev32 Sep 18 15:24 0.100 0.040 0.000 0.000
RECV 0 24f
//4/bin/Pipe Sep 18 15:24 0.000 0.000 0.000 0.000
RECV 0 10r
//4/bin/Fsys Sep 18 15:24 0.040 0.010 0.000 0.000
RECV 0 22r
//4/bin/Fsys.eide Sep 18 15:24 11.049 0.000 0.000 0.000
RECV 0 22r
//4/bin/ksh Sep 18 15:24 0.020 0.010 0.040 0.210
REPLY 40 10o
//4/bin/Audio Sep 18 15:25 14272 28986 0.000 0.000 READY
— 10r *
//4//photon/bin/Photon Sep 18 15:25 0.730 0.290 0.000 0.000
RECV 0 17r
//4/bin/Input Sep 18 15:25 0.100 0.070 0.000 0.000
RECV 0 12o
//4//app/audioTsk Sep 18 15:26 0.040 0.000 0.000 0.000 REPLY
214 10o *

Looks like the audioTsk is waiting on Audio to respond, but Audio forgot
it
needed to respond. Sound right?

I also tried to ‘cat’ a file to /dev/dsp and the audioTsk’s state went
to SIGBL.

If you have any ideas or similar experiences, I’d love to know.

Thanks in advance,
Barry

\

Mitchell Schoenbrun --------- > maschoen@pobox.com
\

–

.
/ /_ \ | Barry Robertson
_ \ | / | Software Consultant
/ \ | | \ | Software Remodeling, Inc.
/ / || /__| brobertson@SoftwareRemodeling.com
/ / Phone: 972-758-9349 Fax: 972-964-7524

7

Previously, Barry Robertson wrote in qdn.public.qnx4:

Now, I followed Mitchell’s suggestion and put a counter in
the function which writes the buffer (which is 4096 bytes)
so that every 64000 times it closes /dev/dsp and reopens
it. Sadly that didn’t work. Is 64000 way too much? I’ll
try something smaller this morning.

Note that I only heard about this problem. I didn’t test
this stuff myself. 64000 does sound like a lot to
conclude that this in not the problem. I’d try it every
10 as an experiment. If the problem goes away you can
figure out where the threshold is.

Mitchell Schoenbrun --------- maschoen@pobox.com

8

Unfortunately ALSA drivers would require code modifications. I don’t
believe /dev/dsp is available and you would be using other control functions
to produce the correct results. I prefer the ALSA drivers over the QNX
Audio drivers, they provide more functionality overall and are not that
difficult to use. I myself had problems with the QNX Audio driver failing
after about 51 minutes (I called it the “51 minute bug” because it seemed to
reproduce itself every 51 minutes or so). Then the good ol boys at QNX
suggested the ALSA drivers, and they were fantastic.

For more information on ALSA drivers (API, documentation, etc) visit
http://www.alsa-project.org

R B Adler

“Barry Robertson” <brobertson@SoftwareRemodeling.com> wrote in message
news:39C8B1E5.21341A0E@SoftwareRemodeling.com…

Hi guys, thanks for the responses. Here’s an update. I’ve
tried it three times, and it failed every time still. I tried
a few things, one of which was to put printouts “#in” “#out”
after all writes to /dev/dsp it goes into fwrite() and
never comes out.

Now, I followed Mitchell’s suggestion and put a counter in
the function which writes the buffer (which is 4096 bytes)
so that every 64000 times it closes /dev/dsp and reopens
it. Sadly that didn’t work. Is 64000 way too much? I’ll
try something smaller this morning.

Will I be able to substitute ALSA drivers for Audio
without code modifications on my end (well, obviously
the IOCTL calls will change, but can I still fwrite()
to the device). I considered it before but felt it
was too much trouble for what I needed. I’d like to find
a work-around for Audio.

Thanks again for your help,
Barry

Mario Charest wrote:

I have heard this problem appears when an internal counter
for DMA related stuff wrap around 65535. So if this
what is happening there isn’t much you can do about it aside
give a try to ALSA

“Mitchell Schoenbrun” <> maschoen@pobox.com> > wrote in message
news:> Voyager.000919122325.15300D@schoenbrun.com> …
I’ve heard of a simpilar problem. The smaller the Audio
block size, the sooner the problem repeats. Closing and
reopening /dev/dsp nullifies the problem.


Previously, Barry Robertson wrote in qdn.public.qnx4:

Hello there,

I’m looking at my code, but this seems like an odd problem, and
with all the audio issues I’ve had, I wanted to check to see
if anyone else has dealt with this (ie. could it be the QNX
audio driver).

My audio interface uses the QNX audio driver to generate sound.
I’m playing WAV files. It works just fine except when it’s left
playing a sound overnight. This is very repeatable, but takes
a while to do (6 hrs). When it’s left on overnight, the QNX system
is slow and the mouse is jerky in the morning. There is no
audio coming from the system though there should be. It should be
playing
an alarm sound over and over. When the program is terminated, the
QNX system comes back to life (full speed).

Output from “sac” indicates that only priority 10 and 31 are getting
CPU time with 10 getting 20-30%. Audio and the interface of mine
are priority 10.

ps indicates that audioTsk (my interface) is in the REPLY state
blocked on “Audio sb -i7” the audio driver which is in the READY
state.

‘*’ marks the Audio and audio interface task (some content snipped)

sin -n3 format ntbp

PROGRAM START TIME UTIME STIME CUTIME CSTIME
STATE
BLK PRI
sys/Proc32 Sep 18 15:24 2.450 0.630 1.870 0.720
READY
— 30f
sys/Slib32 — – --:-- 0.000 0.000 0.000 0.000
RECV 0 10r
/bin/Net — – --:-- 6.110 0.930 0.000 0.000
READY
— 23r
/bin/Net.ether2100 — – --:-- 0.000 0.000 0.000 0.000
RECV 0 20r
idle — – --:-- 24452 0.140 0.000 0.000
READY
— 0r
//4/bin/Dev32 Sep 18 15:24 0.100 0.040 0.000 0.000
RECV 0 24f
//4/bin/Pipe Sep 18 15:24 0.000 0.000 0.000 0.000
RECV 0 10r
//4/bin/Fsys Sep 18 15:24 0.040 0.010 0.000 0.000
RECV 0 22r
//4/bin/Fsys.eide Sep 18 15:24 11.049 0.000 0.000 0.000
RECV 0 22r
//4/bin/ksh Sep 18 15:24 0.020 0.010 0.040 0.210
REPLY 40 10o
//4/bin/Audio Sep 18 15:25 14272 28986 0.000 0.000
READY
— 10r *
//4//photon/bin/Photon Sep 18 15:25 0.730 0.290 0.000 0.000
RECV 0 17r
//4/bin/Input Sep 18 15:25 0.100 0.070 0.000 0.000
RECV 0 12o
//4//app/audioTsk Sep 18 15:26 0.040 0.000 0.000 0.000
REPLY
214 10o *

Looks like the audioTsk is waiting on Audio to respond, but Audio
forgot
it
needed to respond. Sound right?

I also tried to ‘cat’ a file to /dev/dsp and the audioTsk’s state
went
to SIGBL.

If you have any ideas or similar experiences, I’d love to know.

Thanks in advance,
Barry

\

Mitchell Schoenbrun --------- > maschoen@pobox.com



\

.
/ /_ \ | Barry Robertson
_ \ | / | Software Consultant
/ \ | | \ | Software Remodeling, Inc.
/ / || /__| > brobertson@SoftwareRemodeling.com
/ / Phone: 972-758-9349 Fax: 972-964-7524