Adventure Game Studio

I wanted to run some tests for audio playback, and had problems with the following code:

function on_key_press(eKeyCode keycode)
{
//music is a global *AudioChannel
if (keycode == eKeyZ)
music = aWavFile.Play();
if (keycode == eKeyX)
music.Seek(music.Position + 1000);
if (keycode == eKeyC)
Display("Test %d", music.Position);
}

I could start music by pressing Z, pressing X does nothing, pressing C displays 0.

I switched from using a WAV file to an OGG file and the same code works with no problems:

function on_key_press(eKeyCode keycode)
{
//music is a global *AudioChannel
if (keycode == eKeyZ)
music = aOggFile.Play();
if (keycode == eKeyX)
music.Seek(music.Position + 1000);
if (keycode == eKeyC)
Display("Test %d", music.Position);
}

Pressing X now skips forwards and pressing C displays the current position. Is this expected behaviour or is this a bug? I haven't read anywhere that WAV files should be treated any differently, other than threading may be handled differently. I'm testing in 3.4.0.3 (Alpha).

Quote from the manual:

Quote
AudioChannel.Seek(int position)

Seeks the audio clip that is currently playing on this channel to position.
What position represents depends on the FileType of the audio clip:

MIDI - the beat number
MOD/XM/S3M - the pattern number
WAV/VOC - the sample number (eg. in a 22050 Hz sound, 22050 = 1 second)
OGG/MP3 - milliseconds offset

This means that when Seeking in the WAV you are using different units. This is possible that you can't seek by any random number that is not a fraction of its frequency.
Frankly I never knew how it works in AGS in detail, but you could do some experiments, changing the number to your WAV frequency, for instance, and see if that will at least work.

Thanks, that may explain the problem with the seek, but when reading the position I'm getting 0 back. Shouldn't requesting the position from the wav file should be more straightforward, since the sample number is a discrete value, unlike time? I'll try with some shorter files and lower sample rates and see if that makes any difference.

It works with a shorter WAV file, so I guess this is a limitation somewhere based on the total sample count. The audio I was originally using is 4 minutes long at 44.1kHz, this is 10584000 samples in total, so should have been okay for working with 32bit integers.

Ok, here's what I found so far. There is some problem in AGS related to WAV files, that it cannot parse some formats properly. It may still play them, but trying to Seek in them or get current position fails, because AGS thinks that file does not play for some reason (yet it still plays it to the end ...). That might be a lack of functionality, plus a bug of some kind in the engine.

I was testing with AGS 3.2.1, so its rather old.

After trying out several files I had on my disk, I managed to find a WAV file that works correctly in AGS. Your code worked perfect with it. I also tried larger seek values (like "+ 22050") to make jumps more noticeable.

I agree that the Seek function is currently not easy to use with WAV files. There is a Position/PositionMs properties pair that return a position depending on clip type, and actual position in milliseconds respectively. I think that it may be a good idea to introduce SeekMs function.

Thanks for looking at this.
If you would like any help testing the problem further, or testing a potential fix, please let me know.