add some level of ssml support to `module_strip_ssml`
- Dominant language
- C
- Stars
- 331
- Forks
- 92
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 9
Description
**Is your feature request related to a problem? Please describe.**
The SSML tags that clients send to speech-dispatcher are completely ignored for output modules that don't support them.
**Describe the solution you'd like**
`module_strip_ssml` could be extended to support some of it. Notably:
- `break`: we can easily produce silence for the requested duration
- `voice language/name/etc.`: to switch voice on the fly
- `say-as`: to switch spelling/etc.
The idea could be to introduce a `module_handle_ssml` function that returns an array of speech messages, that the `module_speak` function can then iterate over.
Or probably better: the processing could be done on the server side, which would require making modules tell whether they support ssml or not, see #904
This could be done in `speaking.c`'s `speak` function which, after selecting the output module, could realize that it doesn't support ssml, and in that case split the ssml message into several pieces with differing parameters, and put back respective messages on the queue from which the message was obtained.
The implementation could be intermixed with support for multilinguilization (#372).
Contributor guide
No contributing guide indexed for this repository
Research direction
Read speaking.c's speak function and the existing module_strip_ssml/module_speak flow first. Compare the proposed server-side handling with #904 and its interaction with multilinguilization in #372. Done should be defined as an agreed subset of SSML, such as break, voice, or say-as, being processed for modules that lack SSML support.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100