I made different tests and the size of the buffer does not make a big difference.With "test" as text, 35 ms is the best I can get for example with a 128 bytes buffer.Increasing the buffer size does not reduce the time.

I would still make the write chunks 1-4k to reduce the system CPU load, and syscalls always strive up SYS CPU levels. Our end-to-end time Weill be bounded by URL calls etc,but we should minimize our CPU impact, during the time we are running, since these boxes are small and doing a bunch of other stuff that's impacted by our resource usage.

I made different tests and the size of the buffer does not make a big difference.With "test" as text, 35 ms is the best I can get for example with a 128 bytes buffer.Increasing the buffer size does not reduce the time.

Unfortunately I discovered that my solution produces a strange rendering of the end of the file.I imagine it is due to the fact that the Sonos buffers a certain number of MP3 packets before playing them.I think the solution would be to add real MP3 packets to the file, packets corresponding to silence.

You encountered the problem with the URL too long. I have not checked but the way you handle it is probably a way to get it work.But why not using the Say function ?

To come back to the Say function, we could try to cut automatically the text and finally call several times Google. We will have to find the best cut points in the text (like end of sentences) as there will be some delay between each fragment playback (time for Sonos to switch to next "web-radio" file). Other alternative would be to let the user define the cut points in the text, for example with a special character ? Then we will add other cut points only if there are too much characters.

As it seems Google TTS has a 100 character limit per request, an idea might be to have a character count next to the SAY field (or a fixed limit on that field) so people know or can see if they are going to reach the limit on any request. (There looks to be no restriction at the moment)

I'm testing your skills now but may consider having an '+' option so you can add extra SAY commands, then if all I requested at almost the same time, it might be possible to play them in order with little to no delay.

an idea might be to have a character count next to the SAY field (or a fixed limit on that field) so people know or can see if they are going to reach the limit on any request. (There looks to be no restriction at the moment)

You mean the field in the UI (player tab) ? As it is Javascript, it is probably possible. But that would not help the users using the other ways (scene) to use Say. So the idea is more to find a global solution, not something limited to a particular usage.

Quote

I'm testing your skills now but may consider having an '+' option so you can add extra SAY commands, then if all I requested at almost the same time, it might be possible to play them in order with little to no delay.

The limit at 100 characters is exactly what I have with my initial example.The good news is that the limit is absolutely not dependent on the way we call Google.So we have now just to cut a more than 100 characters in several blocks.