VOGONS


First post, by NY00123

User metadata
Rank Member
Rank
Member

This thread is a place for reporting about examples of hypervisors, emulators, compatibility layers and similar programs, which support audio recording from a host input device (e.g., a microphone) using an emulated Sound Blaster. This also includes partial support, say if only early SB cards are emulated and just one DOS program is usable with a host input device.

Please limit yourselves only to working examples; Basically, any environment which can pass the data received from host mic input (or any other actual audio input device) to an emulated SB.

This is a follow-up to the following recent discovery of mine, emphasis on the words "Shortcomings in PCM/Wave Playback and Recording" from the VMware page:
VMware DOS sound improved.. now is finally possible to play FX + FM together! -> https://communities.vmware.com/docs/DOC-40539

I'm going to start with two DOS programs, and the levels of compatibility with one hypervisor and one compatibility layer.


------------
DOS programs
------------

CTHUGHA: A program which processes incoming sound and displays graphics synced to the sound. More details are given here: http://www.afn.org/~cthugha/archives.html

For a download, look for "cthug53.zip", which should come from around 1995-06-24 21:56:04 and have the size of 401430 bytes.
I've attached a backup, which is the ZIP file itself compressed again as a 7Z in order to preserve the file's timestamp (while also reducing the attached file's size a bit):

Filename
cthug53.zip.7z
File size
392.95 KiB
Downloads
No downloads
File comment
CTHUGHA 5.3, ZIP file double-compressed as a 7Z
File license
Fair use/fair dealing exception

After starting CTHUGHA and waiting for loading to complete, press on 'C' for configuration and select Mic as the input device. You may then try to control the recording level using the "Level" buttons. Press Esc to get back, and then try to use the microphone.

RS: A command-line utility powered by the Apogee Sound System, based on Simple sound player (PS.EXE) from James R. Dose. Records unsigned 8-bit mono sound to a RAW PCM formatted file. I actually came up with it for testing audio recording under VMware Player. Was admittedly never tested with vintage DOS hardware, so your mileage may vary. Archive with last binary and source is currently available at: https://ny.duke4.net/files.html; git repository link: https://gitlab.com/NY00123/audiolib-rs

This player requires DOS4GW.EXE or a compatible extender. Once it's ready, enter "RS" for usage instructions. Generally, though, "RS OUTFILE.RAW" should be sufficient.


------------------------------
Environments with SB emulation
------------------------------

VMware Workstation Player 15 (15.5.1 build-15018445) with FreeDOS:
- RS is working as expected while using the Sound Blaster as the card (should be the default).
- Under CTHUGHA's configuration screen, the received sound's volume seems to be correctly reported after it's set up as described above.

DOSEMU2 (Jan 12 2020 build) with fdpp (FreeDOS plus-plus):
- RS is not working as expected.
- CTHUGHA seems to work as under VMware, with one difference: In addition to processing the sound, the recorded input is redirected to the output (e.g., the speakers). The exact volume depends on the recording level set as described above, and it'll keep to work after after leaving CTHUGHA. I'm not sure if this is an instance of an original Sound Blaster feature (e.g., a mixer one) being emulated or not.

Reply 1 of 4, by superfury

User metadata
Rank l33t
Rank
l33t

UniPCemu supports recording from the first found (by SDL2, when it's from 2.0.4 and up if I remember correctly) recording device that the host has. It will of course pass through the samples at real-time speed(so recording realtime, sending to the sound blaster at emulated speed(as the Sound Blaster emulation does itself handle these samples). And of course, samples sent to DMA or CPU are slowed down as well to match emulated speed as well(so if it's at 20% realtime speed, it will send 0.2 seconds of recorded audio per second to the emulated sound blaster card). Said audio is of course buffered in the meantime(using standard-sized buffers, e.g. 2048 samples).

What's actually happening is that the audio routine records in realtime, then 'plays it back' to a stereo audio channel(itself being two signed integers) at the realtime sample rate at the speed of the emulated machine(so for each second emulated, one second of recorded audio is 'played back' on the two integer variables(the current samples)).

What the Sound Blaster itself does is very simple: simply sample those two integers are the rate it's recording at(during DMA-based recording) to 'resample' it in a simple way. The other method the sound blaster supports(the Direct DAC input method) uses the very same method, but allows the sampling to be done by software's own timing.
During either method, the single sample that's read by DMA transfer and Direct DAC is simply determined by the currently stored sample, which always ticks at the speed of the last set Sound Blaster sample rate(at a minimum of 1s/256=3906Hz). The last set sample rate by the DSP Set Time Constant command(command 0x40) is used for all further inputs after it's set(if set at all, where it defaults to like the constant is set like it's called with a parameter of 0, thus 3906Hz).

UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io
Older UniPCemu PC/Android/PSP releases

Reply 2 of 4, by Jo22

User metadata
Rank l33t
Rank
l33t

That's interesting. Does this record-playback-record thing work with communications software, too ?
If so, this would make it possible to use some old amateur radio software that requires 16-Bit/44KHz recording.. 😁

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 3 of 4, by superfury

User metadata
Rank l33t
Rank
l33t

It's only 8-bit, since it's emulating a Sound Blaster 1.0/1.5/2.0 only.

I don't know if 44kHz is supported by the original? It might be, but I could be wrong(setting the time constant accordingly).

Of course, the real recording rate is as high as the hardware supports(although it requests 44kHz from the SDL2 library) on the SDL2 side(and the generic sound module that's running in sync with the emulated hardware).

The sound blaster itself can(according to the time constant) go from 3906.25Hz(setting of 0) up to 1MHz(setting of 255) based on the time constant. So setting it to a constant value of 22(decimal) will make it record at just above 44.1kHz.

Atm, the hardware sample rate using the Direct DAC method uses whatever sample rate was last set by the Set time constant.
Edit: I've just modified it to use a sample rate of 1MHz when recording using the Direct ADC method(command 0x20 of the DSP). So it samples the hardware(which runs at up to 44.1kHz) at a rate of 1MHz. And sending the Direct ADC command just reads what was last put there(all is in sync with the emulated system).

UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io
Older UniPCemu PC/Android/PSP releases

Reply 4 of 4, by superfury

User metadata
Rank l33t
Rank
l33t

Hmmm... Just tried the new 1MHz setting on the recording itself(using the normal record.exe from the Sound Blaster 2.0 disks).

I notice that somehow the speed of recording is a bit elevated? So everything sound a little bit higher than it does a full speed? (it's running a 3MIPS Pentium CPU on a XT machine at 20% speed) Usually I use a normal 100% speed for testing it, though(or as close as a 8086 emulation can be).

Hmmm...
Edit: Still, even with changes to the Sound Blaster recording speed, it still sounds exactly the same? Weird?

UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io
Older UniPCemu PC/Android/PSP releases