I've set up several messages in the Notifications app to speak through my Samsung WAM1500 speaker. When I first configured them, I tested them and they worked fine. But after a day or so, when they play, a second into the audio string the words are garbled by a "bonk" sound. Has anyone else heard this? Is there a fix?
How is it joined to HE? Though Chromecast?
No, I used the Multiroom app to connect it.
Another data point: it seems to happen most often during the first sound made after it has sat idle for a while. Subsequent sounds played (within 5-10 minutes) don't seem to suffer from this problem.
Also, it doesn't seem to matter which voice profile I choose, they all do it.
I believe that's the sound of the device being initialized...that would explain why you only hear it only after the first sound in a while.
Thanks for the response, @danabw. That does make sense to me, however, this speaker never made this sound with my previous setup using ST. So I don't know if HE is using a different speech engine, or if the configuration is slightly different, or what. But I would sure like to figure out how to eliminate that sound.
That would be a question, I think, for the author of the Multi-Room app, or ask HE about the Notification app. I don't use either. I use Follow-Me in WebCore to speak through my Google Home, and hear the same "bonk" as well if my speaker hasn't been active, but the bonk plays before the notification is spoken.
That's interesting. The timing on this speaker is really annoying - it's about one second into the audio so it stomps all over the third or fourth word of the text string.
There may be ways (i'm having memory issues, I may be confusing this w/Chromecast wakeup options) to keep your speaker awake so it doesn't go through the bonk...maybe someone else will see this and comment.
Ah, found it, in teh Follow Me app there is an option to initialize Google/Nest devices every X minutes so they are awake and ready to speak...
I haven't enabled that as it seems like a lot of traffic just to remove a "bonk" that hasn't seemed to cause me any problems so far...maybe Multi-Room has something similar, or there is a stand alone driver/app option to keep your speaker awake.
Hey @djgutheinz, has anyone else had the issue I'm describing that you know of?
No. Several items:
a. The speakers go into standby mode if no music is playing for an extended period. When they restart, they may be grumpy and generate such a sound when the awaken. I have not tried this yet. Let me see if I can duplicate here. BUT it is highly unlikely I can fix the problem.
Okay, thanks. Let me know if you discover anything.
You are stuck with the bonk. It will occur whenever the speaker is idle for more that 10 or so minutes (I can duplicate). I think it is created by the Speaker internal code for playURL (which is used to play a text stream). That code first pauses the stream before playing. It generates the error: PausePlaybackEvent, data = GetCurrentPlayTime fail.
Thanks for looking into it. It's interesting that I never had this happen with ST. Do you know what may be different?
Do not know. I am still investigating, but since I can not investigate but once every 15 minutes, it is quite time consuming.
In Smart Things, what driver did you use? Mine or the native?
PS - Still working on a real fix. Hope is very low. Temporary fix would be to have a two message notification.
I'm pretty sure it was your driver - I know it was a DTH that I had to install - but that was several years ago and I don't have the ST hub anymore.
I have found a work-around that avoids the bonk interrupting you notification. I am adding an initial message to the queue that is a blank audio. It is sent to kick off the queue and lasts for 1 second (I can and may adjust this to 2 if necessary). Plays only before the first message in a queue of messages.
I am in-process of testing this improvement and will tell you when completed.
Thanks for catching this problem so I could fix it.
Update 3.3.0 available.
- Added capability PushableButton linking directly to existing Push method
- Added blank audio stream (1 second) to starting queue, alleviating the "bonk" in the middle of an actual notification.
File links for quick update:
- Driver: https://raw.githubusercontent.com/DaveGut/HubitatActive/master/SamsungMultiroom/MultiRoomDriver.groovy
- Application: https://raw.githubusercontent.com/DaveGut/HubitatActive/master/SamsungMultiroom/MultiRoomApp.groovy
Please provide further comments at the below thread:
[Release] Samsung Multiroom WiFi Audio
That's awesome, @djgutheinz. Do I need to update both the app and the driver? Or just the driver?