I am trying to get Squeezebox TTS working on OpenHAB 2.2. The binding installs OK and detects all my players once I enter the Squeezebox server IP address. I have installed MaryTTS and set the default sink in Configuration > System.
To test I entered “smarthome:voice say hello” on the console. On the selected radio I get an error like:
The radio pauses for about 30 seconds and then resumes. I’ve tried this on an Ubuntu and Windows installation of OH, with the same results. Squeezebox Server version is 7.9.1.
Thanks Mark, I’ll check it out. However, I would have thought that many more people would have come across this if LMS couldn’t play WAV files. MaryTTS only produces WAV files.
You might want to get the MaryTTS wav file and try to play it directly in LMS.
In the LMS, you can go to Radio->Tune In URL and paste a URL that points to a WAV (or MP3) file.
I tried playing a WAV from VoiceRSS and I got the same error you show above. I did this entirely using the LMS and a player (i.e. openHAB was not a part of the test).
OTOH, I’ve tried playing several other WAV samples from various sources on the Internet. Some play and some don’t play. Probably something about the format.
Yeah, I had tried grabbing the wav file to try playing it directly, but the url seems to disappear after a few seconds.
I know I had this working in a previous version of OH, but I seem to recall that there were other parts to the binding - squeezebox.io?
However, I tried smarthome:audio play doorbell.mp3 and that worked OK, so it looks like it’s an audio format issue. I just don’t understand how no one else seems to have had this problem.
I’ll try voicerss insead of MaryTTS tomorrow and see if that works.
Unfortunately I have the same issue.
It seems to be related to all WAV files (e.g. created by say).
playSound(“doorbell.MP3”) has no problems.
If I use an other sink than Squeezebox, wav files are working fine too.
I assume its a sort of timing or naming issue of the temporary file.
Long MP3 files are deleted prior to playing until the end of the title.
If I try deleting the original wav file after a playSound I can not, because its locked by OpenHAB (java) but the temporary file is gone already.
The WAV file is created by the TTS service you’re using (MaryTTS, VoiceRSS, etc.)
The issue with WAV files has nothing to do with openHAB or the squeezebox binding. The LMS has issues playing some WAV files.
There’s a timeout on say and playsound notifications that’s currently set to 90 seconds. That might be what you’re running into. I’m working on a version of the binding that among other things allows the timeout to be set using a configuration parameter on the player thing, similar to what’s available with the sonos binding.
I tried other .wav files locally on the media server and they also refused to play, giving the same playlist error, so it’s a problem with how LMS and the players handle wav files. I have since switched to VoiceRSS which uses mp3 files, and it worked immediately.
Playing exact the same files via LMS Web Interface (Drag/Drop option) is working without issues. Either the OpenHAB web-server is somehow modifying the WAV files or the Squeeze-binding is just not working well.
That’s interesting. The binding doesn’t touch the audio content at all. The binding gets a URL that points to the audio content, which it tells the LMS to add as the last item of a playlist. The LMS then tells the player to stream the audio content using the URL.
In your test using drag/drop, the only difference I see is that the content is played as a local file in your test versus being streamed. I didn’t think the audio content was modified by the web server; however, the web server likely does return some metadata in the form of HTTP headers when it serves the content.
Perhaps dragging & dropping in the LMS Web Interface results in the wav file being transcoded before being sent to the player, while the binding sends the wav file unchanged directly to the player?
I’ve noticed this same problem. I have some .wav files on LMS and downloaded some sample .wav files (short duration) for testing. They play fine if I’m playing directly from LMS, or if they’re set up in a Favorites setup than can be activated from OH. However, trying to play the wav file directly with a playSound rule command doesn’t work. On LMS, it shows a Notification coming in, and I get silence for a few seconds. However, I can play the file directly with LMS if it’s the player (played directly, no OH connection). MP3 files are not affected. I’ve tried long and short files with the same result.
There’s something here with OH… It’s beyond my pay grade, however… I’d like to use Pico TTS for some functions, but since I’m running an RPi3B and I’m a privacy hound, I’m limited to Pico for TTS, and Pico is limited to WAV files…
Thanks, Mark. Here’s a link to an example that behaves this way: http://file-examples.com/index.php/sample-audio-files/sample-wav-download/. It’s the very first download at the top, called file_example_WAV_1MG.wav. I have tried very short wav files (a few seconds), and I have some rips that are 300+MB that are an hour+ in duration. Thus far, none of them work if called from OH via playSound, but they all work if they played either directly from LMS or called from OH in a rule that simply changes a favorite to play on LMS. On the other hand, all MP3 (and FLAC) files work as expected via playSound.
FWIW, I’m administering from a Debian testing machine with LMS running on another Debian/Plex/Kodi/HTPC/Gaming machine. The squeezelite player is on the same HTPC and it’s set as the default squeezelite player sink for Openhabian, running an RPi3B. With wav files, OH interrupts the stream from the LMS to play the WAV file (just as in the MP3 case), but it simply pauses for some time and then LMS takes back control of the audio stream. However, if I use the same wav file on LMS set up as a Favorite, I can make it play from both LMS and through OH rules.
Thanks, Pat. It’s odd that it’s only happening when wav files are played directly from playSound. If it’s happening on HA also, then I’m really confused (as if that were more possible…).
So, I placed file_example_WAV_1MG.wav and an mp3 file on a web server unrelated to openHAB.
Using the “Tune In URL” feature of the LMS, I tried playing both files. The mp3 file played fine. The wav file didn’t play.
Based on that, I don’t think it’s an openHAB issue, as openHAB wasn’t used at all in the tests.
Edit: Because you can play the file when hosted locally on the LMS (I confirmed this in my tests), I suspect this is an issue associated with streaming the wav file.
Thanks, Mark. This question may be out of scope, but do you know what parameters may be required for playing wav files via playSound? Since I don’t have a wav file that plays, and since this exercise is to test whether Pico TTS - sending wav files - could work with OH through over a squeezelite sink reading select files based on scheduled rules, I’m not sure if Pico would work or not. I’m assuming I can tailor some settings with Pico (maybe not - haven’t used it yet) to ensure the wav output conforms. Any thoughts on what I should look for? I can report testing results as needed…
I’m not really sure, as I have no experience with Pico TTS. I suspect Pico TTS will create files that will play on a Squeezebox audiosink, except if the file is streamed from a web server.
To help support this theory, I tried specifying a local wav file (file:///opt/openhab2/conf/sounds/wav.wav) using the Tune In URL feature of the LMS (e.g. Home -> Radio -> Tune In URL. In that case, the wav file played. This further supports that streaming a wav file from a web server to the LMS is where the issue lies. I suspect there may be some HTTP headers that are missing or incorrect.
