sound_postmortem - ryzom/ryzomcore GitHub Wiki


title: NeL Sound Postmortem (2001) description: Postmortem of the NeL sound library after the Ryzom demo — 3D audio, ambient zones, priority system, performance issues, and future plans published: true date: 2026-03-15T00:00:00.000Z tags: editor: markdown dateCreated: 2026-03-15T00:00:00.000Z

Translated from "fr 2002 sound postmortem" — a postmortem written by Olivier Cado ([email protected]) on 18 September 2001, evaluating the NeL sound library after the Ryzom demo. {.is-info}

1. Positive Points

1.1. 3D Sounds

The position of 3D sources is well perceived, both with headphones and with a 5.1 reproduction system.

1.2. Ambient Sounds

Crossfades between zones work well. Ambient sounds can be dynamically selected from a preset (e.g. day, night). Punctual sounds were used in the demo for root creaking sounds.

1.3. Priorities

When the number of sources exceeds the polyphony limit, the highest priority sources (based first on their priority then on their distance from the player) are played.

1.4. Spawn

A feature was added well after the specification phase to create temporary sources that are automatically removed when they finish playing. This greatly simplifies the use of the sound library in the particle system and in the client.

1.5. NeL Misc Conveniences

Thanks to the serialization system (IStream), it was simple to ensure backward compatibility of NSS files. The user interface / implementation split is beneficial. The CPath class was also put to good use.

2. Negative Points

2.1. Features

2.1.1. Distance Culling

Sound Designers regretted the lack of the ability to cut a source when the player moves beyond a certain distance, which was particularly noticeable in the city in the Ryzom demo. The OpenAL specification explains its absence:

"With the DS3D compatible Inverse Clamped Distance Model, AL provides a per-Source MAX_DISTANCE attribute that can be used to define a distance beyond which the Source will not be further attenuated by distance. The DS3D distance attenuation model and its clamping of volume is also extended by a mechanism to cull (mute) sources from processing, based on distance. However, AL does not support culling a Source from processing based on a distance threshold.

At this time AL is not meant to support culling at all. Culling based on distance, or bounding volumes, or other criteria, is best left to the application. For example, the application might employ sophisticated techniques to determine whether sources are audible that are beyond the scope of AL. In particular, rule based culling inevitably introduces acoustic artifacts. E.g. if the Listener-Source distance is nearly equal to the culling threshold distance, but varies above and below, there will be popping artifacts in the absence of hysteresis."

See Future Plans.

2.1.2. Ambient Zone Geometry

The Ryzom demo showed that the chosen hierarchical structure could be insufficient. For example, a staircase lies between two zones (the city and the agora). To represent it, the staircase had to be included entirely in the city zone. The fountain square could have benefited from a "transparent" ambient, because we wanted to hear the bar from the square while having a different wind sound from the rest of the city (the problem was worked around by making the entire square, except the fountain, a transition zone, mixing the square's ambiance with that of the rest of the city). See Future Plans.

Furthermore, the shapes currently allowed for zones are the sphere (the transition zone is then a sphere with the same center, which implies a very simple crossfade calculation) and the axis-aligned box (the transition zone is then a box enclosing the first, with an arbitrary center). Other shapes would complicate the crossfade calculation.

The geometry of the Fyros city sometimes caused problems (for example, the bar's cluster extending into the adjacent street).

2.1.3. Ambient Sound Specification

Ambients allow playing a random sequence of looped sounds with crossfades between them. This feature did not seem useful in the Ryzom demo. Each ambient contained only a single looped sound (apart from the optional punctual sound added on top).

Sound Designers would have preferred the ability to layer sounds simultaneously rather than play them in sequence.

2.2. Bugs

Some sources are stopped unexpectedly. For example, certain footstep sounds are not played or are cut short. This would normally be expected if the number of sources exceeded the polyphony limit, but it happens even in other cases. It appears that a physical source stops playing and transitions to the STOPPED state before the sound's duration has elapsed, for a yet undetermined reason. This bug has only been observed in "spawn" mode.

2.3. Performance

The fireworks display revealed the performance limits of the sound library. Profiling the client during the fireworks shows the following weak points:

  • CAudioMixerUser::redispatchSourcesToTracks() (3.9%, of which 60% is in enterTrack() which "fills" a physical source with the properties of a logical source: the alSource3f and alSourcef calls are slow). This method is called in CSourceUser::setPriority() / CAudioMixer::createSource(), giveTrack(), releaseTrack(), update() (but very rarely in the latter), when the total number of sources exceeds the polyphony (32); this is permanently the case during the fireworks.
  • alSourcePlay() (3.2%, averaging 2.8 ms/call) and alSourceStop() (1.4 ms/call).

The particle system spawns sources frequently, which has the effect of creating a logical source (cf. CAudioMixer::createSource() above) and playing it (cf. alSourcePlay() above).

In the immediate term, it would be useful to minimize the number of calls to redispatchSourcesToTracks().

2.4. Sound Designer / Developer Interactions

We encountered the following problems:

  • Mac/PC compatibility (filenames, defective file exports).
  • Confusion of time units (second.centisecond vs. second.frame where a frame is 1/30 second (video standard)).
  • Tools not yet fully functional, frequent version changes.

2.5. Data and Code Version Management

The absence of a CVS or AlienBrain-type system for data led to chaotic storage. Fortunately, little time was lost on this. However, the NeL distribution system seemed heavy.

2.6. OpenAL

OpenAL is a specification. While the specification itself is documented, the existing implementations are not (missing features, etc.) (although the OpenAL newsgroup provides relevant answers). I observed differences in header files between different versions (Linux, Windows) requiring the creation of special cases, and the file formats recognized by ALUT differ. Furthermore, the Windows version of OpenAL provided by Creative Labs did not work correctly, unlike the one obtained by compiling the Windows version from the Loki Games CVS.

2.7. Time Management

Bugs and performance issues were discovered at the last moment, while I was working on networking for almost the entire last week.

3. Future Plans

3.1. Graphical Interfaces

Ideally, Sound Designers should be able to adjust levels directly from the client itself.

3.1.1. NSS Builder

  • Multiple selection to modify properties of several files at once (like the Settings dialog in Visual Studio).
  • New sound parameters: ADSR envelope shape, multiple sounds.

3.1.2. Tool for Building Ambient Sounds (and Effects)

  • For the demo: C++ macros
  • In progress: generator from configuration file
  • Ideal: graphical interface (3ds Max plugin for placement)

3.2. File Formats

Support for compressed formats (MP3, Ogg Vorbis, ...).

A file naming convention also needs to be established to avoid having to rename thousands of files at the last minute.

3.3. Streaming

Instead of loading all buffers into memory at startup (each buffer sized to the sound it contains), use background loading.

3.4. Ambients

It would be useful to add the ability to create "transparent" ambient zones, i.e. zones in which the ambient is played in addition to those of the parent zone (cf. Negative Points, Ambient Sound Specification).

3.5. Environment Effects

Provide Sound Designers with adjustment capabilities (ideally from the client itself) to choose EAX effects. Verify whether these apply to all sources or only to 3D (mono) sources.

Future: support for EAX Advanced HD (at the time, OpenAL only supported EAX 2).

3.6. Occlusion / Obstruction

Using EAX.

3.7. Distance Culling

See Negative Points, Distance Culling.

3.8. Hardware

Evaluate new sound cards: Creative Audigy, Nvidia nForce, to see what additional capabilities they provide and what the limitations of the next generation of cards will be.

⚠️ **GitHub.com Fallback** ⚠️