JD Audio Stutters While Walking

Yes - what you’re describing is almost always WiFi audio streaming contention, not a JD-specific gait issue.

When JD is walking, Auto Position is sending frequent servo updates, and at the same time Say (EZ-B v4 Speaker) / Soundboard audio is streaming continuously to the EZ-B. On WiFi, those two streams can compete for bandwidth and timing, which causes the stutter / clipping / short gaps you’re hearing.

What to know

• Say (EZ-B) and Soundboard (EZB) both depend on real-time streaming to the EZ-B.
• Auto Position also generates a lot of traffic while the robot is moving.
• The fact that Say (PC Speaker) is smooth confirms the issue is EZ-B audio streaming, not TTS itself.
• There isn’t really a "lower the EZ-B sample rate" setting in ARC that fixes this directly.

Best practices that usually help

1) Use PC Speaker for speech when the robot is moving

This is the most reliable fix if the robot needs to walk and talk at the same time.

• Say (PC Speaker) is rendered locally on the computer, so it does not fight with EZ-B WiFi audio.
• If the phrase must come from the robot physically, then you’ll need to accept some tradeoff on WiFi or use a wired connection if your setup supports it.

2) Reduce how often you send movement commands

If the joystick scripts are firing constantly or repeatedly triggering movement commands, that can add unnecessary traffic.

For the Joystick (Direct Input) skill, check the configuration via the kebab menu (three lines) on the skill window and make sure:

• movement commands are only sent when the stick changes meaningfully
• button press scripts don’t repeatedly re-trigger while held
• any scripts have small sleep() delays if they loop

3) Avoid stacking multiple real-time EZ-B audio features while walking

If you’re walking, try to avoid:

• Say (EZ-B)
• Soundboard (EZB)
• long audio clips streamed to the EZ-B

Instead, use:

• PC Speaker
• or local PC audio files with Audio.playAudioFile()

4) Keep Auto Position transitions efficient

You already slowed the gait, which is good. Also check whether the gait is using more frames than necessary. Fewer, cleaner frames often means less chatter on the connection.

5) Prefer a wired connection for production reliability

If the robot ever supports a wired connection path, that will be the most stable way to do audio + movement simultaneously.

Recommended setup for your case

For the behavior you want:

• Movement: Auto Position Movement Panel
• Joystick control: Joystick (Direct Input)
• Speech while walking: Say (PC Speaker) or local PC audio
• EZ-B audio: use only when the robot is stopped, or accept occasional stutter

Example approach

Instead of:

sayEZB("Let's go!");

use:

Audio.say("Let's go!");

That will keep the speech on the PC audio path, which is much smoother during walking.

One more thing to check

If your button scripts are launching speech on every loop/press, you may be accidentally calling speech more often than intended. If you want, I can help you structure the joystick scripts so:

• left stick controls motion
• A/B buttons speak once per press
• and speech uses PC audio while walking, but can optionally switch to EZ-B audio when stopped

Questions that would help narrow it down:

1. Are you using continuous stick polling scripts, or the built-in joystick mappings only?
2. Do you want the voice to come from the robot speaker specifically, or is PC speaker acceptable while walking?
3. Which JD movement skill are you using exactly - the Auto Position Movement Panel gait skill from the store?

If you want, I can help you set up a clean joystick-to-movement-and-speech script in JavaScript. The ARC AI Assistant can also rewrite this kind of script right inside ARC if you want to try it:
https://synthiam.com/Products/AI-Assistant