Bell Tower - overcoming limits on audible sound falloff?

Is there any way to increase the range of script-played audible sounds, so they could be heard throughout most of the sim? I am trying to build a bell tower with clocks on the top, that will chime the hour with the Westminster clock chimes. I managed to make the tower and the clocks easily enough, and the clocks display the SL time on their analog faces. And I came up with the needed sound bytes to do the chimes, (two ten-second clips plus the "bong" for the hour count) and LSL code to play them at the top of the hour...

But...

The tower is close to 30 M tall, and using llPlaySound to cause the .wav files to play, the sound is already so faint by the time you get to the ground that you can barely hear it! Standing in front of the building that is right next to the tower, I can barely hear the chimes if they originate at the clock face on top. The volume setting is at 1.0, which is the max allowed (Any higher is ignored and treated as 1.0). My client settings are turned up high enough that the rest of the ambient sounds in the area are as loud as I would ever want them to be. Any louder would be too much.

Even if I moved the prim the sound actually originates from to ground level, it appears I would only be able to hear it for a radius of 30 M.

Is there a workaround for this?

(Edit: Realized that this is probably more a question for the scripting tips forum than for building tips, but I can't delete or move this thread. I created a new thread over there, and this one can be deleted. )

Ceera,

Last year I designed the Carillion Chimes at the California Tower in Diegoland. Last summer, I was able to hear the chimes clearly with decient and realistic falloff as the distance increased. Today, it appears borked.

I am now experiencing the same problem as you describe about 25-30 meters and they cutoff. When I origionally set them up, I was consistantly getting a projection of around 90 - 93 meters. It seems that something has changed drastically, I would assume in the client.

I have just started investigating this in the past several days and have yet to come up with an answer. This may be a jira issue, but so far, I have not seen any entry to this.

I only have the Windlight client installed but wonder if it is a problem with the older clients as well.

I recently bought one of Persephone Milk's pianos, and the sound falloff seems to be much more abrupt than I remember when I first saw one. I assumed it was something about my parcel, but perhaps this was changed as part of the spatial voice integration?

Don't know if she uses the same command tho ...

*sigh* Thanks for the feedback, folks. Looks like I'll have to do without the clock chimes for now. Yrrek, since you have an in-world example that demonstrates a changed behavior, I do think you should open a JIRA ticket to see if they will fix it. I'll certainly support it.

I tested with the current Mac client and with the release candidate, and had the same fast falloff. I would agree with the premise that it is something they changed to accommodate audible voice chat.

Ceera,

I am at work but loaded up the 1-18-5-3 client and took a listen at the chimes in Diegoland, they sounded fine at 130 meters. The wind sound was back as well. If you are also using Windlight, the problem may be there.

I noticed you posted this in Scripting Forums and are concerned with the echo. From my experience in Diegoland, it gives a realism to the sound, faded but echoing off the buildings.

Using the 1.18.5.3 (current release) client for Windows, and with all my audio settings maxxed out, both in my OS and in my client prefs, I can barely hear the bells at 30 M away. And that is in a mostly empty class 5 sim. The sound files can't be made any louder without distorting the sound of the bells. They are almost clipping the peaks now when I look at them in Audacity.

Here is the code I am using. Drop this in a prim and when you touch the prim, you'll hear the 12 o-clock chimes. :

// Clock Chime Example script, by Ceera Murakami
// When the prim this is in is touched, it rings the hour of 12 o'clock
// Sound files are the Westmisnster Clock Chimes

default
{
state_entry()
{
}

touch_start(integer total_number)
{
string chimeA = "95a691d0-21c0-21c2-5918-e18ed7e05b2e"; // First 10 sec of top-of-hour chimes
string chimeB = "f5ba3a09-5fa2-d4ac-92bc-4d0000a2e786"; // Second 10 sec of top-of-hour chimes
string chimeBong = "d87217bc-cb47-7d85-c2ea-b0e3d2e40a72"; // a two-second single bong
integer hour = 12;
llPreloadSound( chimeA ); // First 10 sec of top-of-hour chimes
llPreloadSound( chimeB ); // Second 10 sec of top-of-hour chimes
llPreloadSound( chimeBong ); // a two-second single bong
llSetSoundQueueing(FALSE); // Don't wait until sound is done before playing next sound
// Play the top of the hour bells
llPlaySound(chimeA,1.0);
llSleep(10);
llPlaySound(chimeB,1.0);
llSleep(10);
integer i = 0;
for (; i < hour; ++i) // Loop for the number of hours
{
llPlaySound(chimeBong,1.0);
llSleep(2.0);
}
}
}

I am beginning to think something else is going on here. Diegoland is a class 5 sim and was totaly empty when I tried the chimes with 1.18.5.3. In fact I pulled up the map and placed a beacon at the tower and kept pulling away until the chimes were lost. About 130 meters. When I first set this up, about 93 was the farthest I could hear them. It just may have been a fluke that it worked so well for me today. I can not duplicate the test with Windlight until this evening but will load the current version and test both again tonight.

Don't be afraid to allow clipping. Depending on the quality of the chime, you might just be able to get away with it.

Well, I will make a new set of louder chimes tonight in Audacity, and see if that helps. I have a nearly idealized place to test - a Football stadium that I am just finishing construction of for Rutgers University, in a new class 5 sim. I can place my test prim on the goal line, and walk down-field to where the sound fades to nothing. The gridiron is scaled to use 10 M in SL measured space for each 10-yard marking on the playing field. So I can directly read the exact distance just by looking at what line I am at on the field.

Ceera, just do as I do and make a beacon on the map then minimize it. You can fly all over and still see the distance you are from the beacon. Eazy Peazy, lol.

There is an event going on right now in Diegoland, can't distrub them with constant chiming.

Amplifying the sound files to the point where they were something like 40% clipped didn't affect the falloff in the slightest. Up close it was loud, and distorted. 30 M away, it was barely audible at all.

That is not surprising me, the more I fool with this problem, the more I am confused. You did not notice much difference in the chimes with the clipping tho, right?

I put your script in a prim next to mine and triggered them at the same distance. Mine covered 3 times the distance as yours most of the time. Another using the sound files in the inventory of the object instead of the UUID, did not work more than 20 meters from the source. This is a big concern as to the fact that I have another commission and am not sure why things work. Beginning to think it is serverside.

Ceera, I tried your script on my building platform (for the grid ). Class 5 sim, nearly empty, 600m up. All volume sliders maxed AND the volume set to max in Windows as well. The sound fell off quite gradually until 30 meters, at which point it seemed to snap off. Tho it was VERY quiet at 29 meters already.

I played with the rolloff and distance sliders then. I experienced some distortion but no difference in the max distance.

I also played with whether the prim was near another object or not, wondering about some sort of sound occlusion. Didn't seem to make a difference.

And my piano is really SOOO quiet.

Oh btw, that was with a really old (but still voice) client, Nicholaz BE-R, which is based on 1.18.3.5

The only thing I noticed with the amplified and clipped version of the bells was that they sounded worse. The volume level was identical, even though when played externally as .wav files in Audacity, the amplified/clipped version was louder.

And I had initially tried it with the sound files directly in the prim. the behavior was the same as when I later used UUID's.

IT IS RELATED TO PRIM SIZE!

If you drop my script into a default 0.5 M cube, the sound only travels 30 M, *at which point LOD changes make the prim cease to render*! The sound cuts off just as the prim vanishes.

I expanded the same prim to a 5M cube, and can hear THAT from 125 M distance!

Shrunk it to a flat 2.5 M x 2.5M x 0.010 thick clock face, and it still worked at 125 M.

Conclusion. If the prim is far enough away for LOD to clip it, you can't hear it either.

doh, that helps... and I guess we should've realized since even though it triggers by script it's treated as being sourced to the prim... client doesnt register prim, client doesnt register anything that comes from the prim... mostly (says and instant message seem to be completely passed to the sim, you'd think sounds would be too, but I guess they're lumped in with prim properties) Been watching this because I seemed to remember it coming up LONG ago (like 2+ years) but just figured it was one of many changes since then... my clock just got an upgrade, thanks Ceera =)

Oh, that is ugly. The sim is probably still telling your client the prim made a sound, but the client has been instructed to forget the position of the prim the sound is attached to.

Unlike llPlaySound, llTriggerSound would generate a message that includes the position of the sound... maybe it would still work even when the prim is clipped?

Confirmed, llTriggerSound will work when the prim is clipped (:

That would explain everything working in the past. They have been messing with LOD since the introduction of sculptys.

I am not sure if I would have ever figured this out. I have been setting my draw distance higher during my testing and of course could still see my prims.

Would it be possible to force the distance with llTriggerSoundLimited?

Ahhh. Great detective work, Ceera! *claps*

Maaaan, tho, that is unintuitive. I wonder if anyone at LL has thought about it? I don't really see why sound falloff should be linked to LOD, particularly when there are "Distance" and "Rolloff" controls in the audio preferences. Jira enhancement request, perhaps? How do you guys think it SHOULD act?

And I wonder if the sound script for my piano is in its (unlinked) rezzer prim, which I think I may have made smaller when I moved it? hmmm.....

I've been a programmer for more years than I am willing to publicly admit being alive. *smirk* So the challenge of debugging what was going wrong was intriguing. I'll experiment with llTriggerSound. That may be more proof against the prim getting LOD clipped.

I agree, great work. Yes this is definately a Jira issue. What next, Object Occlusion = no sound? Maybe that is why there is no wind in Windlight. You can't see the wind, lol.

Yes Ceera, you have the honors to Jira, I have the honor to vote for it.

/me can't wait to get off work and try it.

llTriggerSound must help, that is what I have been using all along, thus slightly different results or more like, inconsistant data.

Thank you all for your help and inspiration. My new clock script should be in the Library shortly, as "Ceera's Westminster Clock". My version makes a three-prim clock that auto-regulates to SL time within less than one minute of being rezzed, and chimes the hour with the Westminster clock chimes. The chimes can be silenced by commenting out two lines of code. It has no open listens at all, and should be very low lag.

An example of the clock itself can be found in the NE corner of the "HHP at UH" sim.

Still working on a JIRA report for the sound falloff issue. The results are VERY inconsistent as far as what distance the sound can be heard at. Definitely a bug in the way SL is handling audible sounds from prim scripts. I got the same results with both llPlaySound and llTriggerSound.