Chime TTS - Play audio before/after TTS audio lag free

Chime TTS v1.3.0-beta.1 is here! :tada:

I’m excited to announce the first beta for Chime TTS v1.3.0 - Install instructions.

This release is a substantial refresh of the Chime TTS experience, with a redesigned Home Assistant panel, powerful new Chime Sets, improved audio timing controls, and a long list of reliability fixes.

Highlights

  • Chime TTS sidebar panel: Manage chime folders, browse documentation, preview audio, and work with responsive Chime and Chime Set lists.
  • Chime Sets: Create reusable sets of chimes and have Chime TTS choose one at random for more natural, varied announcements.
  • Interactive timing editor: Visually adjust each chime’s start offset with draggable chime/TTS blocks, overlap indicators, a duration grid, reset/save controls, and synchronized playback.
  • Combined audio previews: Preview a Chime Set with the bundled TTS sample before using it in an automation.
  • Per-chime offsets: Save a default start offset per chime, with action- and notification-profile-level overrides when needed.
  • Better notification profiles: Edit profile fields without restarting Home Assistant, plus support for pre_script and post_script.
  • Panel activity logs and replay: Improved grouped logs, warnings/errors for standalone Chime TTS actions, and replay support.
  • New included sounds: “Airport” and “Doorbell” chimes.
  • More robust audio handling: Better support for custom audio files—including uppercase extensions—absolute paths, unavailable media players, playback resuming, external chime downloads, and TTS-provider recovery.
  • Expanded test coverage: New regression, service, filesystem, queue, media playback, panel, notification, and end-to-end tests.
  • Lots of bugfixes

Important

Chime TTS v1.3.0 requires Home Assistant 2024.8.0 or newer.

As this is a beta, please test it with your automations and report any issues, unexpected behavior, or UI feedback on GitHub. Your feedback will help make the final v1.3.0 release solid for everyone.

Thanks to everyone who tests, reports issues, contributes fixes, and shares ideas for Chime TTS!

3 Likes

I reinstalled and configured the beta and it now works with Nabu Casa as well.
However, the default chime from the settings is not used, I have to enter a chime directly for each automation.
The default value for TTS (Cloud in my case) is taken from the settings.

Thanks @HairyPorter23 :+1: I’ll add a fix to the upcoming beta release.

I created a problem but no one is responding to the cause of it. There is actually nothing to configure. I was using an old version which I updated to 1.3.0-beta 1.

@pepe59 there is a new beta release, v1.3.0.beta2 that includes a fix for the UI issues among other improvements and new features.

Thank you very much for solving the problem.
It works perfectly.
I’m closing the issue.

Brilliant :laughing: and just after I recorded my own Doorbell chime.

No seriously, I like where this is going. I use Chime TTS extensively in my speech engine script so I’m looking forward to these improvements.

Glad to hear it :grin:
Let me know if there are other improvements/ideas you’d like to see implemented.

I use the Bells Chime before the TTS. It’s two bell tones, but I only get one.
What do I need to do to fix that?

Without more information I can’t be sure, but I think it’s likely one of two issues:

  1. An issue with generating the combined chime + TTS audio, or
  2. An issue with the playback, where the start of the audio is dropped before the audio is played.

I suggest you use the chime_tts.say_url action to generate the combined audio and play it on your computer. If it sounds ok, it’s likely issue #2.

If the issue is that the start of the playback is missing, you can add a delay segment before the chime, so the dropped part of the audio happens before the chime.

Not sure what else you need… I play Bells. 500 ms delay, then the TTS message

Bells only play one bell tone, not two as it does when play it using the Chime TTS GUI
If add a delay, it occurs after the bell and before the TTS message

chime_tts.say_url creates a file that plays correctly

I had to resort to this nonsense to get it work and play both of the bell tones in bells

action: chime_tts.say
metadata: {}
target:
  entity_id: media_player.raspiaudio_muse_luxe
data:
  tts_platform: piper
  volume_level: 1
  announce: true
  message:
    - tts: e
    - chime: bells
      offset: 500
    - tts: This is a test

Do you hear the same issue in the MP3 file generated by chume_tts.say_url?
Please provide the full debug log messages for the action. Perhaps there’ll be a clue there.

No… the file created by URL played fine on my PC

Nothing in the logs

I note the files starting with tts “e” before the chime sound fine when sent to the Raspi Audio using chime_tts.say; I don’t hear the “e”. If play the cached files on my PC, I hear the “e” . It seems like tts.say is sending the file before the Raspi Audio ready to play so the beginning of the file is clipped.

When I added the “e” that became sacrificial, so the Bells chime played completely, and I heard both tones .
Maybe we need an option to pad the beginning of the mp3 file with some number of mS of silence

As I wrote previously, you can add a delay segment before the chime:

action: chime_tts.say
metadata: {}
target:
  entity_id: media_player.raspiaudio_muse_luxe
data:
  tts_platform: piper
  volume_level: 1
  announce: true
  message:
    - delay: 150
    - chime: bells
      offset: 500
    - tts: This is a test

OK that works now. It didn’t previously
Thanks