UPDATE: From inspection B30 is not connected and OSC doesn't enter the board.
Exactly. If only it were that simple, right? 😉
If the only clock on the EMU is that 45158400 XTAL then it's possible that
they synthesized the 14318181 clock using an numerically controlled
oscillator (adder) followed by a PLL (multiplier).
If the only clock on the EMU is that 45158400 XTAL then it's possible that
they synthesized the 14318181 clock using an numerically controlled
oscillator (adder) followed by a PLL (multiplier).
The conversion factor from 45.1584 MHz to 14+7/22 MHz would be 3+481/3125 = 3.15392. It would be interesting to see how evenly-spaced those clock ticks on EMU8000's pin 30 are.
And by the way: yes, the 1953 NTSC documents do specify the color subcarrier frequency using the rounded number of 3.579545 MHz (they round everything, sometimes incorrectly), the newer SMPTE 170M explicitly defines it as "5 MHz x 63/88". If one keeps in mind that it is not defined out of the blue but derived from the line frequency, which in turn is derived from the sound carrier (in the 1953 specification), its derived formula is 4.5 MHz/286*455/2, which after factorization becomes 315/88 Mhz. I'd rather make calculations using the ideal numbers rather than accumulate rounding errors.
jwt27 wrote:
Possibly my Pentium 4 dropped a few samples somewhere.
How could it drop samples when you're just loading a wave file?
If the only clock on the EMU is that 45158400 XTAL then it's possible that
they synthesized the 14318181 clock using an numerically controlled
oscillator (adder) followed by a PLL (multiplier).
The conversion factor from 45.1584 MHz to 14+7/22 MHz would be 3+481/3125 = 3.15392. It would be interesting to see how evenly-spaced those clock ticks on EMU8000's pin 30 are.
Creating an accurate clock is trivial using an NCO. E-MU were or are specialists
in this technology, it's fundamental to how their sample based synthesis works.
In this instance though would we not use a look-up table, but instead utilise the carry out
of the adder to generate the clock.
I hacked a simulation in C and got these results using XTAL/128 ( 44100 * 8 ) as
the master clock:
Visual Analyzer says it's 443.0215Hz, and shows the same bimodal distribution.
There are some high-frequency artifacts in the output. Might those be affecting the average? Here is a low-pass filtered version of the same recording, if you want to analyze that instead: http://www.symphoniae.com/soundcard/Creative/ … EMUOPL3_LPF.wav
The reason I didn't use Visual Analyzer is due it not being able to analyze the WAV file directly (that I could determine). To NewRisingSun's point, are you using a loopback function/driver, or some DA-AD function in-between?
sklawz wrote:
Creating an accurate clock is trivial using an NCO. E-MU were or are specialists
in this technology, it's fundamental to how their sample based synthesis works.
I think the idea is sound. I don't personally know enough about the inner workings of the EMU8000 to speak intelligently about the applicability of it.
When you measured the clock frequency being supplied to the CT1747, had the EMU8000 been initialized either in DOS, through use of AWEUTIL, or in Windows, by the relevant drivers? If so, could you take another reading with the EMU8000 in an unintialized state? I imagine it's possible that the EMU8000 channels performing sample-rate conversion for the FM output are also generating the clock frequency for the OPL3.
Creating an accurate clock is trivial using an NCO. E-MU were or are specialists
in this technology, it's fundamental to how their sample based synthesis works.
I think the idea is sound. I don't personally know enough about the inner workings of the EMU8000 to speak intelligently about the applicability of it.
For E-MU this would have been a standard building block.
My example probably isn't practical nor anything like the ratios E-MU
would have used but demonstrates it's simplicity. Here is how we
can emulate the hardware in software:
1/* E-MULATE 1 SECOND */ 2 for (i = 0; i < SAMPLERATE; ++i) { 3 adder += CONTROLWORD; 4 if (adder > 0xFFFF) { 5 adder &= 0xFFFF; 6 counter++; 7 } 8 }
You can see how simple it is.
Cloudschatze wrote:
When you measured the clock frequency being supplied to the CT1747, had the EMU8000 been initialized either in DOS, through use of AWEUTIL, or in Windows, by the relevant drivers? If so, could you take another reading with the EMU8000 in an unintialized state? I imagine it's possible that the EMU8000 channels performing sample-rate conversion for the FM output are also generating the clock frequency for the OPL3.
My tests were done with just power on and no BLASTER initialisation whatsoever.
The test machine is an old and decrepit INTEL-TX with my preferred sound card
combination on that box of a OPTI MAD16, SW60-XG and MM-401 and only had
the AWE32 in to measure the clock. It won't be going back any time soon.
It's a poor man's Midi General but I do prefer the MAD16 though, it just works.
Who knows how they done the sample rate conversion? The simplest method
would be to latch the incoming I2S data at the 49716 rate then read it out
of the latches at 44100. It would need some synchronisation if that was the case
but we can only guess ultimately, not sure it really matters any way.
My tests were done with just power on and no BLASTER initialisation whatsoever.
That would suggest that the synth portion of the chip isn't managing the OPL3 clock generation/division, at least.
...but we can only guess ultimately, not sure it really matters any way.
No, ultimately, it doesn't really matter - the information that you've provided lets us know the CT1747 has an OPL3 implementation matching that of the YMF262, even when paired with the EMU8000, and that's enough (for me, anyhow). 😀
My tests were done with just power on and no BLASTER initialisation whatsoever.
That would suggest that the synth portion of the chip isn't managing the OPL3 clock generation/division, at least.
It does demonstrate that those are the default frequencies, yes. What it doesn't tell though, is whether
this frequency was actually selected using a GPIO and also if the EMU8000 supports other frequencies
dependant upon a GPIO. Chances are it doesn't but it's always good to have nagging doubts 😀
Cloudschatze wrote:
...but we can only guess ultimately, not sure it really matters any way.
No, ultimately, it doesn't really matter - the information that you've provided lets us know the CT1747 has an OPL3 implementation matching that of the YMF262, even when paired with the EMU8000, and that's enough (for me, anyhow). 😀
Cloudschatze wrote:There are some high-frequency artifacts in the output. Might those be affecting the average? Here is a low-pass filtered version […] Show full quote
jwt27 wrote:
Visual Analyzer says it's 443.0215Hz, and shows the same bimodal distribution.
There are some high-frequency artifacts in the output. Might those be affecting the average? Here is a low-pass filtered version of the same recording, if you want to analyze that instead: http://www.symphoniae.com/soundcard/Creative/ … EMUOPL3_LPF.wav
The reason I didn't use Visual Analyzer is due it not being able to analyze the WAV file directly (that I could determine). To NewRisingSun's point, are you using a loopback function/driver, or some DA-AD function in-between?
I analyzed it by looping the wav file (trimming it first so that it starts and ends exactly at a zero crossing), set the input in Visual Analyzer to Wave, and sampling rate to 44.1kHz. As long as Windows or the X-fi drivers didn't resample anything along the way, this method should be accurate.
If the high-frequency harmonics affected the analysis in any way, I think you would certainly be able to see this in the histogram.
I see how simple it is. In fact, the exact same method is used by LucasArts' iMUSE driver, which uses a 291+1713/5632 Hz timer to play back Standard MIDI Files of arbritrary tempo. It will result in no error accumulating over time, but I fail to see how this would result in evenly-spaced output clock ticks. I would assume instead that every sixth clock tick would be longer than the others.
I see how simple it is. In fact, the exact same method is used by LucasArts' iMUSE driver, which uses a 291+1713/5632 Hz timer to play back Standard MIDI Files of arbritrary tempo. It will result in no error accumulating over time, but I fail to see how this would result in evenly-spaced output clock ticks. I would assume instead that every sixth clock tick would be longer than the others.
Try it with a smaller control word. This means changing the ratios.
