Attaching audio and maintaining quality?

[Frankie Rockett]

Hi All
I currently have an audio file (cut as required into plenty of 9.9 sec long pieces!). If I play it in-world and fix my camera up close to the object that contains it, I get the best audio experience. That is - loudest volume. However I would like the object with the audio to attach to the avatar and maintain the best possible volume as the avatar walks around. Think 'museum audio guide' kind of function. While I have it all working - triggered by wearing, I find two undesirable and very disappointing effects:
1) as soon as the avatar walks, pulling the camera back and above the avatar, the volume drops off markedly, as we distance our view from the Av and it's attachment a little. Attaching to the HUD is no better, for while it doesn't make the volume rise and fall, it's pitched at some mid-way point - a lot quieter than camera-ing close on the attached object.
2) I notice that the sound seems tied to a particular place. If I 'teleport to click position' in a region, I leave the last 9.9 second portion of audio back where I was standing, and it's not till the next 9.9 section piece enters that the volume returns.

All in all the audio seems like a mess! Is there any way or ideal attachment point that I can play the audio constantly at maximum achievable volume )for any given viewer-volume setting)?

Thank you!

[Quistess Alpha]

1 hour ago, Frankie Rockett said:

I notice that the sound seems tied to a particular place. If I 'teleport to click position' in a region, I leave the last 9.9 second portion of audio back where I was standing, and it's not till the next 9.9 section piece enters that the volume returns.

That sounds like you're using llTriggerSound rather than llPlaySound. Play sound moves with the object that starts it, TriggerSound magically stays in place if the object moves away.

[Fenix Eldritch]

It's always a good idea to reference the LSL wiki pages for the functions you're using, as they usually explain any peculiarities about them - with llPlaySound's attached vs llTriggerSound's unattached sounds being one example.

A small tangent, but you may be interested to know that it's planned for sounds to no longer be limited to 10.0 seconds in length. Very soon you'll be able to upload sound files 30.0 seconds long. It was supposed to be on the RC channels this week, but that got rolled back.

[Frankie Rockett]

Thank you both Quistess and Fenix. Quistess, it sounds (definitely no pun intended) like llPlaySound will conquor the movement effect I was seeing/hearing. Do you think attaching it anywhere in particular will maximise the sound volume? That was my main hurdle here.

[Quistess Alpha]

4 minutes ago, Frankie Rockett said:

attaching it anywhere in particular will maximise the sound volume?

llPlaySound from a HUD should in theory work 'the best' in terms of volume, but would only be hearable by the person wearing the HUD.

[2Tessa]

The camera is your ear inworld, so you may make a phantom object strictly following the camera (need constant updates of its position). This may become a script load on the server. You need a remote control to stop it because once an object follow your camera, will become impossible to be seen and selected, unless your camera move out of the sim borders that the follower object is unable to cross.

[Frankie Rockett]

On 12/17/2022 at 6:27 PM, Quistess Alpha said:

llPlaySound from a HUD should in theory work 'the best' in terms of volume, but would only be hearable by the person wearing the HUD.

Tessa. Thank you for that tip. Yes I see the problem. I won't go down that road I think.
Quistess! Excellent! This is the answer I've been searching for then. And I tested it and it works well in terms of volume. However, it's intruduced a majot problem.

I notice that the sound slices (each 9.9 seconds long, and I have 27 of them), start to intruduce an audible 'thump' at the join points, which, over time, gets worse, revealing itself as an audible gap before we're half way through the piece. This wasn't happening with llTriggerSound, so I'l guessing it's a llPlaySound artefact (or bug?). I am using llSetSoundQueueing(TRUE); to stop things bumping into each other. I also use LlPreloadSound in a loop, 27 times, omne for each piece of sound. Actually on re-re-testing, since switching to llPlaySound, it now inserts large gaps, say 6 seconds, then re-plays the last section again, then resumes on the last-but-two, threby missing a piece out. It does this consistently. To put that visually, it will be playing say, part 9, then it behaves like this:
part 9
part 10
(silence)
part 10
part 12
...and so on.

Any ideas?
Footnote: I 'may' not be able to respond until the New Year at this point, but I shall follow your thoughts and respond soon!

[Jenna Huntsman]

15 minutes ago, Frankie Rockett said:

LlPreloadSound in a loop, 27

This I've found doesn't work - either the viewer is nuking sounds from cache as they're unused, or the region has a silent cap on preloading sounds. The best way to do things is to set up the script to add a sound to the queue, then call llPreloadSound for the next sound to be added to the queue. With that, you should have ~20 seconds for the viewer to download the sound.

It's also good practice to call llStopSound after all segments complete, as llSetSoundQueueing can cause the region to (erroneously) continue playing sounds, as if they were looped instead of a single playback.