[Matt1983]

Here in Argentina, all trains (diesel) honk before leaving

https://www.youtube....h?v=l5rpo_BgHow
https://www.youtube....h?v=vKRsLurPzSA
https://www.youtube....h?v=FPGCxhT9H7E
https://www.youtube....h?v=Hh9fhM7OagA

In the United States, many passenger trains activate the bell to depart.

[Hamza97]

Here in India, trains are required to sound 1 long blast of High-tone horn followed by 1 short blasts of Low-tone. At level crossings there are no particular rules but sign boards are placed 250m before the LC and pilots honk to there hearts content..... :rolleyes: :pardon:

[gpz]

Csantucci, on 13 April 2015 - 11:55 PM, said:

AI horn blowing will stay as it is in Release 1.0, as feature changes are frozen now. However I have the intention of inserting further new features after OR evolution restarts:
- horn blast heard at higher distances (with the help of Peter (gpz) I hope)
- configurable maximum distance at which blast starts
- optional North-American blast sequence, including horn still playing when passing crossing.

Carlo, I have thought of a different strategy of OpenAL sound source management, than we are doing today. The original (current) code assigns an OpenAL source to every sound source getting into cutoff distance circle automatically. I think, this is a waste of resources, since quite a few of them are actually playing, most of them are just sitting in the memory waiting for play. Instead, a better way would be to actually assign an OpenAL source only to sounds wanting to play, and revoking it from them once they have stopped. The buffers are still sitting in memory, so it wouldn't cause more disk reads than now, just we could drastically reduce the number of utilized OpenAL sound sources, which is the current limit of increasing the cutoff distance. This way the cutoff distance could be increased maybe upto 1.5-2 km, from the current 400 m.

If I published a patched branch, wouldn't you mind testing it at one of your sound-crowded locations?

[Csantucci]

Hi Peter,
Yes, I can test it.

[gpz]

I'm sorry for the delay, here is the git branch with modified behavior: https://github.com/p.../SoundSourceIDs

I increased the cutoff distance to 2 km, so horn blast can be heard from much higher distance.

I have also modified the Sound Debug Form to show the actual number of utilized sound sources. I have done the modifications with two different commits, so you may checkout the HEAD's preceeding commit to see the same number in Sound Debug Form before the modifications.

[Csantucci]

Hi Peter, I have downloaded your latest commit and will test it. As I am not expert at all in GitHub, can you tell me how to access your preceding commit? (The one where you only inserted the display of the number of sound sources used in the Sound Debug Form).

[Csantucci]

First impressionis that this seems to be a great improvement on sound. Hearing horn up to 2 Km is impressive.
However I found a problem: I have some trainsets where the bell trigger is used as a second type of horn, e.g. like here:

			Stream (
				Volume ( 1.25 )
				Skip (Stream14 **** This stream allows the whistle to be played at the same time  	**** )
				Priority ( 6 )
				Triggers ( 1
					Discrete_Trigger ( 10	PlayOneShot ( 2
													File ( "Fischio_corto.wav" -1 )	
													File ( "Fischio_doppio_11.wav" -1 )	
													SelectionMethod ( RandomSelection ))) 
				)
			)

Well, this sound (in this case it's within a cab sound .sms file) isn't heard with your version, while it's heard both with OR 1.0 and OR x.3415.
Testing continues.

[gpz]

Probably an ID assignment is missing from somewhere, I will test it out. (I have ideas. :) ) In the end I would be curious about the max number of sources utilized in an area with many-many sounds. I'm curious about it, because if we could go below 256 with the needed number of sources, there would be no need for the custom-compiled oal-soft.dll, a pre-compiled version could be enough (e.g. the one that comes as a nuget package), and the source package could be removed from our repository.

[disc]

There was a fixed 400m cutoff? I didn't knew that, however the most of the sound activation distances are set to too high in sms files already. How the CPU usage of sound process looks, with this new OpenAL handling?

[gpz]

disc, on 21 January 2016 - 04:29 AM, said:

There was a fixed 400m cutoff? I didn't knew that, however the most of the sound activation distances are set to too high in sms files already. How the CPU usage of sound process looks, with this new OpenAL handling?

You can answer your own question about CPU usage, if you compile the branch on your computer. :)

[Csantucci]

The problem is more general: PlayOneShot sounds triggered by a discrete trigger don't work (I don't know if also those triggered by a variable trigger don't work). Maybe better that I continue testing after you have corrected this.

[gpz]

Csantucci, on 21 January 2016 - 05:10 AM, said:

The problem is more general: PlayOneShot sounds triggered by a discrete trigger don't work (I don't know if also those triggered by a variable trigger don't work). Maybe better that I continue testing after you have corrected this.

Yes, I think it would be better. I thought that the problem is general to playoneshot, because although currently I cannot see the code, but I remember, that those sounds were handled a bit differently. It will be an easy fix. :)

[gpz]

I have adjusted the activation/deactivation logic a bit. Carlo, could you please try to make a test? (Uploaded to GitHub.)

[Csantucci]

Hi Peter,
these are the first results:
- hearing distance 2Km: OK
- PlayOneShot sounds: OK
- transition between different motor sounds: OK
- max amount of Sound Sources in a crowded European station: 293
- max amount of Sound Sources with a single 80-Wagon, 4-Engine USA train in explore mode (2 per wagon plus a bunch for every engine): 205 (but could be the double when meeting another similar train, which can be usual in USA routes).

So, positive test.

If it is envisaged to reduce the default maximum number of Sound Sources, I would reduce it to not less than 512, and I would leave the configuration capabilities present now (no hardcoded number). You never know...

I didn't make comparison tests about CPU usage.

[gpz]

Good to hear the results. :) Thanks for the testing! I don't think I will replace the current OpenAL32.dll, rather it will be a possibility for the future. And in any way, the configurability will remain as it is now, since that is a base feature of OpenAL Soft. But still, I think this new source management strategy is the right way of doing it, so I will create a blueprint about it, and commit these changes to the main repository.