Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

win32 midi driver / MCI crashes on OpenMSX #3941

Closed
DorpsGek opened this issue Jul 11, 2010 · 17 comments
Closed

win32 midi driver / MCI crashes on OpenMSX #3941

DorpsGek opened this issue Jul 11, 2010 · 17 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

ABCRic opened the ticket and wrote:

I started a new game on a 256x256 map and was going to just leave the game there with one AI (NoCAB) running, to see how it developed while alone in that map size.
The music (OpenMSX) was behaving a little strangely, occasionally stopping on a note.
Then the game suddenly crashed, without apparent reason. The problem wasn't the AI, because (silly me) I forgot to set the Maximum number of competitors to >0.
I have uploaded the files generated by the crash and the last autosave of that game. I couldn't make an emergency save as even though the OpenTTD error window showed up, Vista immediately said the program stopped responding so I couldn't click the Emergency save button.

Game version r20111 under Windows Vista.

Attachments

Reported version: trunk
Operating system: Windows


This issue was imported from FlySpray: https://bugs.openttd.org/task/3941
@DorpsGek
Copy link
Member Author

glx wrote:

mciseq.dll!_LookByte@4() + 0x5f octets
mciseq.dll!_GetByte@4() + 0xf octets
mciseq.dll!_HandleMetaEvent@12() + 0x2f octets
mciseq.dll!_SendAllEventsB4@12() + 0xbd octets
mciseq.dll!_TimerIntRoutine@8() + 0x59 octets
mciseq.dll!_OneShotTimer@20() + 0x1b octets
winmm.dll!_DriverCallback@28() + 0x4e octets
winmm.dll!_TimerCompletion@4() + 0x95 octets
winmm.dll!_timeThread@4() + 0x54 octets
kernel32.dll!@BaseThreadInitThunk@12() + 0x12 octets
ntdll.dll!___RtlUserThreadStart@8() + 0x27 octets
ntdll.dll!__RtlUserThreadStart@8() + 0x1b octets


This comment was imported from FlySpray: https://bugs.openttd.org/task/3941#comment8302

@DorpsGek
Copy link
Member Author

Rubidium wrote:

The game crashed on playing one of the midi files. It's crashing now because we changed the default midi driver for Windows yesterday because the other is causing incorrect playback of the MIDI, but by the looks of this it's not really a solution... In any case, you can "work" around it by stopping the MIDI playback or change back to the dmusic MIDI driver, see known-bugs.txt for more.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3941#comment8303

@DorpsGek
Copy link
Member Author

ABCRic wrote:

I changed back to the dmusic driver, as you said. The music is playing normally again.
May I ask why were the changes made? Were the TTD sounds playing incorrectly? I haven't noticed any problems with the OpenMSX music.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3941#comment8304

@DorpsGek
Copy link
Member Author

Rubidium wrote:

Certain combinations/orders of OpenMSX music cause the music to be played differently (wrong pitch). For example play the intro song, then busy schedule and then the intro song again. Around 20-30 seconds into the intro song you'll notice that the guitars sound differently... and if you don't you might have a fancy sound card that handles the MIDI playback and doesn't suffer from this issue.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3941#comment8305

@DorpsGek
Copy link
Member Author

Rubidium wrote:

What version of OpenMSX are/were you using at the time of the crash?


This comment was imported from FlySpray: https://bugs.openttd.org/task/3941#comment8323

@DorpsGek
Copy link
Member Author

ABCRic wrote:

Version 0.2.1, the most recent.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3941#comment8324

@DorpsGek
Copy link
Member Author

Rubidium wrote:

I've let my Windows run through all the songs a few times and they didn't trigger this crash. Did you by any chance choose a subset of songs? If so, which one?
Can you reproduce the crash? If so, on which song (or songs) does it crash?


This comment was imported from FlySpray: https://bugs.openttd.org/task/3941#comment8371

@DorpsGek
Copy link
Member Author

ABCRic wrote:

Music play was normal, all music playing by it's default order.
I've tried reproducing the crash, but haven't had any success. Either OpenMSX 0.3.0 fixed the issue, or it was just an occasional crash. I've noticed that on the second song (Keep on Rolling), if the CPU is under some load (e.g panning the camera quickly) some specific notes hiccup.

I'm also having two more issues:

  1. Wrong songs being played: the Jukebox displays the music track that should be playing, but the song that's actually playing is another one. This occurs when I change the song using the buttons on the Jukebox. This does not happen with the dmusic driver.

  2. The jukebox occasionally skips songs, like if they didn't exist. I only had this issue with the dmusic driver when I updated OpenMSX 0.3.0.

Seems like this new music driver doesn't like me :(
Tests made on r20194


This comment was imported from FlySpray: https://bugs.openttd.org/task/3941#comment8373

@DorpsGek
Copy link
Member Author

Rubidium wrote:

This bug has also been reported as #3965. I would like to ask Ronnie (rh), as he seems to be able to reproduce it quite easily, to open the jukebox and tell whether the crash occurs when a song has just ended or somewhere in the middle of a song. If it is in the middle of a song, is it always the same song? And which song is it?
If it is at the end of the song: can you reproduce it when you disable shuffling of the songs? If so, after which song does it crash? If you know that you can check in the playlist which song follows and tell us which song causes the crash.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3941#comment8380

@DorpsGek
Copy link
Member Author

rh wrote:

It happens on track 2 ("Keep on rolling"), but not always. I timed it three times and it then crashed around 53, 42, 62 sec.
Maybe it can happen on other tracks but this one is a sure thing. It didn't matter if I played other songs before, it seems to happen just at random. There was however a certain tone at the time of each crash (a long tone, the same every time).

I have a multi core CPU (running win7 x64), maybe thats why this issue is more reproducible for me, if it's a threading issue.

Read the other comments and I realize now that I also encountered that the wrong song is sometimes played, if you skip tracks fast I think (forward a couple of tracks -> wait -> then back to the one you started with).


This comment was imported from FlySpray: https://bugs.openttd.org/task/3941#comment8403

@DorpsGek
Copy link
Member Author

ABCRic wrote:

Yup, Ronnie is experiencing exactly the same thing.
At least I'm not the only one.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3941#comment8404

@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 1, 2010

rh wrote:

Have tested the issue of the wrong song playing, and it is like this:

(* Playback is on)
* Press 3 times on the forward button (pretty fast). The correct song is shown in GUI, but only the first next song is played.
* Stop playback, then start it, now the correct song is played (The GUI always shows the correct song).

The same is true for when you press the back button.
This error is not related to the crash on song 2.

Viewed the code and the use of "_song_is_active"-variable seems wrong for a threaded application. The problem is that a song takes some time (a couple of sec?) to start, and when it has been started _song_is_active is set to true, but during this time the user might have pressed the next button more times. Then the later presses will not be seen, since _song_is_active is already true. Some kind of atomic counter is needed instead of the bool variable, or some other thread safe approach.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3941#comment8447

@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 2, 2010

rh wrote:

As I see it, the "Keep on rolling" crash will happen with the MCI midi driver on some systems, and there is no way this is going to be fixed externally, so the only ways to fix this is to either change/correct the song so it does not crash, remove it or find another music driver for 64-bit Windows (as dmusic is not available).


This comment was imported from FlySpray: https://bugs.openttd.org/task/3941#comment8451

@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 2, 2010

Rubidium wrote:

I've created a bug report at OpenMSX: http://dev.openttdcoop.org/issues/1202

It would be nice to know whether there are more songs that crash OpenTTD, or whether this is the only song. Would you please test the other songs? You can, with a custom song, just select all songs except "Keep on rolling".

Yes, the MCI implementation is very nasty and possibly wrong. Problem is that it's almost impossible to easily figure out what MCI is doing; you never know when it has processed a command or not. And on top of it all, it's just dead slow. It's too bad that I'm totally not familiar with the Windows API to say anything useful about the implementation though.

I do, however, know that directmusic does work with a 32 bits OpenTTD on 64 bits Windows.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3941#comment8453

@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 3, 2010

rh wrote:

I let it play the other songs for more than 12 hours and it didn't crash, so I think it's only number 2.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3941#comment8456

@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 9, 2010

Rubidium closed the ticket.

Reason for closing: Won't fix

We can't fix MCI, however... there is a new OpenMSX release coming soon that has the crash causing song removed.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3941

@DorpsGek DorpsGek closed this as completed Aug 9, 2010
@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 9, 2010

ABCRic wrote:

They're removing it?
It was my favorite song :(

I hope that the 'temporarily' part on "Replace 'Keep on rolling' (temporarily) with 'Big Man Boogie' by Jim Redfarn" means they'll put it back soon (and fixed).
I'll keep the song in my playlist and keep using the dmusic driver as I have issues with MCI stopping on some notes on other songs too, specially when the CPU is under significant load.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3941#comment8491

@DorpsGek DorpsGek added Core flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) labels Apr 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Development

No branches or pull requests

1 participant