Alarm annunciation

[shroffk]

I need to make the alarm annunciator a bit more configurable.
Instead of speaking out the alarm I need to play notification sound/s...

The simplest solution would be to add some preferences and extend the Annunciator to have a AudioClip/MediaPlayer to play some sound file set in the prefrences.

Another way to do this would be the use of SPI so that the Annunciator becomes an implementation of an interface with a speak(AnnunciatorMessage message) method that can be implemented to satisfy different use cases.

@kasemir @tynanford any thoughts?

[kasemir]

The current implementation based on FreeTTS is clearly not optimal.
FreeTTS is somehow using the AWT event pipeline, whereas CS-Studio used SWT and now JFX, which can create all sorts of hangups. FreeTTS has not been updated for a long time (14 years ago??, https://en.wikipedia.org/wiki/FreeTTS). I could only get the "kevin16" voice going, all the others were worse or dysfunctional.
Having an update, maybe a pluggable mechanism, would be good.

In the Eclipse implementation, wasn't there a way to select between pluggable implementations. Vaguely remember one was sending the text as UDP packets, because one site had a tool which turned those into speech.

Or, since we are using Kafka, you could simply not run the annunciator in the GUI but write your own annunciator service that subscribes to the Kafka 'talk' topic and turns that into speech or any other type of sound.

[shroffk]

Having an update

I was looking into this, the best/newest solutions I could find were calling the google translator or and AWS service which require user accounts.

maybe a pluggable mechanism, would be good.

Ok, maybe it is worth use SPI then.

Or, since we are using Kafka, you could simply not run the annunciator in the GUI but write your own annunciator service that subscribes to the Kafka 'talk' topic and turns that into speech or any other type of sound.

Sure, we can argue for the annunciator to be a stand alone service... in fact we can expand the scope to a notifier where the stand alone service has a pluggable interface for you to annunciate, play a sound, make a call, send a text, call the fire dept.

[kasemir]

solutions I could find were calling the google translator or and AWS service

Right, you clearly want something local in the control room, not call out to a cloud service.
On the Mac, you get a "say" command line tool that sounds very good. For Linux, "festival -tts" is also better than the FreeTTS voice. I'd rather not launch them as external processes from with the Linux GUI, though, but leave that to for example a python-based background service.

[tynanford]

Having a standalone service means we lose out on a few perks like the alarm annunciator working with the memento/layouts and requires future people to figure out this is a separate thing they need to install. So IMO that's the less ideal solution. But also a workable solution for us if it isn't feasible in phoebus

[georgweiss]

My users have expressed concerns that with multiple workstations in the control room using the Annunciator with different alarm configurations, a call-out may or may not be of interest. While I'd say this is not really a software problem, it would be beneficial if a call-out would include the id of the alarm configuration. I'd guess our friend kevin16 might have some difficulties here.

I'm fine with a dedicated annunciator service to provide audio streams, in particular if we could chain multiple audio files into a single call-out, e.g. "three + active alarms in configuration + foobar". Regarding Python: I'd be prepared to implement a service in Spring Boot, even at a personal cost.

[shroffk]

Ok,
So to address @georgweiss use case, if I make the "speaking" part of the annunciator pluggable then ESS control room Phoebus can include a different implementation of the annunciator which adds the missing parts (you could add the multiple audio files, etc...). The ALS Phoebus will play a sounds. The NSLS2 Phoebus will just sign and quietly express disappointment at the state of affairs.

I really REALLY dislike the idea of having to use a cloud service...If anyone knows of any other (non OS specific) standalone text-to-speech I would volunteer to implement that.

As the next step I will have a PR with an SPI based pluggable model for annunciators and work with ALS and ESS to add their specific implementations.

[georgweiss]

As for ESS... my idea is merely an idea and not urgent at all. Whatever changes, I assume current implementation will stay intact. In any case, a cloud service will not fly with us.

[beherste]

I don't have any experience with using it, but there is Piper which is used by Home Assistant:

Github Repo: https://github.com/rhasspy/piper

Sounds Samples: https://rhasspy.github.io/piper-samples/

Not sure how cross-platform it is, but people have got it working under Windows: https://www.reddit.com/r/Windows10/comments/16w3xic/piper_texttospeech_in_windows_10/

FRIB is also firmly in the 'no cloud service' camp.

[kasemir]

The samples sound very good.
Looks like we have several examples for annunciating text by calling an external program.
They all sound better than the FreeTTS java library.
For Mac OS it's say, on Linux it's festival -tts or piper. https://stackoverflow.com/questions/1040655/ms-speech-from-command-line lists some options for Windows.

Operationally, a background service has advantages over the annunciator GUI. While it's easy enough to start the annunciator GUI, operators need to remember to start it, exactly once. With a background service, you configure that to run on a dedicated alarm computer in the control room, and that's it.

Technically, it should be pretty easy to cook something up in python that subscribes to the Kafka ..._TALK topic and calls a configurable external program. Could also be done in Java, but I've been burned by then either not capturing the error output of the external process, or hanging on for too long and ending up with a growing memory footprint.