Real SB16 trouble; reducing memory usage?

QNX Newsgroups (Archives) qdn.public.qnxrtp.newuser
1

Wow. I finally got the RtP to boot smoothly on a system I actually
own. (Hooray for the 6.1.0 release, or whatever it is that went up on
get.qnx.com over the summer…!) Anyone reading here who might’ve been
following the Phoenix Consortium’s list/IRC a year or so ago might know
what I mean… :wink:

Unfortunately, there are two problems. The first is that it’s a
P133/32MB, which I’ll get to in a minute; the second is that the closest
I own to a compatible soundcard is a Creative CT2290, one of the
original, pre-PnP SB16 models.

For further reference, information on the card can be found at:
http://asia.creative.com/support/specs/sound/sb16/ct2290.html

…and for context, I’m slowly acclimating to the way Neutrino handles
hardware detection, though I’m still a bit fuzzy. I think I’ve made
some sort of breakthough in having the sense to edit
/etc/system/enum/include/block to knock the disk cache down a bit - but
it seems io-audio is new for this release(??), and the deva-sb
executable mentioned a few thousand posts back no longer exists as such…

So now, the problem: the RtP does detect the card (configured to
all-defaults, as per the Creative site), but the mixer believes it’s a
CT1745 - and attempts to play MP3 or WAV result in rather ungraceful
lockups of phplay. (Slaying mpegaudio cures the former; I haven’t
figured out how to recover gracefully from the latter, as a slay phplay
or a kill -9 doesn’t seem to take effect)… I can ls /dev/snd and see a
few files, and, of course, plain (analog-passthrough) CD playing works,
and, perhaps importantly, the mixer manages to control the levels for
such, both the base and the CD levels…

Now, going from the ancient post from jamesm@qnx.com (‘Sound and video
problem’ thread, 11/27/2000), it sounds like the RtP is getting the
right port, but the interrupts and DMA settings just might be haywire.
io-audio seems to have precious little documentation, and there’s even
less for deva-ctrl-sb.so (which isn’t even listed in the io-audio help
page)… Anyone have a cure in mind, or know where to go from here?

I’d ship along some enum-* traps, if I knew which would provide the
right info.

Potentially important sidenote - there’s a generic ISA NE2000 card in
this box, on an address of “300,” IRQ 10, and a built-on PCI Trio64.

Now, all that said, I could also use a few suggestions on trimming
memory usage, such that useful stuff could actually be done on the box.
(RAM is cheap; unfortunately, EDO SIMMs aren’t, relatively speaking.)
I’ve knocked the EIDE cache down to 512k, made the Photon backdrop a
solid color, and switched to the tiny TCP/IP stack- what’s next? I
remember something said about adjusting the fontserver…

-In all cases, thanks in advance!
-Joe “Floid” Kanowitz

2

For the record, and anyone else looking here for help, here’s “Debugging
Non-PnP Sound for the Half-Clued,” and the trick to knocking down your
IDE cache for_real. Maybe this was all said on QNXStart.com, but it’s
down, so I had to learn the hard way. Hooray!

The “I’m not a complete idiot!”'s guide to debugging soundcard
trouble/adjusting settings on the fly:

#See if an audio driver/daemon is running…
ps -A | grep io-audio

#Slay it if it is
slay io-audio

#Restart io-audio with the settings you want to try
io-audio -d sb -oioport=0x220,irq=5,dma=1,dma1=5

Now, in determining your io-audio statement, have a look at the output
of ‘use io-audio’ - but how do you know the name of the driver, and how
do you know what options it accepts?

cd /x86/lib/dll
ls deva*

The part of the filenams between “deva-ctrl-” and “.so” lines is the
name of the driver, as far as io-audio is concerned.

To figure out what options you can pass, look in the
/etc/system/enum/devices/audio file. Search for the name of the driver
you want to load, and you’ll see a call to a mount() function. Look at
what it passes on the -o line to io-audio (remember, a ($variable) is a
variable, not an option :wink:), and you’ll get an idea of what you can
specify manually.

When it comes to reducing the size of the disk cache, you may find
yourself barking up the wrong tree. I found
/etc/system/enum/include/block, and figured the…
set(DEVB_OPTIONS, cam quiet blk “auto=partition,cache=512k”)
…line would have me golden. Not true!


See, QNX loads the disk block device as part of the boot process- long
before it reads that ‘include’ file.

So, gasp, we need to rebuild the “boot image!” Sounds painful, but in
reality, it’s even easier than recompiling a Linux or *BSD kernel.

Just cd /boot/build, and edit the file you want to use- qnxbasedma.build
if you’re doing fine with the basic install.

Find the startup-script section, and right above the call to diskboot
(looks like [pri=10o] PATH=/proc/boot diskboot -b1 -D1 -odevc-con,-n4),
insert these lines:

pci-bios
waitfor /dev/pci
devb-eide blk cache=1M
waitfor /dev/hd0

What we’re doing here is getting devb-eide loaded before diskboot does
it for us; that way, we get a chance to tell it we only want 1 meg of
disk cache, or whatever value you choose to specify. (Hint: the repeated
declarations of ‘pci-bios,’ ‘devb-eide,’ and ‘diskboot’ down at the
bottom of the file are include statements- they define what executables
get included in the image, and thus what you can run before you get
yourself access to something like a disk/filesystem/etc. :slight_smile:)

Now, you just save the file, and rebuild the boot image with a simple:

mkifs -v /boot/build/qnxbasedma.build /.boot

If nothing failed, give a reboot, and you’re set! You might want to
rebuild again calling devb-eide with the ‘cam quiet’ option, should the
boot output annoy you.

Mad props to cdm for explaining this to me!

General followup on the soundcard, for anyone who actually cares:

After much fooling around, I’m inclined to believe there’s a bug in
deva-ctrl-sb.so. I’ve no way to turn any ‘PnP OS’ option fully off
(Dell/AMI BIOS from the early Pentium era), but I have no other devices
that could rush in to conflict, unless something truly rude happens
during the boot process. (The SB16 in question appears to be proto-PnP;
Creative hasn’t archived a setup util, and it seems to steadfastly
work on 0x220/irq 5/dma 1,5 in DOS.)

The mixer detects the card as a CT1745, and it’s indeed driven by a
(revision) of that chip. The only thing I haven’t done is to try
every feasible dma combo, so while something might be happening there,
I’m inclined to believe the driver’s just having a bad year.

If anyone wants to get their mitts on this card for debugging purposes,
I’m willing to donate/loan it…

-Joe “Floid” Kanowitz