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).

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.. 😁

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).

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?

NY00123 wrote on 2020-01-18, 21:13:

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.

You need to run them in a reverse order.
After CTHUGA sets the volume levels and inputs,
you can use RS (which doesn't do these
mandatory things on its own, so its broken).