[Lindsayts]

roeter, on 22 July 2013 - 04:06 PM, said:

Hello,

now we're one this subject, there's something that's been bothering me for quite some time.
When the system has to load a 'new' sound (i.e. one that's not been played before in this session), the whole display freezes while the sound is loaded.
I would assume that with multithreading etc., display would be independent from sound, but apparantly that is not so.
Are we one thread short - should sound have it's own thread? Or is there something else going on in the background that's causing this?

Thanks,

Rob Roeterdink

There's probably no real way around this sort of problem. One can if one has the time to try and optomise the particular thread's software to minimise the issue but in the end there is no real way to forecast the future requirements of the program in a simple and non intrusive fashion (note the simple and nonintrusive).
Over the years (we are talking 50 years here!) there has been PLENTY of effort within hardware, aplication programming and operating system design to try and minimise file axis times.

Lindsay

[James Ross]

roeter, on 22 July 2013 - 04:06 PM, said:

now we're one this subject, there's something that's been bothering me for quite some time.
When the system has to load a 'new' sound (i.e. one that's not been played before in this session), the whole display freezes while the sound is loaded.
I would assume that with multithreading etc., display would be independent from sound, but apparantly that is not so.
Are we one thread short - should sound have it's own thread? Or is there something else going on in the background that's causing this?

There is a very long-standing bug in the cab control code, which causes it to load the sound files directly (i.e. in the Updater Process). This is obviously completely wrong but I've not felt comfortable enough with the sound code to fix it. Everything else, including environmental sounds, is all done from the Sound Process, which is a completely independent thread and AFAIK never causes any issues.

[dennisat]

James Ross, on 23 July 2013 - 01:58 AM, said:

There is a very long-standing bug in the cab control code, which causes it to load the sound files directly (i.e. in the Updater Process)

Are sounds for the AI train cabs loaded and played? I sometimes here cab sounds when in external views, eg brake and throttle operation, which are not the Player train cab sounds. I am assuming these sounds are coming from nearby AI trains. If this is the case, could these sounds not be loaded or is it likely to be a problem with the sms file?

Dennis

[gpz]

This shouldn't normally happen, there is a code piece that intends to prevent this. Can you reproduce it (preferably with standard routes)? If you can, please file a bug report at https://launchpad.net/or

[copperpen]

James

Thank you for explaining the why and how of the stutters. I have tried the experimental load delay, but it is definitely not for me. The load process is made longer as intended, which does smooth things out quite well, however the big downside is chunks of scenery popping into view quite close to the player viewpoint. I will put up with the judders and screen freezes until a solution is found.

[gpz]

James Ross, on 23 July 2013 - 01:58 AM, said:

There is a very long-standing bug in the cab control code, which causes it to load the sound files directly (i.e. in the Updater Process). This is obviously completely wrong but I've not felt comfortable enough with the sound code to fix it. Everything else, including environmental sounds, is all done from the Sound Process, which is a completely independent thread and AFAIK never causes any issues.

James,

Do you mean the LoadCarSound() and LoadTrackSound() functions in constructors of MSTSWagonViewer and MSTSLocomotiveViewer classes? Those parse the sms files, add SoundSource objects to SoundSources list and register events at car loading time, but don't actually load any wav files. Wav files get loaded by the sound process when it runs through SoundSources. Or is there some other code that don't come to my mind now? (I'm really interested, it should be fixed if possible.)

[James Ross]

gpz, on 23 July 2013 - 09:29 AM, said:

Do you mean the LoadCarSound() and LoadTrackSound() functions in constructors of MSTSWagonViewer and MSTSLocomotiveViewer classes? Those parse the sms files, add SoundSource objects to SoundSources list and register events at car loading time, but don't actually load any wav files. Wav files get loaded by the sound process when it runs through SoundSources. Or is there some other code that don't come to my mind now? (I'm really interested, it should be fixed if possible.)

I don't think it is that code; it is the code that plays sounds when you operate the cab controls. I've not actually looked in to the code but I have clearly observed the cab control sound files being loaded on the wrong thread.

[gpz]

There is only the OpenWavFile() function loads wav files, which is called from constructor of SoundPiece class, which is called only by SoundItem.SetPiece() function, which is called from ALSoundSource.Queue(), which is called from sound commands' Run() function. These functions are called by TryTrigger(), which is called by SoundStream.Update(), which is a sound thread function.

Cab sound events are registered in MSTSLocomotiveViewer:
if (Locomotive.CabSoundFileName != null) LoadCarSound(wagonFolderSlash, Locomotive.CabSoundFileName);

But this line doesn't load the wav files, just adds the SoundSources and SoundStreams to the list, for being updated as written above. As I can find out these tasks are completely separated. (And these lines might be extremely boring for a non-programmer. :drinks: )

[James Ross]

gpz, on 24 July 2013 - 11:55 AM, said:

But this line doesn't load the wav files, just adds the SoundSources and SoundStreams to the list, for being updated as written above. As I can find out these tasks are completely separated. (And these lines might be extremely boring for a non-programmer. ;) )

If this has changed in the last few months, the issue might be fixed now, but I know it was an issue not that long ago.

[gpz]

James Ross, on 25 July 2013 - 12:45 AM, said:

If this has changed in the last few months

Well, I'm afraid not. So it must be something else.