A_PlaySound(... samplePos), and S_GetSampleLength

[Nash]

These are 2 suggestions condensed into 1 because they are related.

1) Ability to set the starting position of the sound to play, in samples

I'd like a new argument to A_PlaySound that allows me to set specifically at which sample to start playing the sound.

2) Retrieve sample length of a sound

Similar to S_GetMSLength, I'd like a function to retrieve how many samples a sound is, given the sound ID.

Use case: I have some looping sounds played in UI context, which I do not want them to start at exactly the same point all the time. I would use S_GetSampleLength to randomize the starting sample position.

[Chris]

1) Ability to set the starting position of the sound to play, in samples

I'd like a new argument to A_PlaySound that allows me to set specifically at which sample to start playing the sound.

While not impossible to add, this would be dependent on the sound being played. If the sound gets updated (or modded) with a different sample rate, the start sample offset may no longer be the intended point of the sound. Is that an acceptable issue?

Use case: I have some looping sounds played in UI context, which I do not want them to start at exactly the same point all the time. I would use S_GetSampleLength to randomize the starting sample position.

Starting a sound at a random sample position can randomly cause the sound to exhibit a click or pop at the start from a sudden change in amplitude, even if it otherwise sounds quiet, depending on the initial sample value it starts at. If you want multiple instances of the same sound to play unsynchronized, it seems to me that a better option would be to have a random delay before starting the sound, and/or add very small pitch variations (small enough to not change the apparent tone, but enough that the play positions drift over time).

[Graf Zahl]

I don't think that this is a good idea at all.

[Nash]

If the sound gets updated (or modded) with a different sample rate, the start sample offset may no longer be the intended point of the sound. Is that an acceptable issue?

I don't think that this is a good idea at all.

S_GetMSLength() is already doing the exact same thing. Why was that allowed to be scriptified in GZDoom then?

Starting a sound at a random sample position can randomly cause the sound to exhibit a click or pop at the start from a sudden change in amplitude, even if it otherwise sounds quiet, depending on the initial sample value it starts at. If you want multiple instances of the same sound to play unsynchronized, it seems to me that a better option would be to have a random delay before starting the sound, and/or add very small pitch variations (small enough to not change the apparent tone, but enough that the play positions drift over time).

- I can't add a delay because the sound loop is over 1 minute (it's background ambience) and it'd be weird of the sound randomly takes about a minute before starting.

- Random pitch is unacceptable because it changes the audio quality.

- The pop/click issue can be solved script-side by playing the sound with 0 volume and then fading the volume in manually.

I might have to settle with multiple copies of the audio asset, all offset differently. But I want an answer about S_GetMSLength first... I find it contradicting that that one is scriptified, yet it will exhibit the same problem as Chris' first response.

[Graf Zahl]

The main issue with 'samples' is that it is not a time-based unit. Getting the length in milliseconds abstracts from how waveform sounds are constructed and will survive even if in the future a sampling-rate-agnostic format or something that can alter its sampling rate depending on the data gets invented. So any info based on amount of samples won't fly.

[Nash]

Understood... ok what about setting a sound to start playing at a specific time (milliseconds, seconds, whatever) be more feasible for the engine? Sorry for being persistent but this is a sound design problem and I kind of take those things seriously... =P

Basically this would all I'd be asking for then. A new argument to A_PlaySound that allows you to set the starting play position using time. Click and pop is not a problem for me, I can make my own homebrew fade-in curve.

[Graf Zahl]

If OpenAL can do it, that should be possible.

[Chris]

There's no issue on OpenAL's side. Just need to set the source's AL_SAMPLE_OFFSET or AL_SEC_OFFSET property before playing the sound. There's already some code dealing with that, relating to sound preemption (if a sound can be automatically restarted after being preempted, it tries to restart playing at where it would be if it had kept playing) and save loading (when sounds are started given the time they were at in the saved state).

Also, OpenAL Soft does take some measures automatically to prevent clicks and pops when starting in the middle of a sound, by doing a quick volume ramp if it's not starting at offset 0 (gain starts at 0 then ramps up to the intended volume over 20ms or so). At least, it does that in the current Git version. I think 1.18 does as well, but I'm not 100% sure.

[Caligari87]

Just would like to add that defining the starting point in common time units (hs.ms) would definitely be preferable to samples for common use, although perhaps both could be optional.