OS/2, eCS & ArcaOS - Technical > Multimedia

PC Speaker output to sound card?

<< < (4/6) > >>

Lars:
It's very simple. If have have an exe MyApp.Exe, then do this:
exehdr /V MyApp.exe | find "imp"

It will list all the imports. If you find something like this:
REL OFF(32)  0014       imp DOSCALLS.286

then you know that this exe uses DosBeep.

You then run:
dllrname /N /Q MyApp.exe DOSCALLS=NEWCALLS

You then rerun:
exehdr /V MyApp.exe | find "imp"

Now it will show this:
REL OFF(32)  0014       imp NEWCALLS.286

and you will know that from now on, the new DosBeep Implementation will be called. It works the very same way to patch a DLL.

I have written this simple app, file bla.c:

#define INCL_BASE
#include <os2.h>

int main(int argc,char *argv[])
{
    DosBeep(1000,1000);
    return 0;
}

and build it with:
icc -Gm+ -Gd+ -Ge+ bla.c
dllrname /N /Q bla.exe DOSCALLS=NEWCALLS /* this does the interesting part */

When I now run bla.exe, I can hear the Beep via my Speakers driven by Uniaud or via the Speakers connected via Audio USB, whatever device I choose as the default WAV device (the default WAV device will be used to play the sound).

By the way: use my USBAUDIO.ZIP package to have everything to work with USB audio. And it also comes with a DLL that extends the Multimedia Setup Object to allow you to simply switch the default WAV device with a mouse click. Of course that works across the board, not only for the USB audio device but also for the UNIAUD device.

Lars

Lars:
Ok, I now tested rhythm.exe.

Yes, there is a problem. The app issues DosBeep with a duration of only 1 ms in length (that's the minimum duration) and this happens at a potentially very high repetition rate.
Looks like the MMPM sound system cannot handle this when a play list is used (as I do, because it is easy to use in this case). The "play" call never finishes but fortunately Ctrl-C works ...

I might need to switch to DART to keep up with this speed. I'll give that a try. In the meantime, try to run rhythm.exe with a slow beats per minute rate to test if it works in principle.

EDIT: it does not work even with a slow rate. What I can see is that this SW runs a high prio thread, potentially for sound output. That makes it likely that DART will have to be used in order to cope with the high generation rate that is necessary.

Lars

Lars:
I also looked at os2snd2. Yes, it does not use DosBeep. Instead it uses an incredibly bad hack and directly tries to program the PIT. That is what DosBeep would do anyway. Because DosBeep is not used, it cannot be replaced. It is not possible to patch this SW.

OS4User:

--- Quote from: Lars on April 16, 2020, 08:23:28 pm ---It will list all the imports. If you find something like this:
REL OFF(32)  0014       imp DOSCALLS.286

--- End quote ---

Hi Lars

do not forget  Dos16Beep   (DOSCALLS.50)

Lars:

--- Quote from: OS4User on April 17, 2020, 10:12:07 am ---
--- Quote from: Lars on April 16, 2020, 08:23:28 pm ---It will list all the imports. If you find something like this:
REL OFF(32)  0014       imp DOSCALLS.286

--- End quote ---

Hi Lars

do not forget  Dos16Beep   (DOSCALLS.50)

--- End quote ---

I was too lazy to think about issues like thunking (and even more involved: changing the process type to PM and using 32-bit PM to show a message box) but I guess you are right. I'll just need to hack together a good old 16-bit app to test if it properly works.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version