LSS10999 wrote:

I recall having read that GUS was able to play up to 14 audio samples at the same time (or up to 32 at a reduced frequency rate).

This is true for UltraSound (and compatible) cards based on the GF1 chip. They support up to 14 channels at the maximum sample rate of 44.1 kHz; beyond 14 channels, the sample rate gradually drops with each additional channel. If I remember correctly, at 32 channels, the sample rate is just over 29 kHz (EDIT: it's actually around 19.4 kHz).

This is not true for cards based on the AMD InterWave chips; its synthesiser module always operates at 44.1 kHz in native/"enhanced" mode, regardless of the number of active channels. When operating in legacy compatibility mode, it uses "frame expansion" to approximate the sample rate behaviour of the older cards.

Software that supports the GUS directly is able to specify the number of active voices. No Sound Blaster card before the AWE32 supported more than a single stereo channel (sometimes listed as 2 voices) for digital audio. Even though you could, for example, hear a door close and gunshots at the same time in Doom, they would have been mixed in software with a Sound Blaster or similar card, whereas the UltraSound could do that in hardware (though some software failed to leverage that feature).

640K!enough wrote:

Even though you could, for example, hear a door close and gunshots at the same time in Doom, they would have been mixed in software with a Sound Blaster or similar card

Yes, the DOOM engine allows up to 8 sounds to be mixed in software in realtime. In the setup program you can specify how many sounds to mix (so if you have a slower CPU, you can reduce the amount of channels to improve performance of the game).

LSS10999 wrote:

I recall having read that GUS was able to play up to 14 audio samples at the same time (or up to 32 at a reduced frequency rate).

That is why good players for the GUS only activate actually used voices when playing music. Even when having 32 channel tracker music it doesn't mean that at all time all 32 voices are actually playing. e.g. if most of the time 14 channels play then you have with a GUS still 44.1 kHz most of the time.

elianda wrote:

That is why good players for the GUS only activate actually used voices when playing music. Even when having 32 channel tracker music it doesn't mean that at all time all 32 voices are actually playing. e.g. if most of the time 14 channels play then you have with a GUS still 44.1 kHz most of the time.

Are you sure that that is the case? From your description, it seems like you're implying that "good" players update the number of active voices in real-time, based on the number of voices that are actually being used. That would involve updating multiple registers each time the number of active voices changes, and depending on what is being played, I am not sure it could be done without audible side-effects on GF1 cards.

This is different on IntrerWave-based cards, as the sample rate does not depend on the number of active voices in enhanced mode, and de-activating voices is a fairly simple matter.

You can see that in e.g. Cubic Player. Press o to show scopes, white color is an active voice and gray an inactive.

640K!enough wrote:

That would involve updating multiple registers each time the number of active voices changes, and depending on what is being played, I am not sure it could be done without audible side-effects on GF1 cards.

Depending on how fast the GF1 is at changing the number of voices, and how elegantly it switches, it could certainly be possible.
Pretty much all tracker formats I know, are designed to update at 50 to 70 Hz. That means that any pitch, volume or other effect changes only happen once every 1/70th of a second at most. So you send all updates in a single batch. Adding a few more register writes to that batch at the end, should not be very time-critical.

I suppose it should be reasonably easy to see by just running Cubic Player inside DOSBox and checking the active mixing frequency in the emulated GF1-core.

well both GF1 and the IC376 (EMU8000) chip came into existence in 1992.. so I consider it a wash. IC376 did come with ROM and RAM out of the box, where GF1 only had ram. and we know the 8801 demo board was the first wavetable card, creative just flipped the pinout header from emu's reference design.

Scali wrote:

Pretty much all tracker formats I know, are designed to update at 50 to 70 Hz. That means that any pitch, volume or other effect changes only happen once every 1/70th of a second at most. So you send all updates in a single batch. Adding a few more register writes to that batch at the end, should not be very time-critical.

might be doable, except on 386+486 maybe it might be too slow, IO port writes are expensive, if you had to batch up a whole bunch to go from 13 to 20 channels and cross the 14channel mark.

personally I dont think any tracker did it, you would for sure HEAR the difference if it switched from playing 14 channels at 44.1khz to 32 channels at 19khz then back to 14 at 44.1khz.. maybe. I'm speculating here, but I think people would hear a difference (I dont have musical ears so I might not 🤣!)

I think the main problem is needing to use all new note step values to produce the correct music freqs when sample rate changes.

BloodyCactus wrote:

might be doable, except on 386+486 maybe it might be too slow, IO port writes are expensive, if you had to batch up a whole bunch to go from 13 to 20 channels and cross the 14channel mark.

personally I dont think any tracker did it, you would for sure HEAR the difference if it switched from playing 14 channels at 44.1khz to 32 channels at 19khz then back to 14 at 44.1khz.. maybe. I'm speculating here, but I think people would hear a difference (I dont have musical ears so I might not 🤣!)

Impulse Tracker does it. You can see the active voices in the drivers section of the program. From DRIVERS.TXT:

"You cannot choose the mixing rate for the GUS - the mixing rate is
dependent on the number of channels playing. This driver continuously
reinitialises the GUS to use as few channels as possible. You can
further restrict the number of channels used with /Lxx on the command
line of Impulse Tracker."

Scali wrote:

Yes, the DOOM engine allows up to 8 sounds to be mixed in software in realtime. In the setup program you can specify how many sounds to mix (so if you have a slower CPU, you can reduce the amount of channels to improve performance of the game).

Doom 1.2 can mix 4 channels in hardware on the GUS. AFAIK hardware mixing was dropped because of some DMA related instabilities.

BloodyCactus wrote:

IO port writes are expensive

Yea, but not THAT expensive.
On an AdLib you actually have to do 35 dummy IO reads after every register write. And that's never been a problem.
It's a safe assumption that the GUS is faster than that. The OPL2 is notoriously slow.

BloodyCactus wrote:

personally I dont think any tracker did it, you would for sure HEAR the difference if it switched from playing 14 channels at 44.1khz to 32 channels at 19khz then back to 14 at 44.1khz..

I suppose it depends on how many notes the music plays in practice.
I don't think you'll see jumps from 14 to 32 channels very often. I would hazard a guess that it would be more gradual in practice.

Scali wrote:

Depending on how fast the GF1 is at changing the number of voices, and how elegantly it switches, it could certainly be possible.
Pretty much all tracker formats I know, are designed to update at 50 to 70 Hz. That means that any pitch, volume or other effect changes only happen once every 1/70th of a second at most.

That is the key point; on GF1-based hardware, when changing the SAVI register to update the number of active voices, does it take effect immediately after the register write completes, or after some delay? As Tiido mentioned, a change that causes the sample rate to change requires updating the per-voice registers in order to avoid an audible pitch shift. Please correct me if I am wrong, but I don't think the 50-70 Hz update rate of trackers alone will save you, since you're still generating audio between updates.

If I had to guess, I would assume that the changes take effect at the beginning of the next synthesiser frame, so as long as you can push out all of the necessary register updates before the next frame begins processing, you may get away with it. If the I/O writes collectively take longer than one frame, or if the changes take effect at the end of each write, I don't understand how it can work without at least introducing some audible distortion.

640K!enough wrote:

If the I/O writes collectively take longer than one frame, or if the changes take effect at the end of each write, I don't understand how it can work without at least introducing some audible distortion.

As I tried to explain with my AdLib example, that is not the case.
You can do a LOT of IO writes in 1/70th of a second.

Scali wrote:

As I tried to explain with my AdLib example, that is not the case.
You can do a LOT of IO writes in 1/70th of a second.

I think we're talking about different frames; I was referring to a GUS synthesiser frame, which, at 44.1 kHz, lasts less than 22.7 microseconds. I suspect that that's when register changes will be applied, so if one changes the number of active voices, but doesn't complete all of the corresponding per-voice register updates before the beginning of the next frame, there will be some audible distortion, however brief, that would not have been present if one had allowed for a constant number of voices for the material being played. Unless this was changed in later releases, ULTRAMID did it that way, settling on 24 voices as an acceptable balance between polyphony and audio quality.

If Cubic Player does indeed manage the number of voices in real-time, it would be interesting to figure out how they did it, and what the resulting quality is like.

640K!enough wrote:

I think we're talking about different frames; I was referring to a GUS synthesiser frame, which, at 44.1 kHz, lasts less than 22.7 microseconds. I suspect that that's when register changes will be applied

That is an assumption, and that may or may not be correct. I am not familiar with the internals of the GUS synth.
I am familiar with the Amiga however, and I know that the Amiga sound chip fetches data per word. Since it plays 8-bit samples, it always fetches two samples at a time.
This is also why you can only set loops in mod files on even sample offsets.
Anyway, my point is: there may be some prefetching/caching going on in the GF1 chip, so an actual 'GUS synthesizer frame' may be at a much lower rate than 44.1 kHz.
Aside from that, I don't know how register writes are interpreted. Are they active immediately, or are they latched, and will they become active at a certain point?

But it seems that there are various GUS players/trackers that employ this trick, and it doesn't seem to cause any audible effect (I've used both Impulse Tracker and Cubic Player, and never noticed any glitches).

640K!enough wrote:

I think we're talking about different frames; I was referring to a GUS synthesiser frame, which, at 44.1 kHz, lasts less than 22.7 microseconds. I suspect that that's when register changes will be applied, so if one changes the number of active voices, but doesn't complete all of the corresponding per-voice register updates before the beginning of the next frame, there will be some audible distortion, however brief, that would not have been present if one had allowed for a constant number of voices for the material being played.

The GUS synth is a sequential state machine. It loads the voice registers for voice 0 at the top of the sample frame, processes updates for voice 0, saves the updates voice 0 back to the voice register file, increments the voice index, and finally compares it to SAVI. If equal, it waits for the next top of frame. If less than, it process voice 1 and so on. The voice register file is dual port RAM. AMD evolved the OTTO/GF1 RTL design when they created the Interwave. Weirdly they published all of the technical details of it's implementation in a provisional patent which is now public (US Patent number 6,058,066) which includes waaaay more detail than even the programmer's reference.

So voices are updated at up to 32 different phase offsets within the frame. You would have to recompute FSTEPS 32 x FS to realistically change the SAVI dynamically. I'm working on an FPGA Interwave core and have basically implemented it the same way.

640K!enough wrote:

If Cubic Player does indeed manage the number of voices in real-time, it would be interesting to figure out how they did it, and what the resulting quality is like.

Cubic does not. Cubic was OSS'd a long time ago. Both the older DOS versions and the newer OCP versions have published source and the GUS driver doesn't dynamically modify SAVI during the song playback - only at load time when the max active voice is computed from the file.

eeguru wrote:

AMD evolved the OTTO/GF1 RTL design when they created the Interwave. Weirdly they published all of the technical details of it's implementation in a provisional patent which is now public (US Patent number 6,058,066) which includes waaaay more detail than even the programmer's reference.

I recall people complaining of compatibility issues with the InterWave though.
More specifically, they claim that the pitch/speed of the InterWave does not match the GF1 exactly, and as a result, you can hear problems with songs that use long samples. I believe they play too fast on the InterWave.

eeguru wrote:

I'm working on an FPGA Interwave core and have basically implemented it the same way.

Ooh! That's an interesting project!

Scali wrote:

I recall people complaining of compatibility issues with the InterWave though.
More specifically, they claim that the pitch/speed of the InterWave does not match the GF1 exactly, and as a result, you can hear problems with songs that use long samples. I believe they play too fast on the InterWave.

I'm not absolutely sure about this, but there do seem to be timing differences between the GF1 and InterWave. Notice that GF1-based cards use a 19.7568 MHz crystal, versus the 16.9344 MHz crystal on InterWave cards. This ends up creating unavoidable differences in timing. It should only be noticeable when the InterWave is operating in GUS compatibility mode, and I expect that it would be more pronounced as the number of active voices increases (beyond 14). Since you're probably speaking from experience in the demoscene, it seems likely that the code in question was targeted at the GF1.

The table of approximate sample rates per number of active channels for the GF1 is fairly well-known. In compatibility mode, the InterWave approximates this sample rate behaviour. For each active voice beyond 14, the frame time is extended by "about 1.6 μs". Looking at that crystal value, there is no neat way of obtaining the exact 1.61969... μs increment used by the GF1, so it will actually have to be slightly lower or higher. This results in sample rates (other than 44100 Hz) that are slightly different throughout that table, which may explain the differences.

BEGIN EDIT: The programmer's guide states that the optional/secondary 24.576 MHz crystal is required for UltraSound compatibility, so it is unclear if that crystal is used exclusively in compatibility mode, or only for some functions/sample rates. In any case, I suspect the above description is still valid, but some testing will be required to confirm. END EDIT

It's too bad I haven't had a GF1-based card in a few decades, because it would be interesting to create some comparative recordings with the same software, same machine and same recording device, to document the extent of the differences.

eeguru wrote:

I'm working on an FPGA Interwave core and have basically implemented it the same way.

That is an interesting project. How much progress have you made? Will it be a pin-compatible replacement that could be substituted for the AMD part for testing?

eeguru wrote:

Cubic was OSS'd a long time ago.

I just noticed that a few days ago. I may want to have a look at the InterWave driver, not because I realistically expect to be able to improve upon it, but just to tinker with it and see if I can do anything amusing or interesting.

640K!enough wrote:

Since you're probably speaking from experience in the demoscene, it seems likely that the code in question was targeted at the GF1.

Yes, this is specifically about the GF1-compatibility mode. So I thought it may have to do with how the InterWave handles the variable mixing rate in this mode.

640K!enough wrote:

It's too bad I haven't had a GF1-based card in a few decades, because it would be interesting to create some comparative recordings with the same software, same machine and same recording device, to document the extent of the differences.

I have both types of cards. A GUS MAX, GUS Extreme, and a P&P Pro at least.

Scali wrote:

Yes, this is specifically about the GF1-compatibility mode. So I thought it may have to do with how the InterWave handles the variable mixing rate in this mode.

Since you have at least one card from each generation, if you have the time or inclination at some point, would you be willing to test the hypothesis? If you have some old code handy, I guess the first test would be to adjust the sample rate table (or equivalent), re-build and see if the audio now matches what you would expect on the InterWave.