Smooth Playback For C-3PO Animations

Thanks - nice project! The stutter/repeats you’re seeing are almost always caused by one (or more) of these:

• multiple skills/scripts competing to play the same EZ-B audio stream
• WiFi / EZB communication latency (IoTiny is WiFi only) or a flooded comm channel
• audio not converted/streamed in the format the EZB expects (causes buffering)
• a script or Soundboard Track script that’s accidentally retriggering playback (looping)

Below is a troubleshooting checklist, fixes that have worked reliably for C3PO style audio+animation projects, and a short debug script you can run in ARC to help identify what’s happening.

Important references

• EZB IoTiny docs: https://synthiam.com/Support/Hardware/EZ-B-IoTiny
• Output Audio from EZB skill: https://synthiam.com/Support/Skills/Audio/Output-Audio-from-EZ-B?id=15929
• SoundBoard (EZB) skill: https://synthiam.com/Support/Skills/Audio/SoundBoard-EZB?id=16060
• Slow Performance troubleshooting: https://synthiam.com/Support/troubleshooting/slow-performance

Stepbystep checklist (most common least common)

1. Make sure only one skill is actively sending audio to the IoTiny

• The EZB can only play one stream at a time. If you have both the Output Audio skill and SoundBoard trying to play (or multiple Soundboard instances), they can conflict and cause repeated segments or restarts.
• Pick one: either use SoundBoard (recommended for many tracks) OR Output Audio (recommended if you want to preload a single track into project STORAGE). Disable/remove the other to test.

2. Use the SoundBoard Track Editor (if using SoundBoard)

• Import the preconverted WAV into SoundBoard. Confirm the Skill’s Board Index is set to your IoTiny EZB.
• Avoid adding timestamped scripts that re-trigger the track start unless intentionally needed. If you do need scripts, test with them disabled to confirm they’re not retriggering playback.

3. Reduce WiFi / EZB comm contention

• IoTiny is WiFi; heavy EZB read traffic or tight loops can block audio streaming. See "flooded comm channel" in the Slow Performance doc. Actions:
  • Turn off camera feeds, other sensor polling, or duplicate ADC/Ultrasonic read skills during audio playback.
  • Search your project for ControlCommand() calls that might be frequently invoked and add sleeps or rate limits.
  • Add sleep() to any loops that poll EZB ports (avoid tight loops). Example: sleep(100) in loops.

4. Confirm no scripts are retriggering playback

• Check project for:
  • Scheduled scripts or events that call controlCommand("Soundboard v4", "Track_xxx") repeatedly.
  • Sound servo settings that may be issuing playback control commands on every audio frame.
• If you want the animation to follow audio but not trigger new playback, use the "ignoreScript" option when calling Track (controlCommand("Soundboard v4","Track_0","ignoreScript")) or revise the trigger logic so the playback start is called only once.

5. If you use Sound servo or servo animation tied to audio

• Limit how often the servo animation script polls audio position. Use a global variable driven by one reader instead of multiple skills polling the EZB.
• Smooth servo motion: lower frequency of position updates and/or interpolate positions to avoid big servo jumps that may appear like stutter.

6. Try a direct test (no animation)

• Temporarily disable all other skills and only run SoundBoard (or Output Audio) and the IoTiny connection. If audio is clean, that tells you another skill was interfering.

7. If audio still stutters, try different WiFi mode / location

• If IoTiny is in Client mode on a busy WiFi network, try:
  • Connecting PC and IoTiny to the same router / reduce traffic, or
  • Use AP mode (direct PCIoTiny) to eliminate router hops/interference as a test.

Quick debug script (JavaScript) - monitor whether ARC/EZB thinks audio is playing

• Paste this into a Script control and Run. It prints audio state every 250ms and helps reveal unwanted restarts.

// Debug: prints EZB audio playing state and the $EZBPlayingAudio global
while (true) {
  // Audio.isConnected() checks the EZB audio device
  var connected = Audio.isConnected() ? "connected" : "not_connected";
  var ezbPlaying = getVar("$EZBPlayingAudio", "false");
  var isSpeaking = getVar("$IsSpeaking", "false");
  print("Audio: " + connected + " | $EZBPlayingAudio=" + ezbPlaying + " | $IsSpeaking=" + isSpeaking);
  sleep(250);
}

What to look for:

• Rapid toggling of $EZBPlayingAudio or $IsSpeaking - indicates a script restarting or stopping audio.
• If audio is stable on this test while other skills are off, re-enable skills one at a time to find the offender.

Preload into Output Audio skill (recommended if you want best reliability)

• Add the Output Audio from EZB skill to your project, click Load Audio, select the converted 8bit mono WAV, then use its Play to confirm. This skill stores compressed audio into the project storage (reduces onthefly conversion and disk reads).

Questions to narrow it down

1. Is the IoTiny connected as AP mode (direct) or client (on your home WiFi)?
2. Do you have any scripts tied to SoundBoard Track timestamps or any ControlCommand() calls that start playback?
3. Can you try the "only Soundboard + IoTiny" test (step 7) and let me know if the stutter still happens?

I believe the issue you're experiencing with the IoTiny is Wi-Fi interference. While we're unable to see your video because it's either removed or not public, audio playback is generally unstable when wifi transmission is poor.

This support document should help quite a bit: https://synthiam.com/Support/troubleshooting/Audio-Playback-Issues

We'd recommend hardwiring the controller to the computer if this is in a Wi-Fi-saturated environment. But the IoTiny is not capable of hardwiring USB/uart mode like the EZB v4 or Arduinos. If possible, consider using an Arduino or an EZB v4 and using the Sound Board v2 (PC) instead of the EZB audio.

At least, based on your post, we're guessing you mean the Sound Board (EZB) that you're using because there is no robot skill titled "SoundBoard v4". If you can add information to help clarify, we can get you running quickly so C3P0 can spread holiday cheer.

Let us know, and we'll get C3P0 rock'n to holiday classics.

I have a suggestion that may help clean up your transmission over a cluttered WIFI environment. I know the following is possible within the EZB v4 interface but not sure if the IOtiny has this capability. You'll have to get in there and find out.

Anyway, when you log into the EZB interface through your internet browser look in the WIFI section. Hopefully you'll see a dropdown window list that is called Channel. Here you can change the channel your EZB (and hopefully the Iotiny) run on to a less crowded channel. Most devices are preset to the dame channel from the factory (most of mind are set to channel 11).

To actually find a clean channel you can download a WIFI analyzer for you phone. When you run that app you can see what the WIFI signals are showing that you and your close neighbors are connected to and using. Your app should also be able to show the different channels everyone is running on and which ones are less congested than others. Simply switch to a cleaner one.

Good suggestion, @Dave - the suggested support document from Synthiam Support includes a wicked WiFi tool in Step #2 on that page. There's a tool we're always getting people to use that shows all the wifi networks and their signal strength. I use it to sort by strength and look at channels that aren't being used.

Check suggestion #2 for the Wifi scanner program here: https://synthiam.com/Support/troubleshooting/Audio-Playback-Issues