Possible implementation error in panning of GUS mode?

[digistorm79]

I am wondering if there is something wrong with the emulation of the panning of the GUS mode. Let me try to explain (because it may sound wrong at first). This all is no criticism of your hard labour, and maybe I am wrong altogether. But I just wanted to raise the question because it doesn't seem that anyone else is noticing.

So, I noticed that when using headphones, the position of instruments sounds more extreme than I was used to, sometimes making it unpleasant to listen to. So I started investigating a little bit...

I own a GUSpnp, so an Interwave card. I do not have a classic GUS, but hear me out. I checked the documentation of the Interwave chip and found formulas and an attenuation table of the GUS classic emulation mode of the Interwave chip, so, official documentation. The Interwave card produces roughly the volume levels for each channel as described by those formulas and attenuation data.

Then I started measuring the output of the PicoGUS and DOSBox-X and I found that the attenuation in decibels (so, logarithmicly) is roughly twice of what is in the documentation of AMD (who made the Interwave chip). I then started investigating the source code of the PicoGUS firmware and DOSBox-X and found that they are quite similar, and the most striking thing is that I found that the PicoGUS uses a "fixed table" for the panning attenuation that matches exactly the Interwave documentation. This can almost not be accidental. I have difficulty reading the various optimisations with bit shifts and what not, but I think I even recognise some of the formulas that AMD provides in their documentation for the implementation of linear to logarithmic conversion.

But then my question is: If it seems that effort was made to implement the Interwave panning table (for the classic mode), why does it sound different then the actual Interwave? I do have some observations. When I sum up the measured left and right levels of my actual Interwave board, the mono output does not have a constant value as it should and most software mixing routines do. But the PicoGUS and DOSBox-X - with the doubled up attenuation in dB's (which is logarithmic, not linear) - do feature that constant output level in mono. This would be sonically "correct", but it is not what the GUSpnp with Interwave in classic mode does, nor is it what the documentation says it should do. So my question is: Why? Did you check the panning levels with a real classic GUS (which I unfortunately do not have), and if you did, does it do it differently?

The reason why I make all this effort to bore you with a long question, is that is seems very odd to me that Gravis would intentionally make an attenuation table for the emulation of the panning of the classic GUS - which almost certainly is baked into the hardware - and then do it wrong. So, if Gravis did describe it correctly, why seem the PicoGUS and some emulators to do it wrong? It seems like the PicoGUS applies a factor of 2 before the linear to logarithmic conversion is done, but I cannot figure out the source code quite enough to confidently say so. I tried to reproduce some calculations with some scrap code, but obviously I would need a lot more time to investigate how the source code of the PicoGUS is actually working, and I am not used to all the bit shifting and what not.

But, if it does appear to be a bug and not a correct emulation the of the real GUS, I would like to ask if it can be fixed, because it does bother me a bit that demo's do not sound like I am used to, and the extreme panning is a bit jarring on headphones.

I assume that you already own every possible resource of GUS documentation that exists out there so you probably know what documentation I am talking about. But if you need any more information or want the measurement I made, I can send them to you.