VOGONS


First post, by digger

User metadata
Rank Member
Rank
Member

So I dusted off an old yet interesting piece of code I found on the internet, that some of you are probably already familiar with: Jeff Leyda's .wav DOS player for ICH AC'97 audio devices.

It's small, simply written to do one job, very well documented, with well-structured, well-commented and quite understandable assembly code. It's the first example of modern PCI sound programming that I didn't find intimidating.

And most of all: it works! 😀

Long story short, I need people with actual AC'97 sound hardware (Intel southbridges at first, in a later stage perhaps also implementations from other chipset vendors) to test my recent changes to it.

My ultimate goal is to use these sources a basis for a a VBE/AI DOS sound driver for AC'97 sound devices, which could one day perhaps ship with FreeDOS.

Anybody care to help me with this? I mean testing, although code contributions would be absolutely welcome as well!

I've attached a recent build that you can try. If you prefer to build from source, you can find it (including my modifications to it) here: https://github.com/volkertb/ich2player

The code can be built with MASM (Microsoft) or WASM (Open Watcom).

In particular, I'd like to test on the following southbridges:

  • 82801AA AC'97 Audio Controller (ICH)
  • 82801AB AC'97 Audio Controller (ICH0)
  • 82801BA/BAM AC'97 Audio Controller (ICH2)
  • 82801CA/CAM AC'97 Audio Controller (ICH3)
  • 82801DB/DBL/DBM AC'97 Audio Controller (ICH4)
  • 82801EB/ER AC'97 Audio Controller (ICH5)
  • 6300ESB AC'97 Audio Controller (ESB)
  • 82801FB/FBM/FR/FW/FRW AC'97 Audio Controller (ICH6)
  • 82801GB/GBM/GR/GH/GHM AC'97 Audio Controller (ICH7)
  • 82440MX AC'97 Audio Controller (440MX, technically not a southbridge)

If you have any systems or laptops with any of these southbridges or chipsets in them, would you care to help me test this?

I'd very much appreciate it. Thank you! 😊

Volunteers with other AC'97 compatible hardware not on this list are welcome too! Let me know what chipset you'll be testing with exactly, though, because I may have to add the vendor and/or device IDs for them to the sources for it to have a chance of working at all.

Oh, and be careful when you specify the `/v` parameter, since that will set the line-out and master output volume of your AC'97 device to the maximum level. If you have another tool to set the volume before running the tool, then it's best to leave the `/v` parameter out. In most cases, your AC'97 device will be muted by default, though, so bear that in mind when you don't hear any audio while testing.

Oh, and Jeff, if you happen to read this as well: thank you for sharing this cool bit of software with the world, along with the sources. It's proven quite educational! I hope you're well, wherever you are.

In more detail:

The original code had only ICH2 (82801BA/BAM) southbridge support enabled, since that was the only hardware (Intel 810 or 815) that he had available to test with at the time.

However, when I added a few lines to enable ICH (82801AA0) support as well, I found that that worked fine in QEMU/KVM and VirtualBox VMs, when I had the AC'97 sound device emulation enabled in both hypervisors.

That made me confident enough to enable support for ICH and ICH0 (which came between the original ICH and the ICH2) as well.

In the comments of the source code, Jeff mentioned that he expected later Intel ICH southbridges to be compatible as well, so I looked up the PCI device IDs of all the later Intel AC'97 devices, going all the way to ICH7, and added "support" for those to the utility as well.

...Or at least I *think* I did. From what I understood in these thread on the Flat Assembler board, configuring the codec properly (unmuting, setting the volume, etc) might not be entirely 100% compatible in later southbridges, such as ICH4:

So perhaps some tweaks or changes to that part of the source code (specific to certain southbridges and/or certain different brands of codec) might be necessary after all.

I also perused the intel8x0 ALSA Linux kernel driver sources to get some clues, but that is a pretty hefty piece of code. At first glance it did seem that there were a lot of vendor-specific changes, but I was expecting (and kind of hoping) that between devices of the same single vendor (Intel), the compatibility would be mostly 100%. That may have been a naive assumption, though. 😅

Attachments

  • Filename
    README.txt
    File size
    7.63 KiB
    Downloads
    14 downloads
    File license
    Public domain
  • Filename
    player.exe
    File size
    2.51 KiB
    Downloads
    11 downloads
    File license
    Public domain

Reply 1 of 25, by dionb

User metadata
Rank l33t
Rank
l33t

Right, can help 😀

Downloaded player.exe, stuck it on a DOS IDE DOM running 6.22 and stuck that in a few systems.

Compaq SW400 motherboard (from AP550 workstation) with i840 chipset and 82801AA (ICH):
- unsure about PnP status (no option in Compaq OEM BIOS)
- detects ICH
- no audio output without /v flag
- after applying /v flag, .wav files play back, but incredibly compressed (i.e. entire sample in fraction of a second). I tried various .wav files including one known to be 16b stereo (PCM1622S.WAV sample file from Mediavision PAS16 installation)

Gigabyte GA-6WMM7 with i810 chipset and 82801AA (ICH):
- PnP aware OS: no
- detects ICH
- .wav files play back, but incredibly compressed (i.e. entire sample in fraction of a second). I tried various .wav files including one known to be 16b stereo (PCM1622S.WAV sample file from Mediavision PAS16 installation)

Compaq TR100 board with i815 chipset and 82801BA (ICH2):
- PnP aware OS: not clear, but able to assign and change IRQ in BIOS
- detects ICH2
- absolutely no sound, regardless of /v flag

Not good. I suspect .WAV file compatibility may be part of the problem on the first two. Do you have a known-good .wav file I could test with?

Reply 2 of 25, by digger

User metadata
Rank Member
Rank
Member
dionb wrote on 2020-05-25, 16:11:

Right, can help 😀

Thank you, fellow Amsterdammer! 😀

Downloaded player.exe, stuck it on a DOS IDE DOM running 6.22 and stuck that in a few systems. […]
Show full quote

Downloaded player.exe, stuck it on a DOS IDE DOM running 6.22 and stuck that in a few systems.

Compaq SW400 motherboard (from AP550 workstation) with i840 chipset and 82801AA (ICH):
- unsure about PnP status (no option in Compaq OEM BIOS)
- detects ICH
- no audio output without /v flag
- after applying /v flag, .wav files play back, but incredibly compressed (i.e. entire sample in fraction of a second). I tried various .wav files including one known to be 16b stereo (PCM1622S.WAV sample file from Mediavision PAS16 installation)

Oh yeah, I should have mentioned that in my opening post: the player is currently hard-coded to play back every WAV file at 44100kHz, regardless of the file's actual intended playback frequency. The file name PCM1622S.WAV implies a 16-bit 22kHz stereo file. Such a file would be played back at twice the speed. So it might just be as intended.

A good next step for improvement might be to have the tool analyze the file for a possible WAVE_FORMAT_EXTENSIBLE header to see if there is a specific frequency that the file is intended to be played at, and if so, configure the sound device to play back the digital audio at that rate. I'll try to have a go at that.

Gigabyte GA-6WMM7 with i810 chipset and 82801AA (ICH): - PnP aware OS: no - detects ICH - .wav files play back, but incredibly […]
Show full quote

Gigabyte GA-6WMM7 with i810 chipset and 82801AA (ICH):
- PnP aware OS: no
- detects ICH
- .wav files play back, but incredibly compressed (i.e. entire sample in fraction of a second). I tried various .wav files including one known to be 16b stereo (PCM1622S.WAV sample file from Mediavision PAS16 installation)

OK, same southbridge model and same encouraging result. Good to know for sure that the tool works with actual ICH devices as well, and not just with emulated ones in VMs. 😀

Compaq TR100 board with i815 chipset and 82801BA (ICH2): - PnP aware OS: not clear, but able to assign and change IRQ in BIOS - […]
Show full quote

Compaq TR100 board with i815 chipset and 82801BA (ICH2):
- PnP aware OS: not clear, but able to assign and change IRQ in BIOS
- detects ICH2
- absolutely no sound, regardless of /v flag

Okay, that one is interesting, especially since the original author of the tool had only an ICH2-based motherboard to develop and test the code with, and therefore ICH2 was the only variant that he had initially enabled in the code. This might be an example of different AC'97 codecs being wired up to the controller differently, requiring adjustment to the volume setting code.

Could you check in Win9x (or whatever more modern OS you might have installed on these systems) exactly what driver (from which vendor and such) you have installed, and what sound devices are shown in the Device Manager?

Not good. I suspect .WAV file compatibility may be part of the problem on the first two. Do you have a known-good .wav file I could test with?

Sure. I'll upload the files that I created and tested the tool with myself.

I used the espeak speech synthesizer and ffmpeg in a recent Ubuntu Linux OS to generate and convert the WAV files as follows:

espeak "Your sound card works perfectly." --stdout | ffmpeg -i - -ar 44100 -ac 2 -f wav sndtest1.wav
espeak "Enjoying yourself?" --stdout | ffmpeg -i - -ar 44100 -ac 2 -f wav sndtest2.wav
espeak "It doesn't get any better than this!" --stdout | ffmpeg -i - -ar 44100 -ac 2 -f wav sndtest3.wav

Espeak apparently synthesizes the speech at 22kHz and I found no obvious way to have it render the resulting audio at 44.1kHz instead, so I converted it with ffmpeg instead. I'll also attach the results to this message.

Let me know if the result sounds more normal. (By the way, the originally generated audio is already quite fast.)

Thanks again for your help in testing this!

Attachments

  • Filename
    sndtest.zip
    File size
    432.71 KiB
    Downloads
    11 downloads
    File comment
    sound test files generated with espeak and ffmpeg
    File license
    Public domain

Reply 3 of 25, by digger

User metadata
Rank Member
Rank
Member

By the way, when you tried it with the Compaq TR100 board, did you get the idea that it was actually playing back the file, but just with muted audio? Did it behave like it was playing, so a delay before seeing the DOS prompt that took about as long as it did to play the file on he other two machines? Or did it hang or do other weird stuff, like immediately quitting?

Reply 4 of 25, by dionb

User metadata
Rank l33t
Rank
l33t
digger wrote on 1970-01-01, 04:25:

[...]
Thank you, fellow Amsterdammer! 😀

It's a small world 😉

[...]
Oh yeah, I should have mentioned that in my opening post: the player is currently hard-coded to play back every WAV file at 44100kHz, regardless of the file's actual intended playback frequency. The file name PCM1622S.WAV implies a 16-bit 22kHz stereo file. Such a file would be played back at twice the speed. So it might just be as intended.

The .TXT file says multiple sample rates supported, but that could explain something. Sounded a lot faster than 2x though...

A good next step for improvement might be to have the tool analyze the file for a possible WAVE_FORMAT_EXTENSIBLE header to see if there is a specific frequency that the file is intended to be played at, and if so, configure the sound device to play back the digital audio at that rate. I'll try to have a go at that.

[...]

OK, same southbridge model and same encouraging result. Good to know for sure that the tool works with actual ICH devices as well, and not just with emulated ones in VMs. 😀

It's consistent at least.

[...]

Okay, that one is interesting, especially since the original author of the tool had only an ICH2-based motherboard to develop and test the code with, and therefore ICH2 was the only variant that he had initially enabled in the code. This might be an example of different AC'97 codecs being wired up to the controller differently, requiring adjustment to the volume setting code.

Tbh I hate this kind of OEM board. Could be anything. Normally I avoid them, but I also tend to avoid i8xx-series chispets, but here we are, so have to make the best of it.

Could you check in Win9x (or whatever more modern OS you might have installed on these systems) exactly what driver (from which vendor and such) you have installed, and what sound devices are shown in the Device Manager?

Could be a challenge, I installed WinXP on it once, now it's past activation deadline. But can see about installing Win98SE...

[...] Sure. I'll upload the files that I created and tested the tool with myself. […]
Show full quote

[...]
Sure. I'll upload the files that I created and tested the tool with myself.

I used the espeak speech synthesizer and ffmpeg in a recent Ubuntu Linux OS to generate and convert the WAV files as follows:

espeak "Your sound card works perfectly." --stdout | ffmpeg -i - -ar 44100 -ac 2 -f wav sndtest1.wav
espeak "Enjoying yourself?" --stdout | ffmpeg -i - -ar 44100 -ac 2 -f wav sndtest2.wav
espeak "It doesn't get any better than this!" --stdout | ffmpeg -i - -ar 44100 -ac 2 -f wav sndtest3.wav

Espeak apparently synthesizes the speech at 22kHz and I found no obvious way to have it render the resulting audio at 44.1kHz instead, so I converted it with ffmpeg instead. I'll also attach the results to this message.

Let me know if the result sounds more normal. (By the way, the originally generated audio is already quite fast.)

Thanks again for your help in testing this!

Tnx, will give it a shot tomorrow.

Reply 5 of 25, by digger

User metadata
Rank Member
Rank
Member
dionb wrote on 2020-05-25, 22:47:

The .TXT file says multiple sample rates supported, but that could explain something. Sounded a lot faster than 2x though...

Hmmm, now that you mention it, and after I've taken another look at the code, you're right, it does seem to make at least an attempt to read the sample rate from the WAV file, if available. But apparently not all WAV files include sample rate information in their metadata. So if it can't find it, I guess it somehow either falls back to 44100kHz, or it happens to be the default in the device and it remains unchanged.

I guess I got confused by the comment line "enable codec, unmute stuff, set output rate to 44.1" in codec.asm, as well as the hard-coded define "SAMPLE_RATE_441khz" in codec.inc. But that constant isn't used anywhere in the code, at least not anymore. So apparently both that comment line and the constant are remnants of an earlier version in which the sample playback rate was still hard-coded.

So apparently the raw audio output from espeak (before I ran it to ffmpeg to resample it) didn't contain the necessary WAV metadata for the tool to detect the correct sample rate. But I'll have to retry that to make sure.

Tbh I hate this kind of OEM board. Could be anything. Normally I avoid them, but I also tend to avoid i8xx-series chispets, but here we are, so have to make the best of it.

Well, at least it comes in handy now for this test, if nothing else. 😀

Could be a challenge, I installed WinXP on it once, now it's past activation deadline. But can see about installing Win98SE...

Cool! If you install Win98SE, one other thing that you'll be able to try is to unmute the sound device and set its volume in Windows and then exit to DOS (which you could still do in Win9x OSes, I believe) and then run the player, to see if it's indeed just the unmuting and volume changing part that's not (yet) working.

Tnx, will give it a shot tomorrow.

I'm curious about your results. Thanks again and good night for now!

Reply 6 of 25, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie
digger wrote on 2020-05-25, 23:48:

...But apparently not all WAV files include sample rate information in their metadata.

This is not true. Such files are not valid WAV files by definition. Of course there can be files that contain only raw pcm data but these are not WAV files. WAV files have to contain WAVEFORMAT or WAVEFORMATEX header and the nSamplesPerSec field is mandatory otherwise no player could play these files properly. If we are talking about this pcm1622s.wav file it definitely contains proper header with valid sample rate info. So the problem must be something else.
https://github.com/ayushev/encoder/blob/maste … st/pcm1622s.wav

Website, Facebook, Youtube
Falcosoft Midi Player + Munt VSTi + BassMidi VSTi topic

Reply 7 of 25, by Benedikt

User metadata
Rank Member
Rank
Member
digger wrote on 2020-05-25, 23:48:
dionb wrote on 2020-05-25, 22:47:

The .TXT file says multiple sample rates supported, but that could explain something. Sounded a lot faster than 2x though...

Hmmm, now that you mention it, and after I've taken another look at the code, you're right, it does seem to make at least an attempt to read the sample rate from the WAV file, if available. But apparently not all WAV files include sample rate information in their metadata. So if it can't find it, I guess it somehow either falls back to 44100kHz, or it happens to be the default in the device and it remains unchanged.

I think I read somewhere that the AC'97 standard only mandates 48kHz and that everything else is optional, so maybe the specific CODEC chip in question does not even support other sample rates?
Just guessing here.

Reply 8 of 25, by digger

User metadata
Rank Member
Rank
Member
Falcosoft wrote on 2020-05-26, 07:21:

This is not true. Such files are not valid WAV files by definition. Of course there can be files that contain only raw pcm data but these are not WAV files. WAV files have to contain WAVEFORMAT or WAVEFORMATEX header and the nSamplesPerSec field is mandatory otherwise no player could play these files properly. If we are talking about this pcm1622s.wav file it definitely contains proper header with valid sample rate info. So the problem must be something else.
https://github.com/ayushev/encoder/blob/maste … st/pcm1622s.wav

Hmmm, okay, that's interesting. In that case, it increasingly begins to look like the sample rate configuration part of the code isn't working properly either, or that it perhaps doesn't work the same on every combination of ICH revision and AC'97 codec. As a first next step, I'll let the player output the sample rate that it detected from the file, to make sure if at least that part is working.

Benedikt wrote on 2020-05-26, 08:05:

I think I read somewhere that the AC'97 standard only mandates 48kHz and that everything else is optional, so maybe the specific CODEC chip in question does not even support other sample rates?
Just guessing here.

Good point. I'll do some more research on this.

In the meantime, if any of you have any other motherboards with an ICH southbridge (any revision up to ICH7) to test this on, and is willing to help me test this, I would appreciate it! Thanks. 🙂

Reply 9 of 25, by dionb

User metadata
Rank l33t
Rank
l33t
digger wrote on 2020-05-25, 21:15:
[...] […]
Show full quote

[...]

Sure. I'll upload the files that I created and tested the tool with myself.

I used the espeak speech synthesizer and ffmpeg in a recent Ubuntu Linux OS to generate and convert the WAV files as follows:

espeak "Your sound card works perfectly." --stdout | ffmpeg -i - -ar 44100 -ac 2 -f wav sndtest1.wav
espeak "Enjoying yourself?" --stdout | ffmpeg -i - -ar 44100 -ac 2 -f wav sndtest2.wav
espeak "It doesn't get any better than this!" --stdout | ffmpeg -i - -ar 44100 -ac 2 -f wav sndtest3.wav

Espeak apparently synthesizes the speech at 22kHz and I found no obvious way to have it render the resulting audio at 44.1kHz instead, so I converted it with ffmpeg instead. I'll also attach the results to this message.

Let me know if the result sounds more normal. (By the way, the originally generated audio is already quite fast.)

Good news:
With your .wav the two ICH boards behave perfectly. No sound without the /v, with the /v all the espeak glory you made here. So either the player is failing to do 22kHz correctly, or those old Mediavision .wavs are missing stuff. However the ICH code seems to be working fine 😀

These files are quite a bit longer, it also lets me answer your other question: on the ICH2, still no sound, however the system is busy for as long as if it was playing - so it probably is the volume thing.

As for installing Win98SE - have to see about finding time for that...

Edit: working on Win98SE now.

FWIW, the TR100 board has an AD1885 codec connected to the ICH2.The GA-6WMM8 board has an AD1881 connected to the ICH. Not sure about the SW400, will check when I next look at it.

Edit2: oh boy, forgot how much fun Win98SE could be, particularly on non-standard hardware. After installing Intel chipset drivers everything started conflicting with everything. Removing NIC and disabling USB in BIOS at least got me to the point of having a working desktop (in 16 colours, as the Rage 128 Pro drivers refuse to recognise the Rage 128 Pro installed). Turns out the regular AD1885 drivers also can't do anything with this board, so I need to find the Compaq specific driver somewhere... will do so sooner or later, but not tonight.

Reply 10 of 25, by digger

User metadata
Rank Member
Rank
Member

I appreciate the effort. I feel kind of guilty asking you to go tbrough those troubles of installing Win98SE again, especially on more uncooperative hardware.

Thanks foe the info on the specific codecs!

I think my next step is to have the player display the sub-device-ID (or whas it the device-sub-id) of the detected sound device, since I can cross-reference those with the device-specific quirks in the Linux and FreeBSD drivers for ICH southbridges and compatible chipsets.

I'll have more time to work on it the coming weekend.

In the meantime, everyone reading this are welcome to test the player on whatever hardware they have and share their findings here.

Good night for now!

Reply 11 of 25, by dionb

User metadata
Rank l33t
Rank
l33t
digger wrote on 2020-05-27, 00:12:

I appreciate the effort. I feel kind of guilty asking you to go tbrough those troubles of installing Win98SE again, especially on more uncooperative hardware.

No worries - actually I just received a new Tualatin CPU for this board and was running into limitations of not having a Win98SE box, so it was on my to-do list anyway. Have now found the original Compaq softpaq for the Presario 5000 system it came from (and a Dell OEM driver for the low-profile Rage128Pro that might work), will try them when I have time.

Thanks foe the info on the specific codecs! […]
Show full quote

Thanks foe the info on the specific codecs!

I think my next step is to have the player display the sub-device-ID (or whas it the device-sub-id) of the detected sound device, since I can cross-reference those with the device-specific quirks in the Linux and FreeBSD drivers for ICH southbridges and compatible chipsets.

I'll have more time to work on it the coming weekend.

In the meantime, everyone reading this are welcome to test the player on whatever hardware they have and share their findings here.

Good night for now!

What's the endgame here? Just a working .wav player, or are you actually contemplating trying to get SB-compatible DOS sound on AC'97 (which would be huge, of course)?

Reply 12 of 25, by digger

User metadata
Rank Member
Rank
Member
dionb wrote on 2020-05-27, 08:40:

What's the endgame here? Just a working .wav player, or are you actually contemplating trying to get SB-compatible DOS sound on AC'97 (which would be huge, of course)?

My goal is to write an open source VBE/AI driver for this family of audio devices. VBE/AI in an audio-specific extension of the VESA VBE specification. It was meant as a sound card API and hardware abstraction layer for DOS applications and games. Unfortunately, this extension to the VBE standard wasn't released until 1994, by the time which it was too late to gain any traction in the DOS game industry.

However, bridge drivers for both Miles Design AIL2 and DIGPAK were eventually released that would allow VBE/AI drivers to be used in games that used either of those driver models. And there are quite a few games out there that do.

Also VBE/AI, being an open industry standard, would be a nice thing to offer in FreeDOS as a relatively high-level and hardware-independent audio API.

VBE/AI drivers already exist for Sound Blaster and even the Disney Sound Source.

A later step could perhaps indeed be to also write a Sound Blaster emulator for ICH devices, or if possible even a Sound Blaster emulator for anything that has a VBE/AI driver.

If this proves successful, than I'd like to see VBE/AI drivers developed for Intel HDA and USB audio devices as well. If not by me, hopefully by others.

Open source sound drivers are currently actually an item on the FreeDOS wish/TODO list.

Reply 13 of 25, by dionb

User metadata
Rank l33t
Rank
l33t
digger wrote on 2020-05-27, 09:41:
My goal is to write an open source VBE/AI driver for this family of audio devices. VBE/AI in an audio-specific extension of the […]
Show full quote
dionb wrote on 2020-05-27, 08:40:

What's the endgame here? Just a working .wav player, or are you actually contemplating trying to get SB-compatible DOS sound on AC'97 (which would be huge, of course)?

My goal is to write an open source VBE/AI driver for this family of audio devices. VBE/AI in an audio-specific extension of the VESA VBE specification. It was meant as a sound card API and hardware abstraction layer for DOS applications and games. Unfortunately, this extension to the VBE standard wasn't released until 1994, by the time which it was too late to gain any traction in the DOS game industry.

However, bridge drivers for both Miles Design AIL2 and DIGPAK were eventually released that would allow VBE/AI drivers to be used in games that used either of those driver models. And there are quite a few games out there that do.

Also VBE/AI, being an open industry standard, would be a nice thing to offer in FreeDOS as a relatively high-level and hardware-independent audio API.

VBE/AI drivers already exist for Sound Blaster and even the Disney Sound Source.

A later step could perhaps indeed be to also write a Sound Blaster emulator for ICH devices, or if possible even a Sound Blaster emulator for anything that has a VBE/AI driver.

If this proves successful, than I'd like to see VBE/AI drivers developed for Intel HDA and USB audio devices as well. If not by me, hopefully by others.

Open source sound drivers are currently actually an item on the FreeDOS wish/TODO list.

Impressive! And all the more happy to help in whatever way I can 😀

Reply 14 of 25, by digger

User metadata
Rank Member
Rank
Member

Thanks! 🙂 Any help with this will be helpful, both with testing and development.

It's actually been a great opportunity for me to further explore my obsession with low-level software development, particularly in assembly and C. I don't have much experience with that, to be honest. It's been a fun learning curve. I my daily life I work with high-level languages such as Java, Kotlin, JavaScript, etc. Although that's all fun and challenging too, it's an interesting change of perspective to go closer to the metal again, as well as to enjoy the nostalgia of the MS-DOS gaming days and explore what could have been. 😊

By the way, here are FreeDOS pages mentioning the desire of the project maintainers to one day ship with audio drivers. The first one mentiones VBE/AI explicitly.

* http://wiki.freedos.org/wiki/index.php/ ... t_wishlist
* https://www.freedos.org/contribute/

Reply 15 of 25, by dionb

User metadata
Rank l33t
Rank
l33t

Ugh, this TR100 board really, really doesn't like Win98SE (or vice versa) - it keeps freezing on boot after I install the 'correct' audio drivers. Same symptoms as with the conflict with NIC and with USB when it was on. Looks like PnP is completely messed-up. Normally I'd just mess around with PnP OS setting in BIOS in that case, but I don't have that option here. Running out of time and energy to keep messing around with this install. I'll probably try WinME next, as that is what this system originally shipped with. That precludes exting to DOS for the "does Windows driver unmute" thing, but at least I should be able to give you that exact driver version.

Reply 16 of 25, by bregolin

User metadata
Rank Newbie
Rank
Newbie

This is awesome!
Just tested it on a 82801CA/CAM ICH3 and all audio files played perfectly. Keep it up! So looking forward to what this brings for DOS gaming on modern-ish computers 😀

IBM Aptiva 2162 - P55 166 MMX, 32MB, CS4237B + Wavetable, ATI Mach64 2MB / Win98SE
Custom PIII 750, 64MB, SB AWE64, Voodoo 3 3000 AGP / Win98SE
Sony Vaio z505 SuperSlim - PIII 550, 192MB, YMF744, NeoMagic 256AV+ / Win98SE

Reply 17 of 25, by digger

User metadata
Rank Member
Rank
Member
bregolin wrote on 2020-05-28, 21:05:

This is awesome!
Just tested it on a 82801CA/CAM ICH3 and all audio files played perfectly. Keep it up! So looking forward to what this brings for DOS gaming on modern-ish computers 😀

Excellent! Thank you for testing. ☺️

ICH3 is a revision that wasn't originally supported in the source code. I just added the device IDs of ICH3 through ICH7 to the detection whitelist in the source code, not knowing if that would be enough to make it work out of the box. Good to know that this was enough at least for the ICH3 on your motherboard to work. May I ask what motherboard or system this was?

By the way, if I'm reading the source code of the FreeBSD driver correctly, ICH4 will probably require a bit more initialization stuff to support.

Anyway, I'm going to try to enhance the application further to display the Subsystem ID and Subsystem Vendor ID of the detected ICHx AC'97 device. That way, we can determine in more detail which of the tested devices (and combinations of southbridges and codecs) work out of the box and which not. Also, when you send me the subsystem ID that will then appear on screen, I'll be able to cross-reference it with device-specific quirks in the FreeBSD and Linux drivers for those audio devices. And then I'll try to backport those.

Reply 18 of 25, by bregolin

User metadata
Rank Newbie
Rank
Newbie
digger wrote on 2020-05-30, 21:31:

ICH3 is a revision that wasn't originally supported in the source code. I just added the device IDs of ICH3 through ICH7 to the detection whitelist in the source code, not knowing if that would be enough to make it work out of the box. Good to know that this was enough at least for the ICH3 on your motherboard to work. May I ask what motherboard or system this was?

This is a Compaq Evo N1000v notebook . If you need more info I can dig it up and run some diagnostics

IBM Aptiva 2162 - P55 166 MMX, 32MB, CS4237B + Wavetable, ATI Mach64 2MB / Win98SE
Custom PIII 750, 64MB, SB AWE64, Voodoo 3 3000 AGP / Win98SE
Sony Vaio z505 SuperSlim - PIII 550, 192MB, YMF744, NeoMagic 256AV+ / Win98SE

Reply 19 of 25, by digger

User metadata
Rank Member
Rank
Member

Alright, @dionb, @bregolin and everyone else willing to help me test my progress with this,

I just improved the player to display some more detailed PCI info about the detected sound device, including the subsystem ID and subsystem device ID.

Could you please try it again with the version I'm attaching to this message, and share the entire display output with me, including the actual playback result (whether you heard any sound or not, with or without the /v option, and whatever other behaviour you might notice)?

You are encouraged to test this with as many different ICHx AC'97 devices as you want and can.

And again, if you prefer to build the EXE yourself, you can check out the code from https://github.com/volkertb/ich2player

The next step will be to enable some more (partially?) compatible devices other than the Intel ICH southbridges, including various revisions of the NVIDIA nForce chipsets.

Thanks again, everyone! 😊

Attachments

  • Filename
    player_0515423.zip
    File size
    1.77 KiB
    Downloads
    12 downloads
    File comment
    Build of Git revision 0515423 of https://github.com/volkertb/ich2player
    File license
    Public domain