Looping a sequence of sounds; how to tell duration?

[Qie Niangao]

It's been ages since I've done anything with llPlaySound(), so maybe I've forgotten an easy way to do this.  I have several sounds to play in sequence and then the sequence must repeat in a (more or less) infinite loop.

I think I've got the timer logic correct, using sound queueing and preloading and playing, but because the queue is only two sounds deep, the reliability of the sequence being preserved over many repetitions without gaps depends on my having a fairly accurate measure of how long each sound lasts.  I can't think of a reasonable way to figure that out short of measuring with a stop watch.  (These are sound assets acquired in-world, not made by me.)

I swear, back when I used to do sound stuff, I used to be able to watch the console and get a record of when a sound started to play.  The timestamps were probably only one-second resolution, but with enough repetitions I could get enough precision using that.  But I sure can't figure out how to turn on that sound debugging in the viewer now.  (I've looked at both Viewer 2 and Snowglobe.)

If I turn on network message logging, I can see AttachedSound messages in the console, but they aren't labelled and they seem to be far too numerous to correspond with the start of each sound I'm really trying to play. 

Am I overlooking something, or do I just break out the stop watch?

[Rolig Loon]

It's easiest if you create the sound files yourself, of course, because then you can create them to precise lengths that you planned ahead of time.  If you can't grab the sound on your machine and direct it into an editing program to measure its length, then I think it's stopwatch time.  You ought to be able to get pretty close, especially if you do a dozen measurments and take the mean,

[Void Singer]

a gesture may be more reliable for getting time... I'm not aware of any displays that show it, but I don't do much sound work, and pretty much avoid doings sequenced stuff.

[Helium Loon]

If you have a close approximation to the total sound length of the elements, llSetSoundQueueing() may be the simplest way to get it to work, like you said.  Although it only allows two sounds queued currently (there is a JIRA in place to increase the queue depth), if one does like this (this assumes the sounds are at least several seconds long each....)

 

llPreloadSound("Sound1");

llPreloadSound("Sound2");

llSetSoundQueueing(TRUE);

llPlaySound("Sound1",1.0);

llPlaySound("Sound2",1.0);

llSetTimerEvent(sound1duration+sound2duration-0.5);

 

Then in the timer() event, have it play the next sound in sequence and set the timer to the next duration.  That way, the queue should always have room for the next sound, and each should start immediately after the prior one.

 If this is what you are already doing, and you are still getting issues, you'll probably just have to use your own sounds that you create to specific durations you know precisely.  And you may still get issues as timers are affected by sim time dilation.....

 

[Qie Niangao]

Yeah, that's pretty much precisely what I'm doing.  (The main difference is that I only llSetSoundQueueing() in state_entry.)

If I were musician enough to make the sounds this thing is supposed to play, I would.  I'm reasonably confident of the IP provenance of the sounds because of recording artifacts (or at least it wasn't ripped from a commercial source).

Good point that this will drift some with dilation.  Now that I think about it, I may put in a slight additional pause before looping the sequence because a short gap there would be better than having the playback overrun real time so much that a  sample gets skipped occasionally.

Anyway, thanks for the answers.  I guess I'll make a quick and dirty script that loops each sound file, I'll measure time elapsed after I've heard 10 reps, and divide that time by ten.