Bug Reports

I am reporting that the issue described in the previous Canny post steam-audio-open-beta#1662 has not been sufficiently resolved. ( https://feedback.vrchat.com/steam-audio-open-beta/p/1662-steam-audio-beta-audio-sources-close-to-head-not-panned-hard-enough ) Specifically, the panning and spatialization of audio sources located in very close proximity to the head remain too weak. The separation between the left and right channels is not distinct enough when the source is near the ear. This lack of accurate spatialization critically impacts immersion, particularly for ASMR content or intimate social interactions where close-range audio positioning is essential. Below is a comparison demonstrating that the issue persists in the current build compared to earlier versions. Reference Videos: Live Build (2025-03-04) - Reference: https://youtu.be/8UoSqduh9Y0 Live Build (2025-12-07) - Current Behavior: https://youtu.be/j3RVQOdXbNo

Chatbox notification sounds are much quieter and easier to miss on Steam Audio. I've been told by multiple people that they didn't realize I was sending messages since Steam Audio launched to Live. I've attached 2 videos showcasing the difference, both the sender and the camera are in the exact same position, and it's clear that the Steam Audio one is quieter. The first video is ONSP (using the un-updated 3p-beta branch), the second one is Steam Audio on Live (build 1768).

After the latest avatar SDK update, the root of the avatar jitters in 3-point tracking. This is affecting all the objects outside the humanoid armature. The jitter goes away if the avatar goes to the crouch mode, or if "Use Auto-Footsteps for 3 and 4 point tracking" is disabled in the VRC Avatar Descriptor. I tried to capture the behaviour using a fresh unity project (created with VCC) and the default pilot avatar, with a cube in the root as a place holder. https://drive.google.com/file/d/14VpjrsixiTsqfLtDAZFJlDIM4FOj7ZBf/view?usp=sharing

If a physbone is moving into a collider due to sufficient pull or gravity it'll very noticeably jitter. This is an issue with the latest physbone changes. SDK 3.8.1: SDK 3.7.6:

It shows 27 Friends contributed, but in the contribution list is only myself.

The number of animation layers heavily affects performance due to unnecessary inverse kinematic calculations. Even blank animation layers with zero weight in the FX layer can trigger this behavior. The offender is seen in the profiler as Animators.IKAndTwistBoneJob. It runs as many times as the currently loaded animation controller with the largest number of layers. Although the individual run time is small, they very quickly add up. Slower CPUs seem to be more adversely affected by this. The time taken by these extraneous calculations quickly grows larger than all normal animator activity. This behavior only happens on animators that have a unity avatar/armature. When that is removed, this behavior goes away and the number of layers ceases to be a significant cause of lag. Most FX layers do not have any interaction with the armature, so it is likely that this behavior can be fixed for almost all FX layers. However from debugging the unity editor in visual studio, it appears the this happens in a native unity function named Animator::UpdateAvatars. It is likely that in most if not all cases, these calculations are completely wasted on FX layers and provide no benefit at all while consuming significant amounts of main thread time. Somehow these calculations need to be only run for layers that require them. Additionally providing a way to get parameters in sub animators would allow logic to be moved out of the main animator completely sidestepping this problem. They would not have a unity avatar associated with them, so this problem would not occur. It would also allow completely disabling animators when not in use. Please attempt to find a way to prevent this behavior or consider convincing your Unity contacts to implement a fix. This seems to be one of the largest contributors to animator lag. I have a full write-up with more profiler images and further explanations. https://docs.google.com/document/d/1SpG7O30O0Cb5tQCEgRro8BixO0lRkrlV2o9Cbq-rzJU

I have a racing world where AI cars are navmesh agents for the person starting a race, and synced objects for other players. There are no scripts running on them for other players, it is just their position that is being synced. When they are close to other players, they will appear to stutter back and forth. The more players in the world, the more they will stutter. When in the distance, they do not stutter at all. This is a new problem, it was not happening in prior builds of VRC. See attached movie (sorry for the dual audio, I have 2 clients open to test) https://drive.google.com/file/d/11qZxBNN0RVzjA9Z0uStS0s3DAFjuin9m/view?usp=sharing *UPDATE This appears to be tied to framerate. If I lock my FPS to 60, I do not see the problem, but if I uncap it and hit FPS much higher (120+ etc), the stuttering occurs. It appears that the objects being synced are only reporting their position at 60fps with no interpolation to account for users running at higher framerates. It is probably not noticeable when things move at slower speeds, but in instances like my racing world, the difference between 60 and 120+ will be obviously cause a stutter when objects have a velocity close to 100 and you also do while moving right next to them! *UPDATE 2 This only happens if I use my monitor with a 60Hz refresh rate, then uncap the the framerate. If I use my Valve Index at 120 or 144Hz with an uncapped framerate, I will not get any stuttering on objects that I do not own that are moving using ObjectSync as my FPS will rarely get higher than the refresh rate of my headset. So ObjectSync is tied to the Hz that your display is when the game launches, or probably FixedUpdate in some way? This is why I see stuttering when running my world FPS uncapped on my display at 60Hz.

Scale both yourself and another person down to the smallest. Try talking to each other, especially when standing near the left or right ear. The other player's voice will sound super loud and crunchy/peaking. A great example of this is any of the booths in Vket that use Udon to scale avatars down when inside. Tested on live 1768.

The new debug UI introduced with 1768 is unusable with vive wands because trigger is Grab for us. It picks up the UI when we attempt to interact with it. If possible, grabbing the UI should use the Drag SteamVR Action since this is bound to the grips on controllers.

there are multiple ways. QM > Report > User > choose any reason > click into the text field > click on the background Another happens somehow when i was closing the menu from reports (i think). When later on re-openeing the menu i saw a message at the bottom for a second I think it said "Invalid ID" or "Invalid Report ID" (not sure anymore). In my logs i found this: > 2025.12.06 04:24:33 Error - Unexpected PushPage MenuReport before SwitchToRootPage calls after menu Canvas_MainMenu(Clone) was reopened. Please navigate to a root page first!