PAS-16 is half-baked?
Mike Isely
This past two weeks, I have been fightly an irritating problem with my PAS-16:
It plays a 1/4 step flat. This can be a real problem if one is trying to
synchronize it with other instruments (unless you have a tin ear)... I talked
to Mediavision's tech support, and after reaching someone who had a clue, I
was told that the FM synthesis portion derives its _unadjustable_ time base
off of the ISA bus clock. Apparently they expect that clock to be 8.33MHz,
but in most clones it is more like 8.25MHz, or 8.0MHz. So, you can't tune it,
and what's worse is that whatever it is tuned to depends on the vagaries of
motherboard design. Wouldn't you think that for musical generation, this
would be important enough to warrant its own crystal oscillator?
After finding this out, I did some thinking about the PAS-16's abilities. If
you step back and consider this, just about every part of the PAS-16 sucks in
some minor way, that with a thought, could have been avoided. The FM tuning,
for me, is the last straw.
FM synthesis:
Why couldn't they have spent the extra $2 and used an onboard crystal,
instead of relying on an externally provided, inaccurate clock? I
wonder what happens if you put the card in a system with a 12MHz I/O
bus?....
DAC/ADC section:
Sure, you can record & playback stereo at 44.1KHz, but it completely
inhales all the ISA bandwidth to do so. It only needs a maximum of
160KB/sec, however because there's no buffering, it effectively
occupies far more of the available bandwidth. Why couldn't they have
added a pair of small fifos? Doing so would relax the dma channel's
timing constraints, and allow transfers to go in faster bursts,
thereby reducing the effective bandwidth needed (and eliminating the
clash with bus mastering disk controllers).
MIDI interface:
Supporting only MPU-401 uart mode only is ok, but it occasionally
drops a byte here or there. Their reason? They really didn't expect
we would USE it... All it takes is one dropped byte to create one
stuck note and ruin the entire sequence. I think this is unacceptable.
Joystick interface:
You can only use a single joystick. A y-adapter won't work unless
you move some wires around. Mediavision has admitted that the joystick
interface isn't 100% compatible, and that if you have the choice,
you should disable it and use another game port adapter.
SCSI interface:
Again, like everything else it sort of works until you start pushing
it. You can in principle hang a hard drive off it, but it will be
too slow. And like the DAC/ADC section, it just inhales available
bandwidth, even though it has a maximum rate of only 600KB/sec
(400KB/sec is a more practical limit). Even using CD-ROMs is a
problem. Ever tried playing CD-DA tracks through the SCSI bus and out
the PAS-16's DAC? This is a double whammy. You need 100% of the
available ISA bandwidth EACH WAY for what should really be a total of
320KB/sec (160 from CD-ROM plus 160 to the DAC). Does the trantor
SCSI interface on the PAS-16 have any buffering at all?
Mixer/output section:
Noisy. Need I say more?
About the only section I've left out is the sound blaster compatibility. And
as far as I know, it really IS as good as the original sound blaster. Too bad
it isn't Sound Blaster Pro compatible...
On my system, I use a multi-I/O card for the joystick, and have just switched
to a MusicQuest PC-MIDI card for the MIDI output. I'm actively looking to get
a _real_ SCSI controller. The Adaptec 2842 sounds perfect, except I have been
hearing rumors that it will clash with the PAS-16, due again to the PAS-16's
being a bus pig. I seem to be adding more stuff to get around each limitation
of the PAS-16. I have to ask myself, what am I using this card for?
This sound card has so many abilities, yet each seems to be a half-baked
implementation. Why couldn't Mediavision have taken the extra step and done
it all the Right Way? Is there anything out there which doesn't have any of
these problems? Maybe I'm about to become a GUS convert...
One other point: It is pretty clear to me that this card is obviously not
intended for "professional" use (where "professional" == doing something other
than playing games with it). Yet one has to ask then, why does the name start
with "Pro-"?
--
Mike Isely | |
Fermilab M.S. 368 | Internet: is...@fnal.fnal.gov | Nobody has anything to do
P.O. Box 500 | Bitnet: isely@fnal | with my mostly meaningless
Batavia, IL 60510 | ATTnet: (708)-840-2784 | and silly rantings...
Cornel Huth
> It plays a 1/4 step flat. This can be a real problem if one is trying to
> off of the ISA bus clock. Apparently they expect that clock to be 8.33MHz,
> but in most clones it is more like 8.25MHz, or 8.0MHz. So, you can't tune it
Not true. The bus has nothing to do with it. If they do anything that would
depend on bus speed, it's simply delaying (spinning in a loop) for a certain
amount of time to pass (required for accessing the OPL chip's address/data
ports). Anyway, most software simply use repeated IN instructions, hoping
that this is a CPU-independent method of getting a constant delay. That it
isn't, though, isn't the problem (though using such techniques means youy
have to severely over-wait, as in 10 times, or more, too long). So what is
the problem? (BTW, a good design would not spin using INs for delay.)
The software. Who wrote their timing simply erred. The timing is based on
the ticks/quarter-note (say, 480), the time-constant of a quarter-note (say,
500k ms). This has to be massaged into a value to feed the timer (either
timer-0, the RTC, or any on-board timer). Getting this value wrong makes
the rate of playback wrong. It has nothing at all to do with bus speed.
Not at all!
Internet: corne...@LChance.sat.tx.us or cor...@ephsa.sat.tx.us
Fidonet: 1:387/800.8
BSS: 40th Floor v32b@1(210)684-8065 M-F:5pm-9am/WE:1pm-9am [-0600]
--
cor...@ephsa.sat.tx.us (Cornel Huth)
Rivercity Matrix -- +1 (210) 561-9815/21 -- San Antonio, Texas
Cornel Huth
hardware specs of the 3, but the OPL2, for examples, used a 49.716kHz
xtal.
Mike Isely
Cornel Huth <cor...@ephsa.sat.tx.us> wrote:
>> This past two weeks, I have been fightly an irritating problem with my PAS-16
>> It plays a 1/4 step flat. This can be a real problem if one is trying to
>> was told that the FM synthesis portion derives its _unadjustable_ time base
>> off of the ISA bus clock. Apparently they expect that clock to be 8.33MHz,
>> but in most clones it is more like 8.25MHz, or 8.0MHz. So, you can't tune it
>
>Not true. The bus has nothing to do with it. If they do anything that would
>depend on bus speed, it's simply delaying (spinning in a loop) for a certain
>amount of time to pass (required for accessing the OPL chip's address/data
>ports). Anyway, most software simply use repeated IN instructions, hoping
>that this is a CPU-independent method of getting a constant delay. That it
>isn't, though, isn't the problem (though using such techniques means youy
>have to severely over-wait, as in 10 times, or more, too long). So what is
>the problem? (BTW, a good design would not spin using INs for delay.)
>
I am not talking about the rate of playback, nor am I making any reference to
how the chip is accessed. I was pointing out that it seems when software
directs the OPL3 to produce frequency "X", what comes out instead is frequency
"X*0.95" (1/4 flat). I measured it with a frequency counter. I compared note
"C2" with a tuning fork. I used 3 different media players under 2 different
operating systems (Midisoft Studio / win, Windows media player / win, and the
MMPM/2 media player / OS/2). I even tried a second PAS-16 card. ALL
COMBINATIONS produced tones a 1/4 step flat. In fact, in all cases the amount
of error was precisely the same. The only element of commonality was that I
was always using the same motherboard hardware.
>The software. Who wrote their timing simply erred. The timing is based on
>the ticks/quarter-note (say, 480), the time-constant of a quarter-note (say,
>500k ms). This has to be massaged into a value to feed the timer (either
>timer-0, the RTC, or any on-board timer). Getting this value wrong makes
>the rate of playback wrong. It has nothing at all to do with bus speed.
>Not at all!
The time base I was refering to is the base frequency from which the tone
generators' divide-by-n counter(s) operate. If that frequency is off, then
all notes will be off-key. My point is that if this is off, then other
instruments played along with the card (i.e. another synth, a flute, a violin,
etc) will all sound terrible, unless you happen to be tone deaf. According to
Mediavision, the tone generator's time base frequency has EVERYTHING to do
with the ISA bus speed. It is using the ISA clock, which is "expected" to be
8.33MHz. If it is something else, like 8.0MHz, the card will be flat. This
is straight from the mouths of Mediavision tech support!
It is a terrible design to make such an important frequency depend on such
a questionable source.
>
>Internet: corne...@LChance.sat.tx.us or cor...@ephsa.sat.tx.us
>Fidonet: 1:387/800.8
>BSS: 40th Floor v32b@1(210)684-8065 M-F:5pm-9am/WE:1pm-9am [-0600]
>
>
>
>--
>cor...@ephsa.sat.tx.us (Cornel Huth)
>Rivercity Matrix -- +1 (210) 561-9815/21 -- San Antonio, Texas
Mike Isely
Cornel Huth <cor...@ephsa.sat.tx.us> wrote:
>Also, the OPL3 (YMF262) does have its own oscillator. I don't have the
>hardware specs of the 3, but the OPL2, for examples, used a 49.716kHz
>xtal.
>
Perhaps the chip's design allows for attachment of a crystal. That would
certainly make sense in any case. But many on-chip crystall oscillator
implementations also allow external circuitry to provide the time base.
Somebody please show me where to find this crystal on the card. If I can
locate the crystal, then I can change it... According to Mediavision
themselves (and I have no reason to doubt them), there is no such crystal
on their card.
>
>
>--
>cor...@ephsa.sat.tx.us (Cornel Huth)
>Rivercity Matrix -- +1 (210) 561-9815/21 -- San Antonio, Texas
Michael L. Murphy
>I am not talking about the rate of playback, nor am I making any reference to
>how the chip is accessed. I was pointing out that it seems when software
>directs the OPL3 to produce frequency "X", what comes out instead is frequency
>"X*0.95" (1/4 flat). I measured it with a frequency counter. I compared note
>"C2" with a tuning fork. I used 3 different media players under 2 different
>operating systems (Midisoft Studio / win, Windows media player / win, and the
>MMPM/2 media player / OS/2). I even tried a second PAS-16 card. ALL
>COMBINATIONS produced tones a 1/4 step flat. In fact, in all cases the amount
>of error was precisely the same. The only element of commonality was that I
>was always using the same motherboard hardware.
Try using the T:1 parameter to MVSOUND.SYS to get the PAS-16 to use it's
own on-board oscillator instead of the motherboards. When I owned a
PAS-16, I think this used to cure the pitch flatness of the FM synth (but
then I got other problems - the FM synth would "cut out" now and
then - hopefully, the same won't happen to you). I never did figure out
how to make the OPL3 synth on the PAS-16 sound *good*, though... :)
BTW, the answer to the question in the subject line is "yes, in more
ways than one". :)
--
+=And=the=Master=said=unto=the=silence,="In=the=path=of=our=happiness=shall=+
\ we find the learning for which we have chosen this lifetime." - R. Bach /
+=send=e-mail=to=<mur...@symcom.math.uiuc.edu>==============================+
Mike Isely
Michael L. Murphy <mur...@symcom.math.uiuc.edu> wrote:
[munch]
>
>Try using the T:1 parameter to MVSOUND.SYS to get the PAS-16 to use it's
>own on-board oscillator instead of the motherboards. When I owned a
>PAS-16, I think this used to cure the pitch flatness of the FM synth (but
>then I got other problems - the FM synth would "cut out" now and
>then - hopefully, the same won't happen to you). I never did figure out
>how to make the OPL3 synth on the PAS-16 sound *good*, though... :)
Yeah, I tried this. First thing I tried, as a matter of fact. It had zero
effect. And no, the mvsound.sys driver did not complain about any syntax
errors on the command line. This was mvsound.sys v3.24. I also tried this
with the latest OS/2 mvprodd.sys driver (September 93?). Same results.
Perhaps T:1 only affects the source used to control ADC/DAC sampling rates?...
Most (but not all) of the tests I ran were under windoze. Is it possible that
the Windows PAS-16 driver was overriding the T:1 setting? I already know it
can override other settings, like dma channel and irq. This however wouldn't
explain why I could replicate the behavior under OS/2 with totally different
drivers.
Thanks for trying though. *sigh*
[munch]
Jim Morris
Mike Isely <is...@fncrd7.fnal.gov> wrote:
>
>FM synthesis:
> Why couldn't they have spent the extra $2 and used an onboard crystal,
> instead of relying on an externally provided, inaccurate clock? I
> wonder what happens if you put the card in a system with a 12MHz I/O
> bus?....
Ahem! The PAS-16 *DOES* have an onboard oscillator. To enable it, and tell
your PAS-16 to NOT use the one provided by your motherboard, add the
parameter "T:1" to the line in your CONFIG.SYS that loads MVSOUND.SYS.
The default value for this parameter, if not supplied, is "T:0", which
tells the PAS-16 to disable the onboard oscillator, and use the one from
the PC's backplane.
>DAC/ADC section:
> Sure, you can record & playback stereo at 44.1KHz, but it completely
> inhales all the ISA bandwidth to do so. It only needs a maximum of
> 160KB/sec, however because there's no buffering, it effectively
> occupies far more of the available bandwidth. Why couldn't they have
> added a pair of small fifos? Doing so would relax the dma channel's
> timing constraints, and allow transfers to go in faster bursts,
> thereby reducing the effective bandwidth needed (and eliminating the
> clash with bus mastering disk controllers).
Are you sure about this? I do not seem to have a problem on my 486SX-25
system, doing playback or record at 44.1kHz, 16 bit. Of course, I also
do not have a bus-mastering disk controller...
>Joystick interface:
> You can only use a single joystick. A y-adapter won't work unless
> you move some wires around. Mediavision has admitted that the joystick
> interface isn't 100% compatible, and that if you have the choice,
> you should disable it and use another game port adapter.
Isn't this also true of the joystick port on the other sound cards? It must
be, else I wouldn't hear of people using the MIDI connector kit for a
SoundBlaster with their PAS-16.
In all honesty, the ONLY thing I can think of that even uses two joysticks
are a few programs like MS Flight Simulator. The majority of PC owners that
even have joysticks only use one. Another thing: On my PC at least, I
have had no end of problems with the joystick interface on standard Multi-I/O
type cards, whereas the PAS-16 joystick interface works flawlessly for me.
>Mixer/output section:
> Noisy. Need I say more?
NOT! My PAS-16 Rev D's output is VERY quiet. I suggest you try listening
to the output of one of Creative Lab's cards, and compare the difference.
>One other point: It is pretty clear to me that this card is obviously not
>intended for "professional" use (where "professional" == doing something other
>than playing games with it). Yet one has to ask then, why does the name start
>with "Pro-"?
None of the low priced (i.e., sub $300 price range) audio cards is really
up to what a music professional needs. They try to do everything, for
starters. If you need a good MIDI interface card, go spend $150 on a card
that JUST does MIDI. If you need wavetable synthesis, go spend $600 on a
card that JUST does that. You see what I mean? You get what you pay for,
and for the $145 I paid for the PAS-16, I for one would not expect it to
stand up to rigorous "industrial strength" use. And neither would I expect
most of the other PC sound cards to either.
Jim Morris (jmo...@rastek.com)
Robert Rosenbaum
>>> off of the ISA bus clock. Apparently they expect that clock to be 8.33MHz,
>>> but in most clones it is more like 8.25MHz, or 8.0MHz. So, you can't tune it
Hmmm. My ISA bus is running at 12.5 MHz. Many older PCs' ISA busses
are running at 6Mhz. My music sounds OK, but then again I may be tone
deaf.
>directs the OPL3 to produce frequency "X", what comes out instead is frequency
>"X*0.95" (1/4 flat). I measured it with a frequency counter. I compared note
>"C2" with a tuning fork. I used 3 different media players under 2 different
I'm not a music expert, but isn't this a measure of 'absolute pitch',
which is indetectable by most human ears? In real life most
instruments are tuned relative to a base frequency (e.g. middle C)
which may be far off from 220Hz (or is it 440Hz ?).
>The time base I was refering to is the base frequency from which the tone
>generators' divide-by-n counter(s) operate. If that frequency is off, then
>all notes will be off-key. My point is that if this is off, then other
I don't see why notes would be off key if music scales are all
relative. Does it have something to do with the logarithmic
progression of frequencies across octaves?
>8.33MHz. If it is something else, like 8.0MHz, the card will be flat. This
>is straight from the mouths of Mediavision tech support!
Then mine should be absolutely screwy at 12.5Mhz, and it isn't. Let
me make sure I understand you correctly - it is using the actual speed
of the bus for the frequency signal, and not the timer which the bus
uses to set its own speed?
I'm going to play around with my bus speed, and see what it does to my
FM sound. Film at 11.
Rob
--
Robert Rosenbaum, rro...@caip.rutgers.edu, (908) 932-0544
CAIP Computational Engineering Systems Lab
Rutgers University Department of Mechanical and Aerospace Engineering
"Will build spacecraft for food"
Robert Rosenbaum
>is...@fncrd7.fnal.gov (Mike Isely) writes:
>>8.33MHz. If it is something else, like 8.0MHz, the card will be flat. This
>>is straight from the mouths of Mediavision tech support!
>
>I'm going to play around with my bus speed, and see what it does to my
>FM sound. Film at 11.
The bus speed doesn't effect the pitch.
I just recored two wav files. Both were a single C5 note from
"Midikeys" using instrument 81 (square wave), recorded in 8 bit mono
at 44kHz. The first was in my usual configuration, in which my bus
speed is clock/5 (10MHz, since my CPU is 50MHz). Then I went into
BIOS setup and lowered the bus speed to 7.15MHz. I went back into
Windows, and recored the exact same thing, then played back the two
recorded files. They sound identical. If there was any difference,
it should be quite detectable, since the bus speed was changed by 30%.
Does this answer the basic question? If there is a strong demand, I
will post the two wav file to alt.binaries.sounds.misc - but I would
rather not do it. They are 175kB each, and uninteresting listening.
Jan van Loenen
|Ahem! The PAS-16 *DOES* have an onboard oscillator. To enable it, and tell
|your PAS-16 to NOT use the one provided by your motherboard, add the
|parameter "T:1" to the line in your CONFIG.SYS that loads MVSOUND.SYS.
|The default value for this parameter, if not supplied, is "T:0", which
|tells the PAS-16 to disable the onboard oscillator, and use the one from
|the PC's backplane.
I always use the T:1 option and the sound is fine.
Is there any reason to use T:0? There must be some reason, as it is even
the default.
Thanks,
Jan