[karajorma]

Since 3.6.5 I've not been having any luck with mv_music.vp. Like lots of other people I got crashes when using it. After some testing I found that any of my missions in TMA, SoR or Mindgames which used numbers, revelations or any other music from the vp crashed.

However when I tried playing the main FS2 campaign the mission Straight, No chaser (which uses numbers IIRC) worked perfectly. I assumed that FRED must be doing something but I couldn't see anything wrong with the mission file.

It's not FRED.

FS2_Open crashes whenever you run using -mod. The same mission in the data folder will work. I even tried extracting Straight, No chaser to a new mod folder and it crashed there.  Since the only thing in that folder was the mission I know that it wasn't a mod causing the crash.

This probably explains why some people have been able to use mv_music fine while others had crashes. If you're not playing a mod everything works.

Anway hopefully that will be enough to track the bug down now cause I want to play my missions with better music.

BTW I tested using Phreaks latest build but I had previously noticed that FS2 retail missions worked on WMCoolmon's build too.

[Goober5000]

*cue taylor*

[WMCoolmon]

Hmmm.

[taylor]

Just so I know how you are reproducing this, what proceedure are you using?  Are you playing the mission from the techroom (campaign/single?)?  If you've got the campaign mission in a moddir then rename it to something else and try it from single in the techroom and see if it does the same thing.  It's crashing during mission load?  At what point?

It did work in previous builds though right?

EDIT: Oh and your mod does have tbl entries that work with that mission right?

In the next pilot file version, which I'm going to wait as long as I can before making it public, it will save the checksum of the tbls as an extra check.  If the last tbls used don't match the current ones then it will give a popup to let you know of possible corruption so that you can cancel switching to a new campaign savefile or except the risks and continue loading.

[karajorma]

Okay. It's gotten stranger. Now it crashes on mission load (about halfway through) regardless of whether I play using -mod or not. It's gone back to its original behaviour.

I pretty sure I haven't added or deleted anything in the meantime so I think I must have just gotten lucky yesterday or something

Has anyone gotten the music.vp to work properly? Cause I've heard a lot of complaints about it.

[taylor]

Try running with -nomusic and then -nosound to see if that makes a difference.  That would help to narrow the problem down.  With that we'll know if the problem is in audiostr.cpp, ds.cpp/sound.cpp, or some parsing problem.

[karajorma]

Running with no music allows the mission to run.
Running with no music & sound pops up an unrecognised command line parameter -noaudio warning.

[taylor]

Originally posted by karajorma
Running with no music allows the mission to run.
Running with no music & sound pops up an unrecognised command line parameter -noaudio warning.

Ehh, it is -noaudio rather than -nosound.   I can't keep all of these blasted games straight.  That one option should disable music too which is why I wanted you to try just -nomusic first.

I'll go through the music code and see what I can find.  Just use -nomusic for the time being and it still happens at any point let me know.  Must be why the Linux version doesn't crash, I'm not done writing the music code yet.

[karajorma]

If I actually add -nosound to the command line then the mission works. It appears that the launcher is adding -noaudio when the flag is actually -nosound.

[taylor]

Originally posted by karajorma
If I actually add -nosound to the command line then the mission works. It appears that the launcher is adding -noaudio when the flag is actually -nosound.

Normally I would celebrate the fact that I was right the first time but I just had to go and correct myself... incorrectly.     It's been a really long night.

Anyway, the Launcher problem is fixed in CVS now so it will be right in future builds.  Still going over the music code but I haven't noticed anything obvious so far.

[WMCoolmon]

taylor, have you taken a look at the new code I commited? One of the problems was that OGG tried to be smart and seek to the beginning of the memory-mapped file; thus, it went and played through all of the OGG files in sequence. I removed the seek and tell functions and made it the responsibility of the audiostr code to stop playing at the right position, which seemed to work pretty well.

I haven't checked yet whether or not cf_find_file_location returns the correct file if -mod is used, or if it doesn't work that it's handled properly.

[taylor]

Originally posted by WMCoolmon
taylor, have you taken a look at the new code I commited? One of the problems was that OGG tried to be smart and seek to the beginning of the memory-mapped file; thus, it went and played through all of the OGG files in sequence. I removed the seek and tell functions and made it the responsibility of the audiostr code to stop playing at the right position, which seemed to work pretty well.

I gave it a quick look and though I don't see anything there is something that I can't put my finger on.  I'm going back over the OGG docs now, it just feels like something isn't being done.  We'll either have to smarten the code up or dumb the OGG stuff down to work around it.  I'm going to test some more in the next couple of hours and after that I hope to have a handle on a good fix.

I haven't checked yet whether or not cf_find_file_location returns the correct file if -mod is used, or if it doesn't work that it's handled properly.

Yeah, it should work as you expect.  It will only do a physical disk search in the moddir in that case but will find anything in the cache (VPs, all other disk files).  It returns 1 on success and 0 on failure so it's easy to test for.

[WMCoolmon]

I did some testing on this myself- it may not actually be the OGG code itself. I had crash problems with just music.tbl present, and I think there may have been related crashes with my music.vp, which is filled with rather large, uncompressed versions of the OGG files in mv_music.vp. (I'm a sound quality freak at times, what can I say? )

So at this point, I don't think it's a problem with the OGG code per se, more likely the FS2-specific code that gets everything set up.

[taylor]

Forgot that music.tbl isn't parsed if music is disabled.  Kinda hurts debugging.  It is parsed through game_init() though so it's nothing level loading related.  Have you tested to make sure that the parsed filenames are correct and don't have any garbage in them?  If Soundtracks[] or Patterns[] is getting corrupted in any way then it could cause a problem.

My thing with the OGG code may be unfounded but I'm going to change parts of it and see what happens.  I want to say that the issue is how OGG deals with multiple open files at the same time.  I can't remember where I read about an issue with that but I'm pretty sure that OGG (in the lib) reuses some stuff and that may be causing some issues.  I could easily have that wrong though, I wasn't looking for that particular info at the time so I didn't read it that carefully.

[taylor]

@WMCoolmon: You may had said already, but why are you mixing the mmio functions on the OGG stuff?  I think the info is getting out of sync with what's stored in OggVorbis_File.  Just filling in the two missing callbacks (seek and tell) and using the corresponding ov_raw_*() functions would be a better bet.  I made the change on my local build and the crashes have stopped, so far.  Try it out yourself and see if you get similar results.

With the returns from those callback funtions being errors I'm not sure what the ogg lib would do.  According to the docs it would get treated as a stream which may be what you intended but mmio is supposed to handle that.  You won't really save anything by using seek and tell yourself and ogg may put itself into a counterproductive state because of it.

[karajorma]

I did actually try making a new music table from the old one with only one of the .ogg files used. As soon as I tried to load a mission which used that song it crashed. Admittedly I didn't change any of the numbers after the filename because I wanted to check if they could be the cause.

Maybe I should emphasise that missions only crash if they actually use one of the .oggs. Missions that use one of the other sound tracks work fine.

[taylor]

Originally posted by karajorma
Maybe I should emphasise that missions only crash if they actually use one of the .oggs. Missions that use one of the other sound tracks work fine.

That's what I noticed as well.  Didn't crash on mission load but in game, when the soundtrack switched from normal (a WAV) to battle (an OGG) music it crashed.  Mission in question was "The Sixth Wonder".  I checked everything I could find but never saw an issue with actually parsing the tbl, only with playing an ogg.  The initial buffer of an ambient or normal OGG track could cause it to crash on level load.

I think my fix should get it working fine but I'd rather have WMCoolmon in agreement with that before adding it to CVS.  The behavior OGG expects in the seek callback is slightly different than what mmioSeek provides so I'd feel better with a second opinion from the guy who wrote the code in the first place.

[WMCoolmon]

If I'd known the functions existed, that would be what I would've done instead. I must've missed ov_raw_seek when I was looking for a way to set the original stream pointer.

If it's working for you, go ahead and commit it and I'll keep an eye out for problems - should be pretty obvious and it's simple to test for.

[taylor]

Originally posted by WMCoolmon
If it's working for you, go ahead and commit it and I'll keep an eye out for problems - should be pretty obvious and it's simple to test for.

Ok, I'll put it in shortly.  If it looks wrong at all to you let me know.

EDIT: It's in.  If you want to release a new build know that it will have some Linux changes in it.  Shouldn't be an issue but if you don't want to get that in your tree yet just update code/sound/audiostr.cpp and code/sound/ogg/ogg.cpp for this particular change.

[WMCoolmon]

Yeah, not a problem. I already updated today, so the Linux changes are all in my codebase already.