I've determined the cause of silent audio in Doom and Dope reported by @Pickle and @HandOfFate, and I have a firmware fix! Many thanks to them for sending the cards back to me. At first I thought it was due to shipping damage or chipset incompatibility, but in this latest batch of cards I just made I started testing with Doom and noticed quite a few cards had the same problem. After eliminating the possibility of bad PSRAM, bad bus interface chips, or DMA bugs, I wondered if it was due to the DAC. Another person who had the same problem said not only was the demo Dope silent, playing the Demo's song in any MOD player was also silent. Dope is a 28-channel MOD file, which corresponds to a 22.05kHz GF1 mixing rate. And would you know it, Doom also runs at 28 channels. On the affected cards, loading any song into Fast Tracker II and playing with the number of active channels reproduces the issue: playback goes silent at 28 voices. Poking at the I2S signals going to the DAC with my scope showed audio being sent at that rate, but the DAC just wouldn't play it. I looked at the PCM510xA datasheet and it doesn't seem that 22.05kHz is really supported, especially at 16 bits per sample. I experimented with padding output to 24 or 32 bits per sample but that didn't alleviate the issue.

After searching the web for PCM5100A (or its variants PCM5101A and PCM5102A) and 22.050kHz, I found a couple posts on the TI forums that also report the same issue of no audio at 22.05kHz:
https://e2e.ti.com/support/audio-group/audio/ … ate-of-22-04khz
https://e2e.ti.com/support/audio-group/audio/ … hz-audio-format

So it seems that 22050Hz sampling rate is not officially supported by the PCM510xA despite it working on 90% of cards. I have a feeling it's somehow being detected internally on the PCM5100A as 44.1kHz, since all of the other oddball GF1 sampling rates work just fine. In any case, I have a simple software fix: at 28 active channels, force an output sampling rate of 44.1kHz and double each sample. It's not interpolated so it pretty much sounds the same as "real" 22.05kHz. The fix solves the issue on all of the affected cards I've tested.

That raises another approach to a fix: constant 44.1kHz output rate for all number of channels, just as the Interwave does it. At first I didn't attempt it because I was worried about available CPU for mixing and PSRAM bandwidth. But @wbc has experimented with creating firmware that outputs at this rate and it doesn't seem to be a problem. I'm wondering how people would react to that since it's less true to the original GUS and its GF1. I could make it switchable via pgusinit.

I would not mind a constant output rate - especially as an option in PGUSINIT - because it provides a functional enhancement to the sound quality. Also, as a composer of those days, I think I can say it felt like a compromise or a necessity to accept less fidelity to have access to more simultaneous voices.
Also, am I correct that the DAC uses a strong anti-aliasing filter (like the Interwave in GF1 mode) that is not the same as the classic GUS anyways? It would feel less of a loss then to have it render at full rate at all time.

I am not sure if the proposed render method (sample doubling) will be the standard for all cards? I have yet to hear it but my gut feeling says it will create aliasing noises because the output filter of the DAC is no longer matched to the render frequency. That may cause some tunes to sound harsh (but again, I would have to give it a go).

polpo wrote on 2024-02-17, 06:10:

I've determined the cause of silent audio in Doom and Dope reported by @Pickle and @HandOfFate, and I have a firmware fix! Many […]
Show full quote

I've determined the cause of silent audio in Doom and Dope reported by @Pickle and @HandOfFate, and I have a firmware fix! Many thanks to them for sending the cards back to me. At first I thought it was due to shipping damage or chipset incompatibility, but in this latest batch of cards I just made I started testing with Doom and noticed quite a few cards had the same problem. After eliminating the possibility of bad PSRAM, bad bus interface chips, or DMA bugs, I wondered if it was due to the DAC. Another person who had the same problem said not only was the demo Dope silent, playing the Demo's song in any MOD player was also silent. Dope is a 28-channel MOD file, which corresponds to a 22.05kHz GF1 mixing rate. And would you know it, Doom also runs at 28 channels. On the affected cards, loading any song into Fast Tracker II and playing with the number of active channels reproduces the issue: playback goes silent at 28 voices. Poking at the I2S signals going to the DAC with my scope showed audio being sent at that rate, but the DAC just wouldn't play it. I looked at the PCM510xA datasheet and it doesn't seem that 22.05kHz is really supported, especially at 16 bits per sample. I experimented with padding output to 24 or 32 bits per sample but that didn't alleviate the issue.

After searching the web for PCM5100A (or its variants PCM5101A and PCM5102A) and 22.050kHz, I found a couple posts on the TI forums that also report the same issue of no audio at 22.05kHz:
https://e2e.ti.com/support/audio-group/audio/ … ate-of-22-04khz
https://e2e.ti.com/support/audio-group/audio/ … hz-audio-format

So it seems that 22050Hz sampling rate is not officially supported by the PCM510xA despite it working on 90% of cards. I have a feeling it's somehow being detected internally on the PCM5100A as 44.1kHz, since all of the other oddball GF1 sampling rates work just fine. In any case, I have a simple software fix: at 28 active channels, force an output sampling rate of 44.1kHz and double each sample. It's not interpolated so it pretty much sounds the same as "real" 22.05kHz. The fix solves the issue on all of the affected cards I've tested.

That raises another approach to a fix: constant 44.1kHz output rate for all number of channels, just as the Interwave does it. At first I didn't attempt it because I was worried about available CPU for mixing and PSRAM bandwidth. But @wbc has experimented with creating firmware that outputs at this rate and it doesn't seem to be a problem. I'm wondering how people would react to that since it's less true to the original GUS and its GF1. I could make it switchable via pgusinit.

Thank you for the heads up. Just to clarify, is the DAC for v2.0 batch 1 cards different to the DAC on v2.0 batch 2 cards? Or all v2.0 cards have this issue?

polpo wrote on 2024-02-17, 06:10:

That raises another approach to a fix: constant 44.1kHz output rate for all number of channels, just as the Interwave does it. At first I didn't attempt it because I was worried about available CPU for mixing and PSRAM bandwidth. But @wbc has experimented with creating firmware that outputs at this rate and it doesn't seem to be a problem. I'm wondering how people would react to that since it's less true to the original GUS and its GF1. I could make it switchable via pgusinit.

Just as long as the internal interpolation is still done at the "output channel" dependent sampling rate... This was an issue with DOSBox for a long time, the internal interpolation was being done based on the (user specified) output rate and games that used software mixing (uploading interleaved buffers of left/right samples) suffered from channel bleeding.

digistorm wrote on 2024-02-17, 07:52:

I am not sure if the proposed render method (sample doubling) will be the standard for all cards? I have yet to hear it but my gut feeling says it will create aliasing noises because the output filter of the DAC is no longer matched to the render frequency. That may cause some tunes to sound harsh (but again, I would have to give it a go).

I'll post some samples of doubled and "real" 22.05kHz so people can compare.

zuldan wrote on 2024-02-17, 08:26:

Thank you for the heads up. Just to clarify, is the DAC for v2.0 batch 1 cards different to the DAC on v2.0 batch 2 cards? Or all v2.0 cards have this issue?

All PicoGUS cards ever made have a small chance of having this issue. It appears to be a fundamental problem that affects a certain percentage of the PCM510xA DAC family, which is used on all PicoGUS cards. In the latest batch of PicoGUS cards sold last week, I only sent out cards that didn't have this issue. Previous batches I didn't test at 22.05kHz so there's a chance some more slipped through. There's a chance the very first batch was lucky and none had the problem. The chance of a particular DAC chip exhibiting this behavior seems to be 5-15%.

Woot got my card in and so far it's working with Doom2 and Duke3d. Love it! I was wondering if anyone had tried to / had luck with getting the card to work in win98 se? I tried the windows driver in the GUS v4.11 software download but I just got some pop noises when sound tries to play.

polpo wrote on 2024-02-17, 06:10:

I've determined the cause of silent audio in Doom and Dope reported by @Pickle and @HandOfFate, and I have a firmware fix! Many […]
Show full quote

I've determined the cause of silent audio in Doom and Dope reported by @Pickle and @HandOfFate, and I have a firmware fix! Many thanks to them for sending the cards back to me. At first I thought it was due to shipping damage or chipset incompatibility, but in this latest batch of cards I just made I started testing with Doom and noticed quite a few cards had the same problem. After eliminating the possibility of bad PSRAM, bad bus interface chips, or DMA bugs, I wondered if it was due to the DAC. Another person who had the same problem said not only was the demo Dope silent, playing the Demo's song in any MOD player was also silent. Dope is a 28-channel MOD file, which corresponds to a 22.05kHz GF1 mixing rate. And would you know it, Doom also runs at 28 channels. On the affected cards, loading any song into Fast Tracker II and playing with the number of active channels reproduces the issue: playback goes silent at 28 voices. Poking at the I2S signals going to the DAC with my scope showed audio being sent at that rate, but the DAC just wouldn't play it. I looked at the PCM510xA datasheet and it doesn't seem that 22.05kHz is really supported, especially at 16 bits per sample. I experimented with padding output to 24 or 32 bits per sample but that didn't alleviate the issue.

After searching the web for PCM5100A (or its variants PCM5101A and PCM5102A) and 22.050kHz, I found a couple posts on the TI forums that also report the same issue of no audio at 22.05kHz:
https://e2e.ti.com/support/audio-group/audio/ … ate-of-22-04khz
https://e2e.ti.com/support/audio-group/audio/ … hz-audio-format

So it seems that 22050Hz sampling rate is not officially supported by the PCM510xA despite it working on 90% of cards. I have a feeling it's somehow being detected internally on the PCM5100A as 44.1kHz, since all of the other oddball GF1 sampling rates work just fine. In any case, I have a simple software fix: at 28 active channels, force an output sampling rate of 44.1kHz and double each sample. It's not interpolated so it pretty much sounds the same as "real" 22.05kHz. The fix solves the issue on all of the affected cards I've tested.

That raises another approach to a fix: constant 44.1kHz output rate for all number of channels, just as the Interwave does it. At first I didn't attempt it because I was worried about available CPU for mixing and PSRAM bandwidth. But @wbc has experimented with creating firmware that outputs at this rate and it doesn't seem to be a problem. I'm wondering how people would react to that since it's less true to the original GUS and its GF1. I could make it switchable via pgusinit.

Does this also affect v1.x cards and when can we expect the FW? Personally, I have no issues with Doom..

polpo wrote on 2024-02-17, 15:28:

All PicoGUS cards ever made have a small chance of having this issue. It appears to be a fundamental problem that affects a certain percentage of the PCM510xA DAC family, which is used on all PicoGUS cards. In the latest batch of PicoGUS cards sold last week, I only sent out cards that didn't have this issue. Previous batches I didn't test at 22.05kHz so there's a chance some more slipped through. There's a chance the very first batch was lucky and none had the problem. The chance of a particular DAC chip exhibiting this behavior seems to be 5-15%.

Would swapping the DAC on affected cards also be a possible solution?

DarkCreon wrote on 2024-02-17, 16:12:

Woot got my card in and so far it's working with Doom2 and Duke3d. Love it! I was wondering if anyone had tried to / had luck with getting the card to work in win98 se? I tried the windows driver in the GUS v4.11 software download but I just got some pop noises when sound tries to play.

my understanding win 3.1 works but as you found win9x does not work yet

Just wanted to say, I'm loving my PicoGUS 2.0! Working with everything I've thrown at it on the GUS side (FDOOM/Jazz/Trackers). Also the WP32 McCake mounted on the PicoGUS wavetable header works great too (Monkey Island/LSL3 Intelligent Mode/DOOM GM/etc).

System is a 386SX-40 ALi M1217-40 (https://theretroweb.com/motherboards/s/dfi-386sx-25-33-40ane)

appiah4 wrote on 2024-02-17, 19:00:

Does this also affect v1.x cards and when can we expect the FW? Personally, I have no issues with Doom..

It's totally up to chance that any given PCM510xA DAC will exhibit this issue, and that means any PicoGUS in the world so far. If yours works, it works, and the great majority of cards out there work fine at 22.05kHz.

Shponglefan wrote on 2024-02-17, 19:04:

Would swapping the DAC on affected cards also be a possible solution?

For a person making a PicoGUS from scratch for themselves, swapping the DAC would be fine, but it would be rolling the dice again. Unfortunately it's not a solution at the volumes and margins that PicoGUS sells at. I can't spend the time doing rework to swap the DAC on 5-15% of boards when I'm selling hundreds. That's why I'm looking at a firmware-based solution.

I've put together this video comparing 28 channel/22050Hz output on different firmwares, playing demo4 in The Ultimate Doom v1.9 and the 7800 phong polys part in Dope. This was recorded on a PicoGUS from the latest batch that has a DAC that doesn't have the 22050Hz output issue. The video shows the following in sequence:
- Stock PicoGUS firmware v1.0.2
- my experiment with sample doubling to play 22.05kHz at 44.1kHz
- wbcbz7's experiment with constant 44.1kHz (this one has some PSRAM contention/bandwidth issues in Doom resulting in stuttering near the end, which I think can be worked around)
- my real Gravis Ultrasound Classic
https://www.youtube.com/watch?v=e_cCG8Npul8

To my ear when I listen closely, the sample doubling approach is a bit more "alias-y" sounding for the reason that digistorm brought up earlier. Constant 44.1kHz sounds good and may be the best path if we can work around the stuttering issue. Attached is a spectrogram of the various cards – you can literally see the aliasing present on everything but the stock PicoGUS firmware v1.0.2 firmware. This is a testament to the great performance of the PCM5100A (when it works!). BTW, there are very few other DACs out there currently produced similar to the PCM510xA that don't need an MCLK input, so I'm a bit reluctant to do a hardware redesign around a different DAC.

To be fair the real GUS also seems to be prone to the same aliasing that the 5102 is prone to when forced to 44Khz? I'd personally hope that you retain 1.0.2 method (as that seems to have the least clipping and should be even clearer than the original GUS going by the spectrogram image) but I understand that probably means releasing two firmwares with each revision..

I think the classic GUS had a less aggressive output filter. It starts a bit earlier to filter out the highs and it leaves more in. The DAC in the PicoGUS sounds more like an Interwave card, which seems to have more of a brick-wall filter.
I think in DOOM the aliasing is not that disturbing because it is aliasing anyway because the DOOM samples are 11 kHz and are already doubled to match the 22 kHz of the 28 channel GUS. In music mode it is a bit more obvious.
I would like an option (don't know if it should be the default) to have that 44 kHz mode (like DOSBox). If you had sampled the next part of Dope (with the "fire clouds") it introduces additional percussion that sounds particularly "lisping" or "scratchy" because those samples are "downsampled" to 22 kHz. In DOSBox they sound much clearer because they are "upsampled" to 44 kHz. But it is *not* how it sounds on real hardware so it is less authentic. But it is nice to have, just like some people prefer particular upscalers on their retro machines.

A couple of ideas:

1. If the issue only occurs at exactly 22050 Hz, you could try deviating a bit from this sample rate. If 22049 or 22051 Hz works correctly, you could just set them as the output sample rate. This slows down / speeds up playback a little bit, but probably no one will notice (it's only 0.16 seconds of drift over an hour) and it's pretty much within the margin of clock tolerances of sound devices.

2. You could use a 44.1 kHz output sample rate at the DAC and use linear interpolation to upsample when channel count is above 14. This adds some aliasing and sheen above the Nyquist frequency without sounding as dirty as simple sample doubling. Sample doubling at only 28 channels is not a very good option because it creates a big jump in sound quality compared to 27 or 29 channels.

3. Fixed mixing at 44.1 kHz (like the Interwave) would be the best in my opinion. If performance becomes a bottleneck, you can gradually ramp down the output sample rate as the GUS does, just not as extreme. Even mixing at 32 kHz would be a great improvement compared to standard GUS.

The PCM is doing the right thing and does a very sharp cutoff above Nyquist, but this produces a dull sound compared to the GUS when the number of voices is high. Not sure what the GUS originally does in these cases. It probably lowers the actual sample rate of its DAC but does not change the output filter to cut off aliasing noise (this might be an engineering choice to "fill in" the missing high frequency content). To emulate this properly, the picoGUS should use a fixed output sample rate of 44.1 kHz, mix at the original GUS mixing rate for the number of voices activated (eg. 22050 Hz for 28 channels), then use BLEP upsampling to 44.1 kHz. The GUS probably also has some low pass filtering which reduces high frequency content which should be applied on the upsampled audio signal.

I personally think this is way too complicated and would rather like to see the added computational overhead to be used for higher quality mixing (point 3 above) instead. I really liked the improved quality of the Interwave in this regard and can't remember anyone complaining about it back in the day. 😀

Pickup my picoGUS from the post office today. I had a quick play around with it, it's in my 386DX40 (OPTi 82C495XLC chipset) paired with a Sound Blaster Pro 2 (CT1600). Seems to work great! I have looped the picoGUS to the line-in of SB.

So far I have tried Crystal Dream 2, Second Reality, Triton's GRAVIS.EXE and the Assembly 94 invitation intro. All seem to work great so far. When I have some more time I will do some better testing by going through the software listed on the Compatibility List.

👍

Edit: Oh, picoGUS is on IRQ7 and DMA 3 and the SB on IRQ5 and DMA 1.

pan069 wrote on 2024-02-22, 10:37:

Pickup my picoGUS from the post office today. I had a quick play around with it, it's in my 386DX40 (OPTi 82C495XLC chipset) paired with a Sound Blaster Pro 2 (CT1600). Seems to work great! I have looped the picoGUS to the line-in of SB.

So far I have tried Crystal Dream 2, Second Reality, Triton's GRAVIS.EXE and the Assembly 94 invitation intro. All seem to work great so far. When I have some more time I will do some better testing by going through the software listed on the Compatibility List.

👍

Very lucky. Mine will probably be here in about 2 to 3 weeks. It hasn’t left the US yet. I’m at the other end of the world!

zuldan wrote on 2024-02-22, 10:40:

pan069 wrote on 2024-02-22, 10:37:

Pickup my picoGUS from the post office today. I had a quick play around with it, it's in my 386DX40 (OPTi 82C495XLC chipset) paired with a Sound Blaster Pro 2 (CT1600). Seems to work great! I have looped the picoGUS to the line-in of SB.

So far I have tried Crystal Dream 2, Second Reality, Triton's GRAVIS.EXE and the Assembly 94 invitation intro. All seem to work great so far. When I have some more time I will do some better testing by going through the software listed on the Compatibility List.

👍

Very lucky. Mine will probably be here in about 2 to 3 weeks. It hasn’t left the US yet. I’m at the other end of the world!

I am also in AU. Placed my order 9 days ago but I think I ticked the faster delivery option.

pan069 wrote on 2024-02-22, 10:47:

I am also in AU. Placed my order 9 days ago but I think I ticked the faster delivery option.

Good thinking! May I ask where it is at the moment?

zuldan wrote on 2024-02-22, 10:50:

pan069 wrote on 2024-02-22, 10:47:

I am also in AU. Placed my order 9 days ago but I think I ticked the faster delivery option.

Good thinking! May I ask where it is at the moment?

Where is what? The picoGUS? It's in my machine. Playing MIDI files atm... 😀

pan069 wrote on 2024-02-22, 10:56:

Where is what? The picoGUS? It's in my machine. Playing MIDI files atm... 😀

Lucky bugger! I should have selected the fast shipping.

Are you enjoying it? What are you using it for other than playing midi files?