Set start time to play sound in A_PlaySound

[Nash]

As a follow up to my previous request, I'd like a new parameter in A_PlaySound to set the starting time to play the sound from.

[ZzZombo]

Sorry? Isn't it there you just set the preceding state's duration equal to the desired delay?

[wildweasel]

I suspect Nash is asking for the other way around: not delaying the A_PlaySound, but specifying that the A_PlaySound should start somewhat further in to the sound than from its beginning.

[Nash]

Yeah the whole point is not to delay when the sound starts. But to make it play from a random starting position.

Say you have a long, 1 minute ambient sound loop (played in UI context). Every time you enter the level, the sound keeps playing at the start. You'll eventually recognize the sound patterns and then you'll get sick of hearing it.

[RockstarRaccoon]

I'd really like to be able to do this sort of thing for music too, being able to see where it is in one track and starting at the same place in a different track, for things like having multiple versions of a song that switch between each other at certain points...


That said, Nash, I think you should consider having said Ambient sound play differently in different parts...

[Graf Zahl]

I'd really like to be able to do this sort of thing for music too, being able to see where it is in one track and starting at the same place in a different track, for things like having multiple versions of a song that switch between each other at certain points...

Most music renderers do not support any fast forwarding to a given position so this is very unlikely.

[Nash]

This is directed to Chris:

I'm sorry for bumping this, but think you could take a look at this?

I have already tried to do it on my own and maybe help submit a PR but OpenAL is really strange to me.

I did try - I tried to see what the engine is doing with the "load game" code - because I know for sure that loading a game would set the sound position to whatever it was previously at - I thought I could somehow do some copy pasta here and apply the same concept - but no luck so far. :(

Forgive me if I'm wrong but the feature suggestion in the OP - to my inexperienced eyes as least - sounds like something that'll be trivial to do; in fact I was so confident that it is, hence why I tried to do it myself... it's just that I really have no idea how to do anything with OpenAL. :S

If you'd rather not do it, then perhaps you'd be willing to provide me some pointers on where to start looking? I'm comfortable enough with doing my own PRs, after all.

Thanks, and sorry for the bump again.

[Chris]

This will probably need a bit of work in both the higher and lower level sound code. It's trivial for OpenAL itself, but the OpenAL backend only knows to set a time offset when the sound-to-play comes with a predetermined FISoundChannel, as a result of loading a save game or restarting a sound that got preempted. For it to work with a freshly started sound, you'd need to add another parameter to the SoundRenderer's StartSound and StartSound3D (and MarkStartTime) methods that specifies a start offset (either in samples or (milli/micro)seconds, given the available information and desired precision).

It's the higher level code (src/s_sound.cpp and related places with scripting glue) that I would be completely lost on.

[Major Cooke]

If you can provide the code for OpenAL, I could fulfill the ZScript side of things, now that Nash has brought this up to my attention again. ZScript has a function for getting the length of a sound and returns a double, I don't remember the specifics of it. S_GetLength() I think?

[Chris]

If you can provide the code for OpenAL, I could fulfill the ZScript side of things, now that Nash has brought this up to my attention again. ZScript has a function for getting the length of a sound and returns a double, I don't remember the specifics of it. S_GetLength() I think?

The code for setting the source's start offset is already there in OpenALSoundRenderer::StartSound and OpenALSoundRenderer::StartSound3D, when reuse_chan is not null. I'm not 100% convinced this is a good idea though, given that a scripted start offset may not work properly when a sound gets modded, requiring a change to the scripts along with the sound.

[Marisa Kirisame]

Making the start time relative to length (in a range of 0.0-1.0) seems more reasonable then.

[Nash]

Making the start time relative to length (in a range of 0.0-1.0) seems more reasonable then.

Yeah, this makes sense.

[Major Cooke]

That's what I was thinking too. What do you think, Chris?

[Chris]

That would probably end up being worse, as the start point would then be affected by any tailing silence or fade out characteristics of the sound, in addition to any internal timing differences. Specifying the offset in time units (floating point seconds, or microseconds or something) I think would have fewer overall issues, and the ones it does have could be more easily corrected by sound authors. It's just that I imagine few sound replacers actually use newly authored sounds and instead are pulling from some other sources where timing issues can't be corrected so easily.

[Major Cooke]

...Okay, I somehow completely missed this part.

It's just that I imagine few sound replacers actually use newly authored sounds

...Crap. There's no way around this either, at least from attempting to look through the source code. A shame. If there was a way to detect if a sound was played or was a random sound, then it could've been programmed to have the option of skipping the start time positioning, but alas...