dr.zeissler wrote on 2023-09-06, 17:21:

Is it possible that AC97 is muted in Dos?

You can disable the entire integrated audio in the BIOS usually, or there are sbemu volume settings that can be adjusted (sbemu /? or something for more info on that command).

I have experienced on on laptop that the audio was very loud on the default volume settings while on another it was normal with the same sbemu settings.

It is a bit problematic, but I think the behavior with SB-Emu shows exactly the problem I am facing right now.

i865G AC97 AD1980 => Bios Setting enable or auto

WARP4 => 3.1.9 AC97 Driver => AC97 Audio is working fine
WIN2K => AC97 Audio is working fine (mapped to irq 17 shown in device-manager
SBEMU => conflict irq5 reported => I7 = everything is working fine but no sound at all, seems to be fully muted
AMITHLON => "PCIscan" shows =i5 like SM-Bus controller also I5 => Kernel310 with drivers 0.90 => everything seems to be OK but sound is not working or is completely muted.

In the BIOS everything on PCI is set to AUTO = PlugNplay
So in plain DOS and in AMITHLON AC97 is muted, but why?!?

Specs of the AD1980 https://www.analog.com/media/en/technical-doc … eets/AD1980.pdf

Interestingly there are some findings of muted AD1980 => https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=140591
This is on FSC C610 D1644 i865g AC97 AD1980, my E600 D1534 is also i865g AC97 AD1980

Fujitsu C610 seems to wire SURR_OUT/HP_OUT for + * internal speaker, and LINE_OUT for lineout AND headphone jacks; + * by se […]
Show full quote

Fujitsu C610 seems to wire SURR_OUT/HP_OUT for
+ * internal speaker, and LINE_OUT for lineout AND headphone jacks;
+ * by setting previous 0x0420, internal speaker works but
+ * no output for either jacks.
+ * ASUS A9T may had been working by not setting the register because
+ * it only wired LINE_OUT.

Too bad no info on FSC E600, but I think that might be similar. Actuall tests indicate that there is still a difference between
AD1980 on D1534 to D1644 (both i865g AC97 AD1980)

I'm guessing that diff is from FreeBSD? (it would be clearer if it were surrounded by [code][/code])
The comment is a little confusing, suggesting that 0x400 is better for all instances but only applies it to the Fujitsu C610.
Anyway, I think this is the SBEMU equivalent (not even compile-tested, I don't have a toolchain):

1diff --git a/MPXPLAY/AU_CARDS/SC_ICH.C b/MPXPLAY/AU_CARDS/SC_ICH.C
2index 0df0f76..3c5aac2 100644
3--- a/MPXPLAY/AU_CARDS/SC_ICH.C
4+++ b/MPXPLAY/AU_CARDS/SC_ICH.C
5@@ -242,6 +242,14 @@ static void snd_intel_ac97_init(struct intel_card_s *card,unsigned int freq_set)
6  snd_intel_codec_write(card, AC97_HEADPHONE_VOL,     0x0202);
7  snd_intel_codec_write(card, AC97_EXTENDED_STATUS,AC97_EA_SPDIF);
8 
9+ unsigned int vid1 = snd_intel_codec_read(card, 0x7c);
10+ unsigned int vid2 = snd_intel_codec_read(card, 0x7e);
11+ // AD1980
12+ if (vid1 == 0x4144 && vid2 == 0x5370) {
13+   unsigned int misc_ctrl = snd_intel_codec_read(card, 0x76) | 0x0400;
14+   snd_intel_codec_write(card, 0x76, misc_ctrl);
15+ }
16+
17  // set/check variable bit rate bit
18  if(freq_set!=48000){
19   snd_intel_codec_write(card,AC97_EXTENDED_STATUS,AC97_EA_VRA);

The LSB of vid2 will be different for other Analog Devices AC97 codecs and FreeBSD seems to patch other models as well.
AFAICT, SC_ICH.C doesn't appear to do any codec-specific patches, it doesn't even report which codec vendor/model is detected (unlike for HDA), so there'll be a cleaner way of doing this if this is expanded to more codecs. Also, should use proper #defines instead of magic numbers.

This is far more advanced than I can do. Google only found the "diff" via search "AC97 muted".
I think I still need more advice on how to check and fix that issue. Thx!

In plain dos I checked SBEMU and it always gave me an IRQ confilict on I5, regardless what I setup in the bios.
The SMBusController seems to be wired to AC97, it moved also over to I7 if I set it hard to I7 via lane 2 = IRQ7.

So in short, I5 does not work on SBEMU on that machine.

If use standard values in the Bios (AUTO) and use I7 in the SET BLASTER then SBEMU does not give me any issues,
everything seems to be fine (setblaster.exe teels me 1..2..3 OK) but I can't hear anything, in any demo or game it's the same,
SB is found on A220/I7 no error but also no sound.output at all.

I read that that AD1980 is sometimes routed wrong. I don't know if the working OS/2 or Win2K/98 etc. drivers do
fix that in some way, but on DOS (SBEMU) and Amithlon AC97(AD1980) seems muted or routed wrong.

Some threads tell me that AC97(AD1980) on some FSC Boards like C610 is routed to the PINK (Surround?) output in LINUX,
but there is no PINK output on my E600/D1534 machine. I'll have a look, because I have C610 too if I can get SBEMU/Amithlon
working on that machine and report later.

Does this application do anything for you? https://github.com/Kaproncai/Unmute

dr.zeissler wrote on 2023-09-07, 05:10:

I think I still need more advice on how to check and fix that issue. Thx!

AIUI the patch value 0x0400 turns the surround/headphone output into an amplified mixer output. The existing line-out is still left as the mixer output, just at line-level. You can try tracing how your systems are routed, page 6 of the datasheet shows pins 39/41 are surround/heapdphone output and pins 35/36 are line-out.

dr.zeissler wrote on 2023-09-07, 05:10:

In plain dos I checked SBEMU and it always gave me an IRQ confilict on I5, regardless what I setup in the bios.
The SMBusController seems to be wired to AC97, it moved also over to I7 if I set it hard to I7 via lane 2 = IRQ7.

So in short, I5 does not work on SBEMU on that machine.

If you want to use IRQ 5, try setting that to "Reserved for ISA" or similar in the BIOS setup.

veelstekel wrote on 2023-09-07, 07:03:

Does this application do anything for you? https://github.com/Kaproncai/Unmute

This unmutes PCBEEP on a Realtek or IDT HDA codec. That won't help dr.zeissler's system which uses an Analog Device AC97 codec and has no audible PCM audio, perhaps due to different routing of the mixer output.

veelstekel wrote on 2023-09-07, 07:03:

Does this application do anything for you? https://github.com/Kaproncai/Unmute

reports "unsupported".

AIUI the patch value 0x0400 turns the surround/headphone output into an amplified mixer output. The existing line-out is still left as the mixer output, just at line-level. You can try tracing how your systems are routed, page 6 of the datasheet shows pins 39/41 are surround/heapdphone output and pins 35/36 are line-out.

Thx, that's a bit to advanced for me. You mean messuring on these Pins with propriet tools (which I don't have)

If you want to use IRQ 5, try setting that to "Reserved for ISA" or similar in the BIOS setup.

That is what I can try. So PCI-Lane2 restricket to ISA...I am not sure if there is an option for this. I'll have a look. Thx!

Now the strange things!

I tested my other machine "FSC C610 I865g AD1980 D1644 Mainboard" on SBEMU.
(I thought it had the PINK (surround) output-jack but it does not, it has the same as my main machine FSC E600)

1. IRQ5 does report the exact same conflict as on the other board
2. IRQ7 reports everything is OK, AC97 is still muted, BUT not on all tested software. Mostly it does not work, but on some scene stuff OPL or SB works. But only on very view.
3. Interestingly the working scene-stuff is still not working on the main machine. On the main machine (FSC-E600) everything is muted in SBEMU.

So same codec, same chipset, partial (minimal) working... how can this be...strange, very strange.

@jtchip
Is it possible that you can sent me a patched version of "mpxplay" to test them on my FSC machines like E600/C610?
Do you need any additional screenshots or a video of that issue?

We are talking DOS (SBEMU) here, but the main focus is Amithlon. I think it's nonetheless a try to check and perhaps fix it for dos if possible. If this can be fixed for amithlon will be even a harder target and will perhaps need the help of the kernel-devs which were inactive for 10+ years. On Dos I can still use Covox, OPL3lpt, but if SBEMU can get working that would be my main option so LPT would be free for hooking up C64Floppy (1541) or ParCP (Data to AtariSt) and other things.

Hopefully only a Bios-thing... but I think it's not... Thx for your help on this, I really appreciate it.

No progress here. Only option for PCI-Lanes (AUTO/IRQx/DISABLE)

Regardless what I do in this, it does not work. Never get any output.

LPT set to I7 / PCI-LANE 2 = DISABLE => machine stops booting
LPT set to I7 / PCI-LANE2 = AUTO or IRQ5 => SBEMU i5 conflict, I7 works, everything muted
LPT set to i5 / PCI-LANE 2 = DISABLE => machine stops booting
LPT set to i5 / PCI-LANE 2 = AUTO or IRQ7 => SBEMU i7 conflict, i5 works, everything muted

I checkt Win2k settings. On win2k I5 is SMBUSController and AC97 is I17.
I deactivate everything possible in the bios (LAN,COM,LPT, USB,FLOPPY) and it still does not work.

?

dr.zeissler wrote on 2023-09-08, 07:27:

You mean messuring on these Pins with propriet tools (which I don't have)

Either check for continuity (with a multimeter) between the output sockets (line-out or headphone) and the pins on the chip, or you can follow the traces from the chip on the PCB to see where they lead to.

dr.zeissler wrote on 2023-09-08, 07:31:

I tested my other machine "FSC C610 I865g AD1980 D1644 Mainboard" on SBEMU.
2. IRQ7 reports everything is OK, AC97 is still muted, BUT not on all tested software. Mostly it does not work, but on some scene stuff OPL or SB works. But only on very view.
3. Interestingly the working scene-stuff is still not working on the main machine. On the main machine (FSC-E600) everything is muted in SBEMU.

OK, the fact that some software does work on the C610 means the AC97 codec isn't muted there. This points to an incompatibility between the software and SBEMU, specifically how the SB is emulated, perhaps the port trapping or emulation of the IO ports isn't accurate enough.

dr.zeissler wrote on 2023-09-08, 07:31:

So same codec, same chipset, partial (minimal) working... how can this be...strange, very strange.

It could be an audio routing issue on the E600. Try MPXPLAY on both systems as the output drivers are derived from that.
Another thing you could try is Linux (the current Debian 12 still has a 32-bit version), there should be a mixer setting called "Line HP Swap Switch" (which appears to control the same bits the FreeBSD patch modifies), see if that setting needs to be different on the 2 machines to get audio.

dr.zeissler wrote on 2023-09-08, 07:59:

Is it possible that you can sent me a patched version of "mpxplay" to test them on my FSC machines like E600/C610?

I'm afraid I can't, I don't have a toolchain to build it. I'm happy to read code and propose some random patches 😀 The last time I developed for DOS was around 1995/96 and don't have much time to get back into it.

dr.zeissler wrote on 2023-09-08, 20:17:

No progress here. Only option for PCI-Lanes (AUTO/IRQx/DISABLE) […]
Show full quote

No progress here. Only option for PCI-Lanes (AUTO/IRQx/DISABLE)

Regardless what I do in this, it does not work. Never get any output.

LPT set to I7 / PCI-LANE 2 = DISABLE => machine stops booting
LPT set to I7 / PCI-LANE2 = AUTO or IRQ5 => SBEMU i5 conflict, I7 works, everything muted
LPT set to i5 / PCI-LANE 2 = DISABLE => machine stops booting
LPT set to i5 / PCI-LANE 2 = AUTO or IRQ7 => SBEMU i7 conflict, i5 works, everything muted

I checkt Win2k settings. On win2k I5 is SMBUSController and AC97 is I17.
I deactivate everything possible in the bios (LAN,COM,LPT, USB,FLOPPY) and it still does not work.

I'm guessing this is the E600? If MPXPLAY doesn't give you sound output on it, then SBEMU probably won't either. The SB IRQ affects the SB emulation, if the software detects the SB and "plays" sound, at least without hanging or crashing, then the SB emulation is probably working and it's the output to the AC97 that's either muted or routed differently.

Thx! I checked another of my FSC desktops. The FSC S2 D1382 and it behaves like the C610 so SBEMU does not work on I5 but on I7 it works.
It plays exactly the software like the C610 does and it also works in amithlon with kernel 310 + drivers 0.90.

So in short, ONLY the E600 machines have that AC97 issue that the sound is muted or routed wrong in DOS and Amithlon.
My Multiboot has not been completed because linux is not installed yet. I will install linux and report how this behaves.

Because amithlon has also some linux-parts when starting I pressume it will be muted too...we will see.
(and of course I 'll checkout mpxplay)

Thx
Doc

...The SB IRQ affects the SB emulation, if the software detects the SB and "plays" sound, at least without hanging or crashing, then the SB emulation is probably working and it's the output to the AC97 that's either muted or routed differently.

This is what amithlon does on this E600. It does not complain any issue. The music-player works and shows the played music with it's graphical analyzer.

The muting or routing is controlled via software, or in the rom/firmware of the AC97 chip? So is there a steady solution (fixing the firmware?),
or has a patched driver be loaded every time to generally fix that?

Normally I would think it has to be patched every dos or amithlon bootup, because Win2K (perhaps Win9x) and OS/2 are not effected on this.

Doc

As you already guessed....mpxplay runs fine on E600 in plain dos, I can see the MP3 playing but I can't hear anything.

I have the same problem on a Dell M6400, and posted earlier on in the thread. I was secretly hoping that in the meantime, a DOS program was written that would send custom config commands to the codec, so you could lookup the mixer and routing verbs in the codec's datasheet and try to reroute or unmute. I intended to have a look at adapting Unmute's code for this purpose (or even MPXPlay) but I don't make it anywhere near my PCs these days!

dr.zeissler wrote on 2023-09-09, 07:59:

The muting or routing is controlled via software, or in the rom/firmware of the AC97 chip? So is there a steady solution (fixing the firmware?),
or has a patched driver be loaded every time to generally fix that?

AIUI, the FreeBSD patch enables the surround/headphone output as an extra mixer output so it's done in software. The line-out should still function as a line-out but I'm not sure why it doesn't on the E600. If you trace the output lines of the line-out and surround/headphone-out from the codec, it might give a clue as to how they've been wired up. It's a long-shot but have you tried the headphone output? Or every single 3.5mm jack?
The Windows driver does it correctly depending on which system it's in, it's just the other drivers that have to figure out how to replicate that. Usually people take a register dump in Windows, see what's different, then replicate that in the other driver being developed. Someone will have to do custom build of MPXPLAY or SBEMU for that though.

Thx, custom software-builds to fix that issue is not what i intent. A general fix should be the goal.
So for dos the fix should be a custom mixer within sbemu ot an external one.
For Amithlon the fix has to be done in the kernel 3xx or the drivers 0.90.

I think both things a unrealistic to get fixed in the near future or at all.
I am thinking about changing to another machine.

Doc

PS:
I already had some other issues with the AC97 dos-support to get line-in when using
LPT-devices. but that was a bit other toppic. It seems that AC97 is not fully "controled"
in anything other than windows. AC97 codecs and DOS mixers

I rechecked:
- FSC S2 => AC97 working in SBEMU
- FSC E600 => AC97 routed wrong or muted (on all output jacks)
- FSC E620 => AC97 working in SBEMU
- FSC E5905 => AC97 working in SBEMU
- FSC C610 => AC97 working in SBEMU

How dumb can this be, the optimal machine for my purpose (small, silent, agp low-profile, 2x Full PCI slots up to 2940UW-PCI, internel full 3,5" Floppy (not slimline) internal Full 5,25 slot, full IDE not SATA interface) but not working on AC97...man what a shitty situation... now I start to check out if there is any plan B. This can only be done if I let something down...

Doc