I've build five 1.2 cards, never noticed any noise issues but I only use cards with speakers.
Gus compatibility isn't great but I mostly use card as an intelligent mode mpu-401 device for that it's great card.
I pair it with sound blaster 16 on 286 machine I use it with mt-32l on mt-32 mode, and on pentium machine mt-32l is on general midi/soundfont mode.
Also in 286 machine I use it in tandy mode.

I build a few of these cards and:
- one is paired with an AWE32 in a 486 build
- one is in a XT used as an Adlib compatible card
- one is not used yet but will be used in an Amiga 2000 with a (x86) bridgeboard

So far all of these cards work great. I'm not having noise issues with speakers. The cards work great in Adlib/GUS and other modes.

I do have a real GUS which I keep in storage and an Orpheus II in my main build. Since it's now waiting on the Orpheus successor, the PicoGUS is an affordable alternative.

I also haven't noticed any noise issues in the v2 card I have. I do recommend getting an external mixer as piping it into another sound card will just add noise.

While the PicoGUS does its job well. I don't recommend using it by itself. It currently doesn't have 16bit digital audio, or OPL3 support. But having GUS, and intelligent mode MPU401, CMS/Game Blaster, and Tandy 3 voice support means it does add a bunch of sound options to a single slot.

Your AWE 64 will resolve the 16-bit limitation, as well as providing some unique experiences for that games that directly support it on the music side. This means custom pre-soundfont standard soundfont, as well as MIDI style tonal changes that can be applied to the AWE 64's OPL synth music as well.

So IMO, an AWE 64 and PicoGUS paired together give a extremely wide variety of sound options. The only thing beyond it would be adding in an MT32 Pi device to also get access to the MT32 as well as large soundfont support for General MIDI. I run a WP32 McCake on the PicoGUS's MIDI daughterboard header, and get clean sounding music.

SScorpio wrote on 2025-01-31, 14:24:

While the PicoGUS does its job well. I don't recommend using it by itself. It currently doesn't have 16bit digital audio

How exactly are you coming to this conclusion?

jmarsh wrote on 2025-01-31, 17:26:

How exactly are you coming to this conclusion?

It only supports up to Soundblaster 2.0 and OPL2. So later DOS games where you want Soundblaster 16 and/or OPL 3 won't be optimal. Having a separate card is the current best option.

SScorpio wrote on 2025-01-31, 18:18:

It only supports up to Soundblaster 2.0 and OPL2. So later DOS games where you want Soundblaster 16 and/or OPL 3 won't be optimal. Having a separate card is the current best option.

Being an Ultrasound means it already supports 16-bit audio.

I'm definitely open to running two cards again. Like I said above, it was primarily the noise that made me pull the Opti. Granted, I do arbitrarily like the sound of the AWE64 a bit better, but the I found the noise just kept me running the Awe64 over the Opti more often than not.

One benefit I was looking for from the PicoGUS was to add back some of the compatibility with older games that I lost just running the Awe64. I got most of that back using unisound drivers, but I also really miss not having a GUS to play around with.

The more I look at it, the more I want one.

jmarsh wrote on 2025-02-01, 00:29:

Being an Ultrasound means it already supports 16-bit audio.

OP has a Socket 7 build, so games that do 16-bit Sound Blaster would be period accurate. The GUS doesn't do 16-bit Sound Blaster, and even it's 8-bit Sound Blaster is better handled by a separate dedicated card.

StriderTR wrote on 2025-02-01, 01:31:

I'm definitely open to running two cards again. Like I said above, it was primarily the noise that made me pull the Opti. Granted, I do arbitrarily like the sound of the AWE64 a bit better, but the I found the noise just kept me running the Awe64 over the Opti more often than not.

One benefit I was looking for from the PicoGUS was to add back some of the compatibility with older games that I lost just running the Awe64. I got most of that back using unisound drivers, but I also really miss not having a GUS to play around with.

The more I look at it, the more I want one.

The AWE 64 is an amazing card. I just have a lowly Vibra 16 that has pretty clean output. But the PicoGUS really opens up what you can play with. It's the closest thing we have to the promise of the Bitchin' Fast 3000 sound card which was supposed to be that FPGA based sound card project. This used a RP2040, so it's not an FPGA, but it still works well.

When you break down and get one, I do recommend exploring CMS/Game Blaster, and Tandy if you haven't. CMS is a different early pre everything going Sound Blaster and Adlib. And Tandy is just neat as it's technically mostly a three channel PC speaker, but can pull off so much more that a regular PC speaker could. It looks like the PicoGUS will also have the possibility of Covox/Disney Sound Source support. That will give most of the early sound options to play with. MT32 and MIDI would be the only thing to expand to on the high end.

Compared to several other sound card projects that while awesome, ended up being several hundred dollars. The PicoGUS is an absolute bargain for everything it does. And it's open source nature that lets anyone build that own will get it around for years.

SScorpio wrote on 2025-02-01, 02:31:

OP has a Socket 7 build, so games that do 16-bit Sound Blaster would be period accurate. The GUS doesn't do 16-bit Sound Blaster, and even it's 8-bit Sound Blaster is better handled by a separate dedicated card.

Practically any game that supports SB16 will also support GUS for digital audio. There's even games that don't support SB16 that do support GUS - giving 16-bit audio without requiring a 16-bit ISA slot.

jmarsh wrote on 2025-02-01, 02:48:

SScorpio wrote on 2025-02-01, 02:31:

OP has a Socket 7 build, so games that do 16-bit Sound Blaster would be period accurate. The GUS doesn't do 16-bit Sound Blaster, and even it's 8-bit Sound Blaster is better handled by a separate dedicated card.

Practically any game that supports SB16 will also support GUS for digital audio. There's even games that don't support SB16 that do support GUS - giving 16-bit audio without requiring a 16-bit ISA slot.

Practically most games supporting GUS don't take advantage of the hardware mixer, causing a performance hit due to the GUS being completely a wavetable synth. SB16 would be preferable in those situations.

To the OP: Pair the AWE64 with the PicoGUS if there are enough resources available.

Gmlb256 wrote on 2025-02-01, 04:11:

Practically most games supporting GUS don't take advantage of the hardware mixer, causing a performance hit when software mixing is used due to the GUS being completely a wavetable synth. SB16 compatibility would be preferable in those situations.

How do you think those games do mixing when outputting to a SB16? I'll give you a hint: they don't use hardware... So using a GUS gives no worse performance.

jmarsh wrote on 2025-02-01, 04:13:

Gmlb256 wrote on 2025-02-01, 04:11:

Practically most games supporting GUS don't take advantage of the hardware mixer, causing a performance hit when software mixing is used due to the GUS being completely a wavetable synth. SB16 compatibility would be preferable in those situations.

How do you think those games do mixing when outputting to a SB16? I'll give you a hint: they don't use hardware... So using a GUS gives no worse performance.

I know that the SB16 doesn't use hardware for mixing samples. I'm point out that using software mixing for the GUS is suboptimal.

Gmlb256 wrote on 2025-02-01, 04:18:

I know that the SB16 doesn't use hardware for mixing samples. I'm point out that using software mixing for the GUS is suboptimal.

No more suboptimal than what it is for SB16. The game uses the same mixing code in both cases.

jmarsh wrote on 2025-02-01, 04:22:

Gmlb256 wrote on 2025-02-01, 04:18:

I know that the SB16 doesn't use hardware for mixing samples. I'm point out that using software mixing for the GUS is suboptimal.

No more suboptimal than what it is for SB16. The game uses the same mixing code in both cases.

GUS requires samples to be stored into its RAM prior playing them, making it suboptimal for software mixing as the RAM has to be constantly updated. This doesn't happen with the Sound Blasters and compatible clones.

Gmlb256 wrote on 2025-02-01, 04:40:

GUS requires samples to be stored into its RAM prior playing them, making it suboptimal for software mixing as the RAM has to be constantly updated. This doesn't happen with the Sound Blasters and compatible clones.

The pre-mixed samples are uploaded into the RAM using DMA, same as how they're played via a SB16.

jmarsh wrote on 2025-02-01, 04:49:

Gmlb256 wrote on 2025-02-01, 04:40:

GUS requires samples to be stored into its RAM prior playing them, making it suboptimal for software mixing as the RAM has to be constantly updated. This doesn't happen with the Sound Blasters and compatible clones.

The pre-mixed samples are uploaded into the RAM using DMA, same as how they're played via a SB16.

Not exactly the same thing, Sound Blasters don't have onboard RAM for storing samples.

Anyway, I will stop posting on this thread to avoid further derailment.

I also combined my PicoGus with an AWE64 and it's the best:
AWE64 does clean sfx/voice and is the most compatible
AWE64 is a good backup for midi music (when no MT32, General Midi or GUS music compatibility)
PicoGUS has an easy MIDI header to deal with (nothing in the way for wavetable)
PicoGUS provides the OPL3 that AWE64 (value) lacks for older games (when rerouting 388 port to the GUS)
PicoGUS gives better results in GUS optimised demos and games that only have soundblaster 2.0 or Pro support