Frogger 2 CD Music doesn't resume with DxWnd

[BEEN_Nath_58]

The game uses CD Audio, but even with using VCDA, the audio doesn't resume after unpausing the game. The game has an export provided, but that didn't prove any useful.

What do you suggest me to do? Inject Suspended Process hook is used.

[BEEN_Nath_58]

Pinging this thread, the audio doesn't work with Fix MCI Id and Hide empty CD ROM Drivers enabled.

[gho]

In my testbed the game works fine, the sound works. The only problem maybe is that when the game is paused and resumed the audio is not resumed from where it was played but it restarts from the beginning of the track, this also when "Emulate CD pause capability" is set. But I'm not sure if this is a problem of DxWnd CDA or it happens also with genuine CD music.
This game was discussed already and with you here: https://sourceforge.net/p/dxwnd/discussion/general/thread/688738716b/#66e7
Is this post a continuation of the the other thread?
Here the game works also with Fix MCI Id and Hide empty CD ROM Drivers enabled. Can you send logs about this problem?

[BEEN_Nath_58]

The only problem maybe is that when the game is paused and resumed the audio is not resumed from where it was played but it restarts from the beginning of the track, this also when "Emulate CD pause capability" is set.

That is the issue.

This game was discussed already and with you here: https://sourceforge.net/p/dxwnd/discussion/general/thread/688738716b/#66e7
Is this post a continuation of the the other thread?

We went to Frogger 1 instead so I though let that be a Frogger 1 thread.

But I'm not sure if this is a problem of DxWnd CDA or it happens also with genuine CD music.

The music always resumes under Windows 98. This issue shouldn't be under my system only, since this has existed over multiple Windows installations.

Here the game works also with Fix MCI Id and Hide empty CD ROM Drivers enabled. Can you send logs about this problem?

I mean I thought they may fix this, but they didn't.

Log was created using Inject suspended process hook

[gho]

Today will be a busy day, but I can just resume what I found yesterday (luckily I had the game already installed).
The game doesn't try to pause the game and resume with MCI_PAUSE and MCI_RESUME messages, it uses MCI_STOP and then MCI_PLAY.
Adding the "Emulate CD pause capability" flag doesn't change anything, also because the game doesn't query this capability with come MCI_STATUS message.
In theory, the game could also resume by sending a MCI_PLAY command at a track position corresponding to the last position, but this doesn't happen, the command is always to start at the beginning of the track. Maybe this could depend on DxWnd CDA player that doesn't return this value to the game? This is why a log from Win98 would clarify the issue, too bad that this is not possible. Anyway, I think I could manage this. I spotted a suspicious MCI_PLAY command in the log apparently with no reason, perhaps that was the instruction that should return the current seek point in the CD track.

[gho]

In more detail, my apologies for the confusion I made ... the following log was from a test where I paused @time=51sec and resumed @time=64sec. You can see that the resume used a MCI_PLAY message with no track specification, which means resume, but here

[00064:938] > dwFrom: seeked 0x30000

the seeked position 0x30000 points to the beginning of track 3 (the one currently playing). So, I suspect that the previous MCI_STOP command

[00051:547] mciSendCommandA: IDDevice=0x0001 msg=0x808(MCI_STOP) flags=0(NULL)
[00051:766] Sending MM_MCINOTIFY MCI_NOTIFY_SUCCESSFUL message on STOP devid=0x1 hwnd=0x3
[00051:766] Sent MM_MCINOTIFY MCI_NOTIFY_SUCCESSFUL message: hwnd=0x3, res=0

was supposed to send the current seek position to the game to be used to resume later on.
Quite interesting!!

[BEEN_Nath_58]

so that means the MCI_STOP command has to store the current audio position but fails to do so?

This is probably a new discovery, one never discussed as far as I have see

[gho]

This is interesting too: from https://docs.microsoft.com/en-us/windows/win32/multimedia/mci-stop

Remarks

The difference between the MCI_STOP and MCI_PAUSE commands depends 
on the device. If possible, MCI_PAUSE suspends device operation 
but leaves the device ready to resume play immediately.

For the CD audio device, MCI_STOP resets the current track position 
to zero; in contrast, MCI_PAUSE maintains the current track position,
anticipating that the device will resume playing.

So, it's not strange that the audio track restarts from the beginning. To resume at the last point there could be two ways:
1) use the MCI_PAUSE message instead of MCI_STOP, but the game doesn't seem to be querying this possibility or making any attempt ...
2) get the current position from the MCI_STOP command or the MCI_GENERIC_PARMS message, but I can't see any field that could possibly hols the value.

So, unless there's something I miss, it seems impossible to resume in this situation.

[BEEN_Nath_58]

Windows WINMM has an even poorer situation, when you pause the music it will go to track02,. and further pause/resume will just restart track02. Let me try ogg-winmm...

Update: Game doesn't even use winmm.dll in the game directory, not even with .ogg files (I personally used .wav)

Update 2: Using dippy-dipper's ogg-winmm, I first had to edit the executable to use fr2mm.dll (his winmm.dll renamed) otherwise the game won't use it. When the game could utilise this file, there was another weirdness. The music plays, but when paused, the music doesn't start at all.

[huh]

@BEEN_Nath_58

The music always resumes under Windows 98.

How did you find out? Do you have Win98 in emulation or on real hardware?
Does that mean the music continues from where it ended?

@gho
information from the link you posted applies to: Minimum supported - Windows 2000 Professional
This suggests that it could be different in Win9x.

[BEEN_Nath_58]

@huh2 PCEM is always there for these situations.

[huh]

Okay, I'll try it with audio CD and MCI Tester on Win98 with real hardware sometime in the middle of next week.

[BEEN_Nath_58]

@huh2 can you provide me with MCI tester?

[gho]

mcitester should be included in the tools folder if you download the DxWnd sources instead of the DxWnd bundle. In the download area there are two folders, one for the releases, one for the sources. Can you spot the file v2_05_76_src.rar ?

[huh]

MCI Tester compiled by @dippy dipper is here:
https://sourceforge.net/p/dxwnd/discussion/general/thread/0d852410/?page=25#2ac3

[gho]

I am also investigating another possibility. The MCI_STOP command comes after a MCI_PLAY from=to=NULL + MCI_NOTIFY. The meaning of this MCI_PLAY is the same as MCI_RESUME, but the DxWnd CD emulation doesn't send a MCI_NOTIFY answer message in this case, and I'm wondering if it could be this missing message that could force a stop.
But if the theory is true, the sound should resume correctly also on Windows XP and later when using an actual CD and winmm.dll ....

[BEEN_Nath_58]

Is there anything you need from Windows 98 Frogger 2? I am currently installing it and list me the things you need.

But if the theory is true, the sound should resume correctly also on Windows XP and later when using an actual CD and winmm.dll ....

Let me try on Windows XP too.

Update: Music plays fine on Windows XP, just like on Win98.

[gho]

So, I need this: a dxwnd log with ONLY the "Sound" log topic + "Timestamp" (see screenshot) taken in a game session where the sound resumes, of course without CDA emulation but with a genuine CD (or playable image).
Possibly, leave some time interval between the stop and the resume and take note of the timing (see the timing trick described before with the FPS overlay) so that I will match exactly the logs with the events.
That will give me a reference about how things should work in the good case.

[BEEN_Nath_58]

Does Windows 98 support DxWnd? On my way to finish installing 98

[BEEN_Nath_58]

Oh got it from Windows XP

[gho]

My apologies (I should have checked before) but in the case of no CDA emulation the interesting info is collected only if you also set the "Logs / Debug" flag. Could you make another run with this additional flag, please?
Anyway, one thing is known for sure: the game is pausing / resuming the CD track without using the MCI_PAUSE and MCI_RESUME or even a MCI_SEEK command. The only way should be using a MCI_PLAY from a fixed time ahead of the beginning of the track. The question, then, is why using the CDA the time is not correctly calculated?
P.s. what sort of host and CD emulation are you using in the WinXP VM? I have a VMWare client here and probably I'd better get myself a decent CDA WinXP environment too, to run my tests without bothering other people too much....

[gho]

This link https://books.google.it/books?id=RJBJPJvct40C&pg=PA441&lpg=PA441&dq=MCI_STOP&source=bl&ots=fyGq8Y3Vid&sig=ACfU3U0gJQ6vItN6KaoXTIyTPIa9pltN9w&hl=it&sa=X&ved=2ahUKEwiYuaGhy4b0AhUG3aQKHXM4DWEQ6AF6BAgQEAM points to a book (too bad it's not a downloadable pdf!) that explains how the old CDPLAYER program was working without using MCI_PAUSE / MCI_RESUME and using only MCI_PLAY / MCI_STOP keeping track of the position. It seems quite similar to Frogger 2 logic, though it doesn't explain where my CDA fails. Still, it seems that the missing MCI_NOTIFY messages could be a promising track.

In effect, all article from page 440 to 444 is quite interesting! It seems to be really pertinent.

[BEEN_Nath_58]

Log with Debug option:

P.s. what sort of host and CD emulation are you using in the WinXP VM?

Using Alcohol 120% to mount on host and using that mounted drive directly in VM.

I have a VMWare client here and probably I'd better get myself a decent CDA WinXP environment too, to run my tests without bothering other people too much....

I wouldn't be able to use my PC from 11th to 23rd, so it would be useful if you could have a machine by then.

[BEEN_Nath_58]

What's the update?

[gho]

Nothing at the moment. I've been busy on another thread and on private matters, but mostly the problem is that to fix this issue it will be necessary to know and emulate exactly the flow of MM messages from the game, the player and the callback routine. It is something that until now was implemented very roughly and badly, it worked to notify the end of a track but it's not enough in this case. So, I need to add more logs, wrappers and run some tests before to write any piece of code to manage the situation. It will take a little, please, be patient.