Cannot seek or read audio position for WAV file, but can for OGG file

Started by morganw, Sat 31/01/2015 23:33:12

Previous topic - Next topic

morganw

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

Code: ags
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:

Code: ags
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).

Crimson Wizard

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.

morganw

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.

morganw

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.

Crimson Wizard

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.

morganw

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

SMF spam blocked by CleanTalk