OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Programming => Topic started by: Jochen Schäfer on May 23, 2023, 10:00:51 am

Title: Strange behaviour in SDL2
Post by: Jochen Schäfer on May 23, 2023, 10:00:51 am
So, I'm working on PrBoom again and I noticed a strange behaviour:
Sometimes when I start the program, there is sound. Sometimes, when I use the volume program, the sound become audible, even if I press the plus sign only once, so that the volume is going down or up one point. The direction doesn't matter.
I'm running a T480 with the newest ArcaNoae Uniaud (I also tried Paul's newer version, no change there). SDL2 is locally build copy of the most recent repo.

The question is, whether somebody knows this phenomenom and point me to some solution.
Title: Re: Strange behaviour in SDL2
Post by: Martin Iturbide on May 23, 2023, 02:55:51 pm
Hi Jochen

I'm using this version of PRBoom+
  https://github.com/josch1710/prboom-plus/releases/download/v2.6um-alpha1/prboom-plus-2.6um-alpha1.zip
To run PRBoom+ it is needed:
  yum install flac fluidsynth SDL2_image

I also experience a problem with the sound. The "action sounds" of the menu and the shots of selecting the menu items sounds fine on the startup, but later when I start up the game the sound is gone. If I close the game and start it over, sometimes I get the menu sound back and sometime don't. 
I made this quick video: https://youtu.be/ssjtBMSdwis

I don't see the SDL Mixer on the exe, which is the audio stuff for SDL. Maybe is some issue with flac.
I haven't added MIDI support to my system to see if the background music works.

Regards
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on May 24, 2023, 10:57:51 am
Hi Martin,

thanks for the feedback. At least, I'm not alone.
My working copy has SDL Mixer linked, that doesn't seem to be the issue.
My current hunch is, that something in SDL2 in conjunction with PrBoom goes wrong.
Title: Re: Strange behaviour in SDL2
Post by: Martin Iturbide on May 24, 2023, 02:19:46 pm
Hi Jochen

You may already know about this, we have two distros of SDL and SDL2.
One on Netlabs rpm (I guess from BitWise Works) and the other from Digi (http://os2.snc.ru/product-SDL.html)

Maybe you would like to test a release with Digi's SDL and see if there is any improvement.  Is that what you did to don't have the issue?

Regards
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on May 24, 2023, 04:16:18 pm
Hi Jochen

You may already know about this, we have two distros of SDL and SDL2.
One on Netlabs rpm (I guess from BitWise Works) and the other from Digi (http://os2.snc.ru/product-SDL.html)

Maybe you would like to test a release with Digi's SDL and see if there is any improvement.  Is that what you did to don't have the issue?

Regards
No, I didn't test Digi's SDL.
Also I don't get what you mean by your last sentence.
 
Title: Re: Strange behaviour in SDL2
Post by: Martin Iturbide on May 24, 2023, 04:40:49 pm
Hi Jochen,

Sorry my last sentence was confusing because  I didn't understand this:
My working copy has SDL Mixer linked, that doesn't seem to be the issue.
I got confused there, please ignore my last sentence.

I guess that it would be good to try to use Digi's SDL2 and if the problem gets solve like magic, it most be some issue with the Netlabs RPM SDL2.

Just in case I have Digi's SDL2 source code copied here:
- https://github.com/OS2World/LIB-SDL2/tree/master/packages
- Original source: ftp://digi.os2.snc.ru/pub/SDL

while Netlabs RPM Bitwise Source code is here:
- https://github.com/bitwiseworks/SDL2-os2
- https://github.com/bitwiseworks/SDL2_mixer-os2
- https://github.com/bitwiseworks/SDL2_image-os2
... and others

Regards
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on May 25, 2023, 09:18:40 am
Hi Martin.

Thanks for the hints, but I know them, because I made some fixes on them and use them for debugging.
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on June 20, 2023, 09:55:06 am
Upon further research, I noticed that the multimedia system, just doesn't do anything with the supplied data. The callback, when the buffer is played, never gets called, until I use the master volume application. Then suddenly the buffer is played and everything is fine. Any ideas why?

Another issue, which bugs me, is that OS/2 reports two sound card while onyl one is in my T480. One of the SDL2 test programs tries to open all reported devices, but the second one is already locked.
Any ideas why?
Title: Re: Strange behaviour in SDL2
Post by: Lars on June 22, 2023, 07:10:32 am
Can you use an USB sound device (with the corresponding drivers of course) and see if that makes a difference? If yes, it must be the UNIAUD drivers. Or AUDIOIF.DLL (that provides the interface between MMPM and the audio drivers and that I replaced for the USB audio drivers with my own version).
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on June 22, 2023, 02:55:23 pm
I will try that on sunday.
Title: Re: Strange behaviour in SDL2
Post by: Martin Iturbide on June 25, 2023, 03:11:08 pm
Hi Jochen, Lars

I recently tried PRBoom+ on my Thinkpad L420 with the USB Audio headset (HP Gaming Headset H320GS (https://www.os2world.com/wiki/index.php/HP_Gaming_Headset_H320GS))

I'm using this version of PRBoom+
  https://github.com/josch1710/prboom-plus/releases/download/v2.6um-alpha1/prboom-plus-2.6um-alpha1.zip
To run PRBoom+ it is needed:
  yum install flac fluidsynth SDL2_image

I used Lars' USB Audio drivers (Included in usbdrv (https://hobbes.nmsu.edu/download/pub/os2/system/drivers/usb/usbdrv249.zip)).

I have some kind of different results:
- Sound works better than before, but eventually I loose the sound completely (less than one minute playing or watching the demo), it comes and go while I play. If I alt+tab to the desktop, the sound gets back.
- I exited and reenter the program like three times, and sound kept working, not like before that I got no sound on the second or third try.
- The volume master control worked, I alt+tab to the desktop, reduced the volume and returned to PRBoom+ with the adjusted volume.
- The volume controls inside PRBoom+ also worked to change the music or SFX
- It even works with the MIDI music, because I have installed Ksoftseq (https://www.os2world.com/wiki/index.php/Enabling_MIDI_Support_on_MMOS2_with_Ksoftseq) some time ago.

I'm not sure if the sound issue is now caused by the MIDI support or my hardware. But on the ArcaOS desktop I have run without interruptions 2 minutes MIDI file (with the USB Headset) without any issues.
But sound is working better with the USB headset than with Uniaud on my case.

It would be interesting if someone else can test PRBoom+ on their machine, specify if using UniAud or USB Audio, just let it run for two to five minutes running the self running demo and check if the sound remains steady for that time.

Regards



Title: Re: Strange behaviour in SDL2
Post by: Lars on June 27, 2023, 09:22:07 am
As a test I now installed ksoftseq (and all of its prerequisites of course).

For me, ksoftseq does not work reliably. Some MIDI files just won't play but the files are not the problem because they play fine with the timidity.exe and kmidi.exe and kmidimmio.exe (the two latter from the kmididec package) command line players.

What I experience is a much delayed playing of the file because apparently, the .SF2 file is loaded every single time when a MIDI file is selected for playing (and unloaded afterwards). What I also observe is a complete system hang when I double click a MIDI file to play every now and then.
I suspect the problem lies in ksoftseq MCD implementation. I have added two issues to the ksoftseq Github repo.

I have not tried PRBoom+ yet.
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on June 27, 2023, 09:48:36 am
Yesterday, I got around to testing with a USB headset and the following are my observations:
I really don't know whether it's any drivers fault, or whether PrBoom does things, it will get away with on other systems.
Title: Re: Strange behaviour in SDL2
Post by: Wim Brul on June 27, 2023, 06:12:42 pm
I did some tests on my Dell Latitude e6500 laptop with ArcaOS 5.0 and Lars' USB 10.249 drivers installed.

1) USBAUDIO.SYS selected as default audio device. Every time I start PrBoom I get sound and PrBoom keeps running with sound. Its SfxVolume control works. Its Music Volume has no effect. Perhaps because I have no MIDI support installed. With rocksndiamonds there is always sound.

2) USBAUD2.SYS selected as default audio device. Every time I start PrBoom I rarely get sound and PrBoom keeps running that way. Once I use its SfxVolume control then most of the time only the next invokation of PrBoom produces sound. With rocksndiamonds there is never sound.

Once USBAUD2.SYS does not get an audio buffer in time it stops sending audio to the device.
This is a flaw in USBAUD2.SYS. I have prepared a fix for that.
Title: Re: Strange behaviour in SDL2
Post by: Dave Yeo on June 28, 2023, 07:38:09 am
Testing here, using UniAud 3.1.4 from Arca Noae, sound usually works, occasionally it doesn't and I need to touch the master volume control, adjust volume or mute/unmute then it works fine. Haven't got the midi to work yet, even after following Martin's procedure to get midi working on the desktop, always get "Error loading song: Couldn't open /etc/timidity/freepats.cfg" guess I haven't set it up correctly.
As far as I can see, only one sound card is found, which is correct as I do have only one. Jochen, are you sure you don't have 2 sound cards, pci.exe will show if there are two and there often are. One regular and one for HDMI, often on the graphics card, which I guess is built in to your laptop.
My /etc/timidity/freepats.cfg
Code: [Select]
dir w:/mmos2
source ksoftseq.sf2
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on June 28, 2023, 07:07:48 pm
Definitely, only one internal audio device. And, as I said before, with a USB headset, I get the same doubling, with the seocnd device being locked immediately.
Title: Re: Strange behaviour in SDL2
Post by: Dave Yeo on June 29, 2023, 01:41:34 am
Definitely, only one internal audio device. And, as I said before, with a USB headset, I get the same doubling, with the seocnd device being locked immediately.

Was the 2nd device visible in the output from prboom-plus or only on your test app? If only on your test app, could you post it?
Title: Re: Strange behaviour in SDL2
Post by: Lars on June 29, 2023, 04:32:21 pm
Yesterday, I got around to testing with a USB headset and the following are my observations:
  • SDL detects the audio devices by sending MCI_SYSINFO_QUANTITY with type set to MCI_DEVTYPE_AUDIO_AMPMIX.
    This only detects the selected default audio and it always gets two devices. Since the second is always locked, when the first is used, I suspect, the system returns one device for output and one for input. I already tried to get the device capabilities, but failed.
    I also don't whether the detection of only the default device is the expected behaviour.
  • Starting PrBoom with the USB headset plugged in, the sound is not starting sometimes. But the trick to change the master volume doesn't work here. Also, I also see Martin's observation that, when the sound starts, it will run (with occasional hickups) and not cut out, like the builtin sound card.
I really don't know whether it's any drivers fault, or whether PrBoom does things, it will get away with on other systems.

I works differently (from my experience from the past).
MCI_SYSINFO_QUANTITY, asking for MCI_DEVTYPE_AUDIO_AMPMIX will return to you as many devices as you have sound drivers installed (simplified way of saying). That's because each audio driver installation will install one MCI_DEVTYPE_AUDIO_WAVEFORM_AUDIO device (and/or potentially a MCI_DEVTYPE_SEQUENCER for MIDI) and also one MCI_DEVTYPE_AUDIO_AMPMIX device (the latter was added late in Warp 3 in order to support DART and new mixing functionality and you have to have such a device in order to play sound at all).
Therefore if you install both USB audio drivers (USBAUDIO.SYS and USBAUD2.SYS) you will be reported back two MCI_DEVTYPE_AUDIO_AMPMIX devices. If you additionally installed UNIAUD, you'd get reported three MCI_DEVTYPE_AUDIO_AMPMIX devices. You cannot tell from that response what is the default ampmix (waveform audio) device.

If you want to identify the default audio device (which is equivalent to identifiying the default ampmix device), then you will need to use MCI_SYSINFO_ITEM / MCI_SYSINFO_QUERY_DEFAULT and specify in the MCI_SYSINFO_DEFAULTDEVICE usDeviceType = MCI_DEVTYPE_AUDIO_AMPMIX.

Please note that the default ampmix (and wave audio) device would need to be set in MMPM2.INI which either happens "by hand" or better by either the selection utility that comes with the USBAUDIO installation (integrated into the Multimedia Object, look there) or by the automatic default audio device selection tool that comes with ArcaOS.
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on June 29, 2023, 06:35:17 pm
I works differently (from my experience from the past).
MCI_SYSINFO_QUANTITY, asking for MCI_DEVTYPE_AUDIO_AMPMIX will return to you as many devices as you have sound drivers installed (simplified way of saying). That's because each audio driver installation will install one MCI_DEVTYPE_AUDIO_WAVEFORM_AUDIO device (and/or potentially a MCI_DEVTYPE_SEQUENCER for MIDI) and also one MCI_DEVTYPE_AUDIO_AMPMIX device (the latter was added late in Warp 3 in order to support DART and new mixing functionality and you have to have such a device in order to play sound at all).
Therefore if you install both USB audio drivers (USBAUDIO.SYS and USBAUD2.SYS) you will be reported back two MCI_DEVTYPE_AUDIO_AMPMIX devices. If you additionally installed UNIAUD, you'd get reported three MCI_DEVTYPE_AUDIO_AMPMIX devices. You cannot tell from that response what is the default ampmix (waveform audio) device.

If you want to identify the default audio device (which is equivalent to identifiying the default ampmix device), then you will need to use MCI_SYSINFO_ITEM / MCI_SYSINFO_QUERY_DEFAULT and specify in the MCI_SYSINFO_DEFAULTDEVICE usDeviceType = MCI_DEVTYPE_AUDIO_AMPMIX.

Please note that the default ampmix (and wave audio) device would need to be set in MMPM2.INI which either happens "by hand" or better by either the selection utility that comes with the USBAUDIO installation (integrated into the Multimedia Object, look there) or by the automatic default audio device selection tool that comes with ArcaOS.
SDL2 correctly wants to enumerate all known devices. The weird thing is, that it always shown two devices with the same name, even when UNIAUD is installed and the USB headset is plugged in. I switched the default setting on the Multimedia Object, but I don't seem to recall the automatic selection tool on ArcaOS, you mentioned. Where is that located?
I'm pretty positive, that I only have usbaudio.sys in config.sys, but I would have verify it, if I have access to my machine again.
Title: Re: Strange behaviour in SDL2
Post by: Lars on June 30, 2023, 07:05:44 am
Maybe you can point me to the SDL code, or I could write some sample code as obviously, something is going wrong. I have never seen what you are stating.
It would also be helpful if you posted your MMPM2.INI file (in the MMOS2 subdirectory. It's a simple text file).
Title: Re: Strange behaviour in SDL2
Post by: Lars on June 30, 2023, 07:21:11 am
I already found one error in the SDL device enumeration code.
The device index is 1-based and not 0-based:

Code: [Select]
ulDevicesNum = atol( stMCISysInfo.pszReturn );

  for( stSysInfoParams.ulNumber = 0; stSysInfoParams.ulNumber < ulDevicesNum; /* should be: ulNumber = 1; ulNumber <= ulDevicesNum */
       stSysInfoParams.ulNumber++ )
  {
    // Get device install name.
    stSysInfoParams.pszReturn    = &acBuf;
    stSysInfoParams.ulRetSize    = sizeof( acBuf );
    stSysInfoParams.usDeviceType = MCI_DEVTYPE_AUDIO_AMPMIX;
    ulRC = mciSendCommand( 0, MCI_SYSINFO, MCI_WAIT | MCI_SYSINFO_INSTALLNAME,
                           &stSysInfoParams, 0 );
    if ( ulRC != NO_ERROR )
    {
      debug( "MCI_SYSINFO, MCI_SYSINFO_INSTALLNAME - failed, rc = 0x%X", ulRC );
      continue;
    }
Title: Re: Strange behaviour in SDL2
Post by: Lars on June 30, 2023, 07:27:53 am
Here is some code. Note that I am not only querying/setting the default ampmix device but at the same time, also the default audio device. Strictly speaking that is not necessary but a sensible descriptive name is only given to the audio device (during installation) and not the ampmix device. I am going the extra mile to query the ampmix device from the audio device via the audio device's first connector. Again, that is not strictly necessary.

Code: [Select]
MRESULT EXPENTRY SettingsPageProc(HWND hwnd,ULONG msg,MPARAM mp1,MPARAM mp2) {
   CHAR retBuff[256];
   CHAR ListBoxString[MAX_DEVICE_NAME+MAX_ALIAS_NAME+16];
   MCI_SYSINFO_PARMS sysParms;
   MCI_SYSINFO_DEFAULTDEVICE defDevice;
   MCI_SYSINFO_QUERY_NAME    devName;
   MCI_SYSINFO_CONPARAMS     wavConnectors;
   ULONG rc;

   switch(msg)
   {
      case WM_INITDLG:
      {
         ULONG numDevices=0;
         CHAR *endPtr = NULL;
         PDEVINFO pDevInfo = NULL;
         ULONG i=0;
         HWND hwndListBox = WinWindowFromID(hwnd,ID_LISTBOX);

         memset(retBuff,0,sizeof(retBuff));
         memset(&sysParms,0,sizeof(sysParms));
         sysParms.usDeviceType = MCI_DEVTYPE_WAVEFORM_AUDIO;
         sysParms.pszReturn    = retBuff;
         sysParms.ulRetSize    = sizeof(retBuff)-1;
         rc = mciSendCommand(0,MCI_SYSINFO, MCI_SYSINFO_QUANTITY | MCI_WAIT,&sysParms,0);

         numDevices = strtoul(sysParms.pszReturn,&endPtr,10);
     
         pDevInfo = (PDEVINFO)calloc(numDevices,sizeof(DEVINFO));
         WinSetWindowPtr(hwnd,QWL_USER,pDevInfo);
         if (!pDevInfo) {
            return MRFROMLONG(FALSE);
         } /* endif */
         for (i=0;i<numDevices;i++) {
            /*device numbers are 1-based (1: first device) */
            memset(&sysParms,0,sizeof(sysParms));
            sysParms.usDeviceType = MCI_DEVTYPE_WAVEFORM_AUDIO;
            sysParms.ulNumber     = i+1;
            sysParms.pszReturn    = retBuff;
            sysParms.ulRetSize    = sizeof(retBuff)-1;
            rc = mciSendCommand(0,MCI_SYSINFO, MCI_SYSINFO_INSTALLNAME | MCI_WAIT,&sysParms,0);
           
            memset(&sysParms,0,sizeof(&sysParms));
            sysParms.pszReturn    = retBuff;
            sysParms.ulRetSize    = sizeof(retBuff)-1;
            sysParms.ulItem       = MCI_SYSINFO_QUERY_NAMES;
            sysParms.pSysInfoParm = &devName;
            memset(&devName,0,sizeof(devName));
            strcpy(devName.szInstallName,sysParms.pszReturn);
            rc = mciSendCommand(0,MCI_SYSINFO,MCI_SYSINFO_ITEM | MCI_WAIT,&sysParms,0);

            strcpy(pDevInfo[i].szWaveInstallName,devName.szInstallName);
            strcpy(pDevInfo[i].szWaveAliasName,devName.szAliasName);

            memset(&sysParms,0,sizeof(sysParms));
            sysParms.pszReturn    = retBuff;
            sysParms.ulRetSize    = sizeof(retBuff)-1;
            sysParms.ulItem       = MCI_SYSINFO_QUERY_CONNECTORS;
            sysParms.pSysInfoParm = &wavConnectors;
            memset(&wavConnectors,0,sizeof(wavConnectors));
            strcpy(wavConnectors.szInstallName,sysParms.pszReturn);
            rc = mciSendCommand(0,MCI_SYSINFO,MCI_SYSINFO_ITEM | MCI_WAIT,&sysParms,0);

            if (MCI_WAVE_STREAM_CONNECTOR == wavConnectors.ConnectorList[0].usConnectType) {
               memset(&sysParms,0,sizeof(sysParms));
               sysParms.pszReturn    = retBuff;
               sysParms.ulRetSize    = sizeof(retBuff)-1;
               sysParms.ulItem       = MCI_SYSINFO_QUERY_NAMES;
               sysParms.pSysInfoParm = &devName;
               memset(&devName,0,sizeof(devName));
               strcpy(devName.szInstallName,wavConnectors.ConnectorList[0].szToInstallName);
               rc = mciSendCommand(0,MCI_SYSINFO,MCI_SYSINFO_ITEM | MCI_WAIT,&sysParms,0);

               strcpy(pDevInfo[i].szAmpInstallName,devName.szInstallName);
               strcpy(pDevInfo[i].szAmpAliasName,devName.szAliasName);
            } /* endif */
            sprintf(ListBoxString,"%s (%s)",pDevInfo[i].szWaveAliasName,pDevInfo[i].szAmpAliasName);
            WinSendMsg(hwndListBox,LM_INSERTITEM,MPFROMSHORT(i),MPFROMP(ListBoxString));
            WinSendMsg(hwndListBox,LM_SETITEMHANDLE,MPFROMSHORT(i),MPFROMLONG((ULONG)(pDevInfo+i)));

            memset(&sysParms,0,sizeof(sysParms));
            sysParms.pszReturn     = retBuff;
            sysParms.ulRetSize     = sizeof(retBuff)-1;
            sysParms.ulItem        = MCI_SYSINFO_QUERY_DEFAULT;
            sysParms.pSysInfoParm  = &defDevice;
            memset(&defDevice,0,sizeof(defDevice));
            defDevice.usDeviceType = MCI_DEVTYPE_WAVEFORM_AUDIO;
            rc = mciSendCommand(0,MCI_SYSINFO,MCI_SYSINFO_ITEM | MCI_WAIT,&sysParms,0);

            if (0 == strcmp(defDevice.szInstallName,pDevInfo[i].szWaveInstallName)) {
               WinSendMsg(hwndListBox,LM_SELECTITEM,MPFROMSHORT(i),MPFROMSHORT(TRUE));
            }
         } /* endfor */
         return MRFROMLONG(TRUE);
      }
      break;

      case WM_CONTROL:
      {
         if (LN_ENTER == SHORT2FROMMP(mp1)) {
            HWND hwndListBox = HWNDFROMMP(mp2);
            SHORT i = SHORT1FROMMR(WinSendMsg(hwndListBox,LM_QUERYSELECTION,MPFROMSHORT(0),MPVOID));
            PDEVINFO pDevInfo = (PDEVINFO)PVOIDFROMMR(WinSendMsg(hwndListBox,LM_QUERYITEMHANDLE,MPFROMSHORT(i),MPVOID));
            if (!pDevInfo) {
               return MRFROMLONG(0);
            } /* endif */
           
            memset(&sysParms,0,sizeof(sysParms));
            sysParms.pszReturn     = retBuff;
            sysParms.ulRetSize     = sizeof(retBuff)-1;
            sysParms.ulItem        = MCI_SYSINFO_SET_DEFAULT;
            sysParms.pSysInfoParm  = &defDevice;
            strcpy(defDevice.szInstallName,pDevInfo->szWaveInstallName);
            defDevice.usDeviceType = MCI_DEVTYPE_WAVEFORM_AUDIO;
            rc = mciSendCommand(0,MCI_SYSINFO,MCI_SYSINFO_ITEM | MCI_WAIT,&sysParms,0);
   
            memset(&sysParms,0,sizeof(sysParms));
            sysParms.pszReturn     = retBuff;
            sysParms.ulRetSize     = sizeof(retBuff)-1;
            sysParms.ulItem        = MCI_SYSINFO_SET_DEFAULT;
            sysParms.pSysInfoParm  = &defDevice;
            strcpy(defDevice.szInstallName,pDevInfo->szAmpInstallName);
            defDevice.usDeviceType = MCI_DEVTYPE_AUDIO_AMPMIX;
            rc = mciSendCommand(0,MCI_SYSINFO,MCI_SYSINFO_ITEM | MCI_WAIT,&sysParms,0);
         }
         return MRFROMLONG(0);
      }
      break;
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on June 30, 2023, 10:59:47 am
@Lars: Now we are getting somewhere. With the index beginning with 1, I'm getting two different driver names.
But now, I get a "Hardware Error" return from MCI_OPEN. If I understand the documentation correctly, one opens a device with its driver name, not with the index from the device enumeration.
Is my understanding correct?
Title: Re: Strange behaviour in SDL2
Post by: Lars on June 30, 2023, 11:43:12 am
Well, it is convoluted to say the least.


Note for all the mechanisms: if you have not specified a default device (in MMPM2.INI) then the "first in the list" will be picked. Potentially not what you want. You can get out of the misery by using the open mechanism via device type as that allows you to qualify a specific device (once you have built yourself a list of what devices exist).

So, you have quite some options. I'll look around at home and see if I can provide some sample code.
But you should make DART vs. non-DART the first decision. Today, for timing critical stuff, apps usually choose DART (or something that builds on top of that). But if you use DART, you will have to know the exact format the data is in (num channels, sample rate, bit depth) because you cannot make use of the autodetection features of MMPM (DART kind of bypasses parts of MMPM).
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on June 30, 2023, 12:45:38 pm
Hi Lars.

It uses DART. The code, I'm referencing, is in https://github.com/josch1710/SDL2-os2/blob/master/src/audio/os2/SDL_os2audio.c (https://github.com/josch1710/SDL2-os2/blob/master/src/audio/os2/SDL_os2audio.c).
Title: Re: Strange behaviour in SDL2
Post by: Lars on June 30, 2023, 01:48:47 pm
The code is under the wrong assumption that you could pass a handle to MCI_OPEN.
The opposite is true: MCI_OPEN returns a handle that you have to use on all subsequent calls.
You will need to slightly change the design.
Ignore the handle and add a usDeviceId to the hidden/private structure and keep using that.
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on June 30, 2023, 02:18:13 pm
Actually, the code uses the returned device id (if this is what you meant).
My question would be then, how to open the selected card in MCI_OPEN? What identifier is needed to say open the USB audio card instead of the internal card?
Title: Re: Strange behaviour in SDL2
Post by: Lars on June 30, 2023, 03:21:59 pm
Also, what you would need to do is build a list of devices in the SDL_DetectDevices function.
Then, the one-based device number can be the handle (again, one-based) that you use as the instance number in the MCI_OPEN call. That would allow to select between different devices.
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on June 30, 2023, 05:48:35 pm
Also, what you would need to do is build a list of devices in the SDL_DetectDevices function.
Then, the one-based device number can be the handle (again, one-based) that you use as the instance number in the MCI_OPEN call. That would allow to select between different devices.
Would that one-based index also go into usDeviceID for the MCI_OPEN message or would that go elsewhere? The documentation only states usDeviceID is a return value for MCI_OPEN.
Title: Re: Strange behaviour in SDL2
Post by: Lars on June 30, 2023, 10:59:57 pm
I will need to reread the docs. We'll continue on Slack.
Title: Re: Strange behaviour in SDL2
Post by: Paul Smedley on July 01, 2023, 07:44:30 am
I will need to reread the docs. We'll continue on Slack.
Just what we need, another forum for OS/2 users to splinter the user group...
Title: Re: Strange behaviour in SDL2
Post by: Dave Yeo on July 01, 2023, 08:08:56 am
Yes, 'tis an interesting thread
Title: Re: Strange behaviour in SDL2
Post by: Lars on July 01, 2023, 03:39:55 pm
I was not aware that the details may be interesting to the end user. It was just to not clutter this forum with endless code exchange and to speed up work.
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on July 03, 2023, 09:41:05 am
I will need to reread the docs. We'll continue on Slack.
Just what we need, another forum for OS/2 users to splinter the user group...
Come on. Nobody wants to splinter the community. We are just working on a solution there.
Title: Re: Strange behaviour in SDL2
Post by: Paul Smedley on July 03, 2023, 11:02:45 am
I will need to reread the docs. We'll continue on Slack.
Just what we need, another forum for OS/2 users to splinter the user group...
Come on. Nobody wants to splinter the community. We are just working on a solution there.
Note.. my comment wasn't specifically directed at you or Lars. The point was more that there are few enough OS/2 users left... I had no idea there was a Slack community that's OS/2 related - and I have no idea how to locate it. Splintering discussion across ANOTHER site just seems wrong. This site is already so quiet. For me, I'm interested in following the discussion, as I have an interest in implementing OS/2 sound support in qtmultimedia - see https://github.com/psmedley/qt6-multimedia-os2/issues/1
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on July 03, 2023, 11:38:44 am
Sure, there is no community as such on Slack.
We will absolutely communicate our solution to this forum, when we have a definite answer.
We are still experimenting at the moment.
Title: Re: Strange behaviour in SDL2
Post by: Lars on July 13, 2023, 08:41:41 am
short update: we have fixed an error in the SDL2 device detection, we have added detection of capture (recording) capable devices, we have implemented capturing/recording support. We still need to test this stuff.
Title: Re: Strange behaviour in SDL2
Post by: Paul Smedley on July 13, 2023, 11:12:33 am
Great news, hoping some of the code can be used for https://github.com/psmedley/qt6-multimedia-os2/issues/1
Title: Re: Strange behaviour in SDL2
Post by: Lars on July 13, 2023, 03:45:15 pm
Great news, hoping some of the code can be used for https://github.com/psmedley/qt6-multimedia-os2/issues/1

I briefly looked at the Qt stuff but got carried away by the C++ stuff (Qt specifics ? "emit" ...). I do not get where the OS specific nifty details have to go.
SDL2 uses the MMPM API directly, Chromium uses libkai (which I guess is a good choice).
Title: Re: Strange behaviour in SDL2
Post by: Paul Smedley on July 13, 2023, 11:14:35 pm
Hi Lars,

The subbed code is at https://github.com/psmedley/qt6-multimedia-os2/tree/os2audio/src/multimedia/platform/os2

I also struggle with c++ :)

Cheers,

Paul
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on July 14, 2023, 04:57:42 pm
I always find it helpful to look at what the WinMM code is doing.
Paul, do we have build instructions for Qt6?
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on July 14, 2023, 05:12:07 pm
Oh, And I found this: https://archive.org/details/developing-multimedia-applications-under-os-2/page/n9/mode/2up?ref=ol (https://archive.org/details/developing-multimedia-applications-under-os-2/page/n9/mode/2up?ref=ol)
Title: Re: Strange behaviour in SDL2
Post by: Paul Smedley on July 15, 2023, 12:08:36 am
Paul, do we have build instructions for Qt6?

Rough instructions
- install dependencies per Qt5
- clone qt6-base - git clone https://github.com/psmedley/qt6-base-os2.git
- checkout 6.3.x branch - git checkout 6.3.x
- mkdir build
- cd build
- configure with something like:
Code: [Select]
set LIBS=-lpthread -lcx
set BEGINLIBPATH=u:\dev\qt6-base-os2-6.3.x\build\lib
dash ../configure -prefix /qt6 -no-opengl -release -system-sqlite -openssl-linked -no-pch -no-avx -- -DQT_BUILD_EXAMPLES=ON -DQT_BUILD_TESTS=OFF 2>&1 | tee configure.log
- build with cmake --build .
- install with cmake --install .
- clone qt6-multimedia - git clone https://github.com/psmedley/qt6-multimedia-os2.git
- checkout os2sound branch - git checkout os2sound
- mkdir build
- cd build
- configure with something like:
Code: [Select]
dash /qt6/bin/qt-configure-module .. 2>&1 | tee configure.log- build with cmake --build .
- install with cmake --install .

The above should work - but it's kinda from memory....

Title: Re: Strange behaviour in SDL2
Post by: Dave Yeo on July 15, 2023, 01:40:22 am
I'll note it never worked for me. I could build Qt5. Takes a lot of memory, VIRTUALADDRESSLIMIT=3072 and with 3.2 GB's of visible memory here, there was swapping, so make sure you have a swapfile, weird popups about no memory and the need to reboot the odd time to recapture memory, fragmentation I assumed. Took almost a day here as well, being careful not to run things like browsers.
Title: Re: Strange behaviour in SDL2
Post by: Paul Smedley on July 15, 2023, 09:38:57 am
Hey Dave - I thought you could build qtbase - it was just the webengine you had issues with? webengine definitely runs out of memory - and built has to be restarted with -j1 to limit ninja to one job for a few build files...
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on July 15, 2023, 10:13:18 am
Paul, do we have build instructions for Qt6?

Rough instructions
- install dependencies per Qt5
- clone qt6-base - git clone https://github.com/psmedley/qt6-base-os2.git
- checkout 6.3.x branch - git checkout 6.3.x
- mkdir build
- cd build
- configure with something like:
Code: [Select]
set LIBS=-lpthread -lcx
set BEGINLIBPATH=u:\dev\qt6-base-os2-6.3.x\build\lib
dash ../configure -prefix /qt6 -no-opengl -release -system-sqlite -openssl-linked -no-pch -no-avx -- -DQT_BUILD_EXAMPLES=ON -DQT_BUILD_TESTS=OFF 2>&1 | tee configure.log
- build with cmake --build .
- install with cmake --install .
- clone qt6-multimedia - git clone https://github.com/psmedley/qt6-multimedia-os2.git
- checkout os2sound branch - git checkout os2sound
- mkdir build
- cd build
- configure with something like:
Code: [Select]
dash /qt6/bin/qt-configure-module .. 2>&1 | tee configure.log- build with cmake --build .
- install with cmake --install .

The above should work - but it's kinda from memory....
Thanks for the instruction.
Re the build requirements of Qt5: Can you please point me, where they are listed?
Title: Re: Strange behaviour in SDL2
Post by: Paul Smedley on July 15, 2023, 10:45:23 am
See steps 1 & 2 of https://github.com/bitwiseworks/qt5-os2/wiki/Developers#building-qt

We should probably move this to a new thread as it's a way OT from SDL2 behaviour. It would be good if others could confirm things build for them - I also need to work out what patches to cmake are necessary and get them into the bww build to make things easier.
Title: Re: Strange behaviour in SDL2
Post by: Dave Yeo on July 15, 2023, 05:41:59 pm
Now, I'm confused and can't remember for sure. Have to revisit.
Title: Re: Strange behaviour in SDL2
Post by: Lars on August 06, 2023, 12:30:31 pm
Update: updated playback, seemed to help with PRBoom+ playback problems, tested by Jochen.
Recording still seems to be a problem, at least with UNIAUD when doing concurrent playback. Need to further inquire.
Jochen updated to latest revision of SDL2, he updated his GITHUB repo:
https://github.com/josch1710/SDL2-os2

BWW also updated their SDL2 GitHub repo to current development state:
https://github.com/bitwiseworks/SDL2-os2
Title: Re: Strange behaviour in SDL2
Post by: Martin Iturbide on August 06, 2023, 06:05:44 pm
Awesome. Thanks Lars, Jochen.

I'm looking forward to test it out once some SDL test binaries get produced.

Thanks.
Title: Re: Strange behaviour in SDL2
Post by: David McKenna on August 12, 2023, 04:15:12 pm
 Installed the new SDL2 from Bitwiseworks, but don't get any sound from PRBoom+, although it seems to work otherwise. Has anyone else tried the new SDL2 and able to get sound? Is there some setting in PRBoom+ needed to get sound on OS/2?

Regards,
Title: Re: Strange behaviour in SDL2
Post by: Lars on August 12, 2023, 04:25:59 pm
Maybe Jochen also had to update PRBoom+ for one reason or the other. He might be able to give an answer.

Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on August 13, 2023, 08:54:07 pm
Installed the new SDL2 from Bitwiseworks, but don't get any sound from PRBoom+, although it seems to work otherwise. Has anyone else tried the new SDL2 and able to get sound? Is there some setting in PRBoom+ needed to get sound on OS/2?

Regards,
Can you start the system volume controll application and adjust the volume while PrBoom is running? Does sound becomes audible, when you adjusted the volume?
This was the behaviour I had, which triggered this thread.
Title: Re: Strange behaviour in SDL2
Post by: Lars on August 13, 2023, 10:00:56 pm
If that is the case, I am sure we can add a simple workaround to the problem on playback: on device open, read the master volume, then set the master volume.
Title: Re: Strange behaviour in SDL2
Post by: David McKenna on August 14, 2023, 02:44:32 am
Hi Jochen,

 If I adjust the volume using the WPS volume knob app while PRBoom is running, the computer locks solid and I have to do a hard reset.

 For MIDI, should I use 'SDL' or 'Fluidsynth' in PRBoom? Or does MIDI not work at all?

Regards, 
Title: Re: Strange behaviour in SDL2
Post by: Martin Iturbide on August 14, 2023, 04:34:45 am
Hello David
For MIDI, should I use 'SDL' or 'Fluidsynth' in PRBoom? Or does MIDI not work at all?
I still haven't use PRBoom with the improved SDL, but I just want to share my notes to get MIDI to work. It worked last time I used PRBoom, but for some people it didn't work that way. (Under your own risk)
- https://www.os2world.com/wiki/index.php/Enabling_MIDI_Support_on_MMOS2_with_Ksoftseq

Regards
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on August 14, 2023, 09:24:53 am
Hi Jochen,

 If I adjust the volume using the WPS volume knob app while PRBoom is running, the computer locks solid and I have to do a hard reset.
That's a new one. Do you have some other SDL2 applications, you can test?

For MIDI, should I use 'SDL' or 'Fluidsynth' in PRBoom? Or does MIDI not work at all?

Regards,
Easiest way is using SDL. For fluidsynth, you would need a soundfont library, and something must be configured (which slips my minds ATM).
Title: Re: Strange behaviour in SDL2
Post by: Lars on August 14, 2023, 12:06:49 pm
Jochen, can you test this with the wave replay Test applications ? They play a single sound file in a loop. And they use the bare minimum of SDL2.
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on August 14, 2023, 01:22:51 pm
@Lars, I don't quite get, what you are getting at. On my machine, the SDL2 tests work.
Title: Re: Strange behaviour in SDL2
Post by: David McKenna on August 14, 2023, 02:40:00 pm
 @Martin: I do have KSoftSeq installed and it works, thanks. Was wondering which MIDI interface to use with PRBoom...

 @Jochen: I tried 'Rocks and Diamonds' ver 4.3.2 and it makes noises and doesn't hang, but I don't know what SDL it uses - I have 4 different DLL's on my system for SDL: sdl2.dll, sdl2200.dll, sdl12.dll, and sdl120.dll. Can you recommend an app to test that you know uses the same SDL as PRBoom?

Regards,
Title: Re: Strange behaviour in SDL2
Post by: Lars on August 14, 2023, 09:34:13 pm
@Lars, I don't quite get, what you are getting at. On my machine, the SDL2 tests work.

Use the test apps to play the sound file and manipulate the volume while doing so.
Title: Re: Strange behaviour in SDL2
Post by: David McKenna on August 14, 2023, 10:14:13 pm
Hi Jochen,

  According to PMDLL, 'Rocks and Diamonds' uses SDL2200.dll, SDL2I200.dll, SDL2M200.dll, and SDL2N200.dll. PRBoom uses SDL2I200.dll only (which in turn uses SDL2200.dll). So it looks like they are using the same version, but in a different manner...

Regards,.
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on August 15, 2023, 09:46:46 am
Hi Jochen,

  According to PMDLL, 'Rocks and Diamonds' uses SDL2200.dll, SDL2I200.dll, SDL2M200.dll, and SDL2N200.dll. PRBoom uses SDL2I200.dll only (which in turn uses SDL2200.dll). So it looks like they are using the same version, but in a different manner...

Regards,.
Yes, PrBoom does some strange things with the SDL2 audio/mixer interface. I'm working at the moment to have the launcher dialog at startup.
I then can work on the sound issues.

Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on August 15, 2023, 09:47:27 am
@Lars, I don't quite get, what you are getting at. On my machine, the SDL2 tests work.

Use the test apps to play the sound file and manipulate the volume while doing so.
No crash on my machine.
@David: What is your setup?
Title: Re: Strange behaviour in SDL2
Post by: David McKenna on August 15, 2023, 12:00:31 pm
 Jochen,

 I'm running a recent install of ArcaOS 5.0.8 with all yum stuff updated to most recent, and latest Arca UNIAUD on bare metal. Tried older UNIAUD and Paul's builds, but no difference. I should point out I don't get a crash, I get a total system hang when trying to use the volume app. Also get a hang when I go to close the game. I've also tried changing various settings in PRBoom, but nothing has helped so far...

Regards,
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on August 15, 2023, 01:10:54 pm
Hi David.

You are correct, but no hang for me, sadly. Can you tell us something about your machine?
Title: Re: Strange behaviour in SDL2
Post by: Lars on August 15, 2023, 01:32:40 pm
Posting the MMPM2.INI would also be potentially helpful.
Title: Re: Strange behaviour in SDL2
Post by: David McKenna on August 15, 2023, 11:15:23 pm
 Jochen and Lars,

  I'll attach a testlog (has all my systems' gory details) and MMPM2.INI...

Regards,
Title: Re: Strange behaviour in SDL2
Post by: Lars on August 16, 2023, 11:32:15 am
Do you have 2 CD-ROM/DVD Drives? If not, remove the drives from MMPM2.INI (IBMCDAUDIO01, IBMCDAUDIO02, including the corresponding sections). Take into account if you have potentially specified a CD-ROM USB drive as that counts as a drive even if it is not attached (it is reserved as such nonetheless).
As a test, remove ksoftseq. The easiest way to do this is to make a backup copy of MMPM2.INI and then to remove
 from MMPM2.INI everything relating to ksoftseq. I can say that I had problems running ksoftseq.
Title: Re: Strange behaviour in SDL2
Post by: David McKenna on August 16, 2023, 12:16:04 pm
 Lars,

  The 2nd CD was a USB one used for testing - removed. I also removed KSoftSeq, but it didn't help, PRBoom still hangs the computer if I use the volume control, and when I try to close the game.

Regards,
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on August 16, 2023, 01:26:49 pm
Does the CAD handler still work? If yes, can you kill the process?
Title: Re: Strange behaviour in SDL2
Post by: David McKenna on August 16, 2023, 09:59:45 pm
Hi Jochen,

  No, <ctrl><alt><del> does nothing, nor <ctrl><alt><num-lock><num-lock>, so can't even get a dump. Have to hit the reset button on the computer.

Regards,
Title: Re: Strange behaviour in SDL2
Post by: Martin Iturbide on August 17, 2023, 03:43:15 pm
Hi Jochen

While you are checking this out, do you think it can be possible also to update PrBoom+ ? For what I see the latest version is 2.6.66 (https://github.com/coelckers/prboom-plus) and the OS/2 version is 2.6um-alpha1. Can you give it a try to see if version 2.6.66 still compiles under OS/2 with what we have? ?

Regards
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on August 17, 2023, 05:06:45 pm
2.6.66 is compiling and running just fine. As I said before, I'm working on the launcher dialog. When I'm done, I will drop a new binary.
Title: Re: Strange behaviour in SDL2
Post by: Martin Iturbide on August 18, 2023, 08:29:24 pm
@Martin: I do have KSoftSeq installed and it works, thanks. Was wondering which MIDI interface to use with PRBoom...

Regards,

David, I was checking some documentation and I found:

"Get "https://www.libsdl.org/projects/mixer/timidity/timidity.tar.gz". Unzip this files on /etc/timidity and you will get support for the MIDI music."

I checked today with my ArcaOS 5.0.8, with  KSoftSeq, and timidity.tar.gz, and the MIDI files are working on my Thinklad L420. PRBoom+ gives me some music background here.

Regards

Regards
Title: Re: Strange behaviour in SDL2
Post by: David McKenna on August 19, 2023, 06:30:22 am
 Hey Martin,

  Thanks for the tip, but doesn't seem to work here - probably for the same reason I don't get any sound in PRBoom. I'm hoping Jochen's next version will help with that.

Regards,
Title: Re: Strange behaviour in SDL2
Post by: David McKenna on August 19, 2023, 03:24:39 pm
 OK - got sound working in PRBoom. I noticed there was a directory in 'Home' for PRBoom, so deleted it. Restarted PRBoom and now everything works - even MIDI music. Also no hang on exit. So anyone having trouble with it - delete that directory in 'Home' and try again...

Regards,
Title: Re: Strange behaviour in SDL2
Post by: David McKenna on August 19, 2023, 03:53:29 pm
 Wait - there's more! Next time I ran PRBoom, there was no sound again. So again I deleted the PRBoom directory under 'Home', then restarted and sound worked. Closed the game, tried to restart - no sound, and hang on exit. So I started looking in the '.prboom-plus' directory under 'Home' and opened the file 'prboom-plus.cfg' to have a look. I was suspicious of the line 'samplerate 44100' so changed it to 'samplerate 48000' and now PRBoom starts every time with sound and no hang on exit!

 So it seems the default samplerate of 44100 is not always appropriate...

Regards,
Title: Re: Strange behaviour in SDL2
Post by: Martin Iturbide on August 19, 2023, 05:23:04 pm
Hi David
Wait - there's more! Next time I ran PRBoom, there was no sound again. So again I deleted the PRBoom directory under 'Home', then restarted and sound worked. Closed the game, tried to restart - no sound, and hang on exit. So I started looking in the '.prboom-plus' directory under 'Home' and opened the file 'prboom-plus.cfg' to have a look. I was suspicious of the line 'samplerate 44100' so changed it to 'samplerate 48000' and now PRBoom starts every time with sound and no hang on exit!

 So it seems the default samplerate of 44100 is not always appropriate...

I'm also experiencing the same "No Sound at PRBoom restart".  But I'm not sure if that is an issue of the samplerate config. In my case, if I reboot ArcaOS I get the sound back on PRBoom+.

I did the following:
- Turned on PRBoom with 44100. Sounds OK (Music and sounds)
- Restart PRBoom with 44100.  No sound
- change PRBoom to 48000 and run. No sound.
- deleted all the .prboom configs at \home\. Run PRBoom to 48000. No sound.
- Restart ArcaOS
- run PRBoom to 48000. No sound
- change back to 44100. No sound.
- Restart ArcaOS
- run PRBoom  with 44100.  Sounds again.
My PRBoom is stable for the moment (on the first run after rebooting ArcaOS). I'm running the automatic demo for some 15 minutes now with Music and Sounds.

I'm using Uniaud32 3.1.3 (2021-10-23), ArcaOS 5.0.8, on my Thinkpad L420 (Intel 6 Series/C200 Series Chipset Family High Definition Audio Controller    8086:1C20)

Regards
Title: Re: Strange behaviour in SDL2
Post by: Martin Iturbide on August 19, 2023, 05:30:36 pm
Hi again

I also found another way to get the sound back, but it is not consistent.
- I get 2nd start of PrBoom without sound, and exit PrBoom
- play arround with some other sounds on the desktop. Drag Drop to produce some sounds
- Restart PrBoom and sometimes, I get back sound (Music and Sound).

Deleting the .\home\.prboom-plus, also does not gives me consistent results.  Sometimes I get sound back, sometimes don't.

Regards
Title: Re: Strange behaviour in SDL2
Post by: David McKenna on August 19, 2023, 07:25:43 pm
Martin,

  When you don't have sound and PRBoom is open, have you tried turning the desktop volume knob a little to see if that brings it back? Jochen said that might help...

Regards,
Title: Re: Strange behaviour in SDL2
Post by: Martin Iturbide on August 20, 2023, 04:30:13 am
Martin,

  When you don't have sound and PRBoom is open, have you tried turning the desktop volume knob a little to see if that brings it back? Jochen said that might help...

Regards,
Hi Dave

I had restarted PrBoom+ like 10 times:
- 4 times the sound came back without any special action
- The rest 6 times with no sound, it worked raising the volume withe Volume knob utility. Sound and music for back each time.
So yes, raising the volume knob worked better than restarting the machine  ;D

Regards
Title: Re: Strange behaviour in SDL2
Post by: Jochen Schäfer on August 20, 2023, 11:01:58 am
Yeah, that was my problem, which started this thread. I'm seeing the  DART device being opened, but the callback for filling the samples never gets called, so there is no sound.
But when some other sound event, like the volume knob or a sound notification, triggers the callback.
Title: Re: Strange behaviour in SDL2
Post by: Lars on August 20, 2023, 11:58:22 am
By the way, was the device opened as shared (via the corresponding SDL env var)? Because if yes, it might be necessary to acquire the device after it is opened and release it before close. Would need to add this to the SDL2 library.