VOGONS


OPL recording problem

Topic actions

Reply 40 of 51, by Cloudschatze

User metadata
Rank Oldbie
Rank
Oldbie
NewRisingSun wrote:

Now to find out what is up with the CT1747 when it is connected to the EMU8000.

Here's a ~20-second capture of the S/PDIF output from a CT3900 card, using your OPL440.COM utility:
http://www.symphoniae.com/soundcard/Creative/ … WAV/EMUOPL3.wav

I'm not sure how accurate this is, but WaveSpectra shows a peak frequency of 440.1Hz.
EMUOPL3.png

sklawz wrote:

UPDATE: From inspection B30 is not connected and OSC doesn't enter the board.

Exactly. If only it were that simple, right? 😉

Reply 41 of 51, by sklawz

User metadata
Rank Member
Rank
Member

hi

Cloudschatze wrote:
sklawz wrote:

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).

Bye

Reply 42 of 51, by jwt27

User metadata
Rank Oldbie
Rank
Oldbie
Cloudschatze wrote:
NewRisingSun wrote:

Now to find out what is up with the CT1747 when it is connected to the EMU8000.

Here's a ~20-second capture of the S/PDIF output from a CT3900 card, using your OPL440.COM utility:
http://www.symphoniae.com/soundcard/Creative/ … WAV/EMUOPL3.wav

Visual Analyzer says it's 443.0215Hz, and shows the same bimodal distribution.

qnil.png

Not sure where the four lower measures came from. Possibly my Pentium 4 dropped a few samples somewhere.

Reply 43 of 51, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie
sklawz wrote:

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?

Reply 44 of 51, by sklawz

User metadata
Rank Member
Rank
Member

hi

NewRisingSun wrote:
sklawz wrote:

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:

SAMPLES/SECOND = 352800, CONTROLWORD = 20780, FREQUENCY = 111859, SAMPLERATE / FREQUENCY = 3.153975, MULTIPLIER = 128
CT1747 = 14317952, YMF262 = 49715

Bye

EDIT: The above hack uses a 16-bit adder.

Reply 45 of 51, by Cloudschatze

User metadata
Rank Oldbie
Rank
Oldbie
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?

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.

Reply 46 of 51, by sklawz

User metadata
Rank Member
Rank
Member

Hi.

Cloudschatze wrote:
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.

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:

/* E-MULATE 1 SECOND */
for (i = 0; i < SAMPLERATE; ++i) {
adder += CONTROLWORD;
if (adder > 0xFFFF) {
adder &= 0xFFFF;
counter++;
}
}

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.

Bye

Reply 47 of 51, by Cloudschatze

User metadata
Rank Oldbie
Rank
Oldbie
sklawz wrote:

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). 😀

Reply 48 of 51, by sklawz

User metadata
Rank Member
Rank
Member

hi

Cloudschatze wrote:
sklawz wrote:

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). 😀

This appears to be the case, yes.

Bye-bye.

Reply 49 of 51, by jwt27

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 50 of 51, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie
sklaws wrote:

You can see how simple it is.

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.

Reply 51 of 51, by sklawz

User metadata
Rank Member
Rank
Member

Hi

NewRisingSun wrote:
sklaws wrote:

You can see how simple it is.

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.

Bye.