Choppy Audio File Out To EZ-B

Yes - what you’re describing is very consistent with real-time audio streaming over WiFi being interrupted by competing CPU/network load, especially with:

• Camera Device processing at 640x480 @ 15fps
• WiFi audio streaming to the EZ-B v4
• servo/movement activity happening at the same time

What’s happening

Audio File Out EZB streams audio continuously from ARC to the EZ-B speaker. If the stream gets delayed even briefly, you can hear:

• choppy playback
• repeated fragments
• pause/stop behavior
• the log stuck on Streaming: ...

That behavior is usually caused by WiFi congestion, CPU load, or both - not a bad file path or unsupported format.

Best format to use

For the most reliable playback, use:

• WAV
• 16-bit PCM
• mono
• 16 kHz if the voice quality is acceptable

That’s the best starting point for lower bandwidth and lower decode overhead.
If you need better voice quality, try:

• WAV
• 16-bit PCM
• mono
• 22.05 kHz

MP3 is usually worse here because it adds decode overhead on the Rock Pi X before streaming.

ARC-side recommendations

1) Reduce camera load

Your biggest improvement will likely come from the camera skill.

Try these in Camera Device:

• lower resolution to 320x240 or even 160x120
• reduce frame rate to 5-10 fps
• use Processed preview only when needed
• if possible, pause the camera when you’re playing critical audio

You can also use the kebab menu on the Camera Device skill to adjust settings and tracking behavior.

2) Keep movement bursts short

Servo/movement scripts can add timing pressure. If you’re running lots of servo updates, try reducing update frequency or spacing actions out with sleep().

3) Don’t rely on simultaneous heavy tasks

On smaller Windows SBCs like the Rock Pi X, ARC + camera processing + WiFi audio streaming can saturate the system faster than a desktop PC would.

Practical workaround: pause camera while audio plays

If the voice line is important, pause camera processing while the clip plays:

ControlCommand("Camera", "PauseOn")
ControlCommand("Audio File Out EZB", "Play", "c:\\robot\\audio\\hello.wav")

while (ControlCommand("Audio File Out EZB", "IsPlaying")) {
  sleep(100)
}

ControlCommand("Camera", "PauseOff")

If you only want to pause tracking and keep the stream visible, that’s usually the cleanest approach.

If you want cleaner handling, add a small audio queue

ARC can do this with a simple script-driven queue so audio lines don’t overlap. If you want, I can help you write a JavaScript queue that:

• waits if another clip is already playing
• optionally pauses camera tracking during playback
• resumes camera after the clip finishes

About buffering / thread priority

Audio File Out EZB does not expose user-adjustable buffering, queue size, or thread priority settings in the skill UI. So there isn’t a hidden bitrate/buffer knob to tune inside ARC for this skill.

Best overall fix order

1. Switch to mono WAV
2. Lower camera to 320x240 @ 5-10 fps
3. Pause camera during important speech
4. Reduce servo update frequency
5. If possible, use a wired connection for the EZ-B or keep WiFi load minimal

One thing to verify

Since you said the EZ-B is in client mode on your home WiFi, are the Rock Pi X and EZ-B both on 2.4 GHz, or is one of them on 5 GHz?
Also, what exact camera tracking modes are enabled in Camera Device when the stutter happens?

If you want, I can suggest a more robust ARC script pattern for playing robot speech reliably while camera and movement are active.