Announcement

Collapse
No announcement yet.

Delayed audio at GH minis

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Delayed audio at GH minis

    I have several event notifications consisting of a .wav tone followed by a speak action. Of late I'm having consistent delays of ~120 seconds for the audio to play on my GH minis via the chromecast PI. (Sometimes the .wav plays immediately, but the TTS seems to always be delayed). I've confirmed that the events are firing properly, just the audio is delayed.

    The problem seems to have started when I segmented my IoT devices--including the minis--to a separate vlan/subnet, and I'm hoping someone here can give me advice on troubleshooting. My HS server and z-net are on my trusted network (vlan1/192.168.0.xxx) and minis are on vlan107/192.168.107.xxx. Firewall rules allow established and related connections from vlan107 -> vlan1, and all other traffic is dropped. No restrictions from vlan 1 -> vlan107. Might I need to poke another hole for the minis to work properly? I have no understanding of how Bonjour works and whether my firewall may be causing a problem there. I also read elsewhere about an issue with the GH going to sleep although I doubt that's the issue as I've repeated the test within minutes with the same results--and they shouldn't have gone to sleep that quickly.

    I've attached a debug log that I started just before manually running an event with the notification actions. I disabled the log just after the audio actually played--about 2 minutes later.

    Any advice appreciated. Thanks.

    -Wade

    edit: On the past 4 tests, 3 times the .wav file played immediately and the TTS was delayed 2+ minutes. The other time both were delayed.


    MESSAGE BOARD (copy/paste section below to message board posts)

    Current Date/Time: 7/1/2019 9:13:25 PM
    HomeSeer Version: HS3 Standard Edition 3.0.0.534
    Operating System: Microsoft Windows 10 Pro - Work Station
    System Uptime: 0 Days 4 Hours 21 Minutes 58 Seconds
    IP Address: 192.168.0.16
    Number of Devices: 683
    Number of Events: 393
    Available Threads: 400
    HSTouch Enabled: True
    Event Threads: 1
    Event Trigger Eval Queue: 0
    Event Trigger Priority Eval Queue: 0
    Device Exec Queue: 0
    HSTouch Event Queue: 0
    Email Send Queue: 0
    Anti Virus Installed: Windows Defender
    In Virtual Machine: No MFG: dell inc.
    Enabled Plug-Ins
    2.0.59.0: BLBackup
    3.0.25.0: BLLock
    2.0.28.0: BLOccupied
    2.0.66.0: BLOnkyo
    3.1.3.33206: Blue-Iris
    3.0.0.34: Chromecast
    3.0.0.65: EasyTrigger
    3.0.0.31: EnvisaLinkAdemco
    3.0.0.8: MeiUnifi
    1.2019.211.1740: MyQ
    3.0.0.33: Nest
    3.0.0.63: PHLocation2
    1.0.0.7: Restart
    3.0.7.0: SDJ-Health
    0.0.0.5: Sure Petcare 3P
    3.0.2.261: Z-Wave
    -Wade

  • #2
    I have a similar problem speaking to Android tablets. Most of my TTS is now pre-recorded and saved as .mp3 files. I have my tablets on a different subnet as you do. I also run HS3 on linux. I have not had delays as long as you have, but it is different to each tablet and can be delayed for 1-5 seconds. I run a ubiquity edgemax router so I don't think I need to upgrade and iperf says I have plenty of bandwidth. My TTS timing improved when I went to pre-recorded files because I was getting delays on up to 10 seconds with TTS conversion.

    Below is the site I used to build my pre-recorded text to speech files.

    https://soundoftext.com/

    Hope this helps.

    Comment


    • #3
      Originally posted by AllHailJ View Post
      I have a similar problem speaking to Android tablets. Most of my TTS is now pre-recorded and saved as .mp3 files. I have my tablets on a different subnet as you do. I also run HS3 on linux. I have not had delays as long as you have, but it is different to each tablet and can be delayed for 1-5 seconds. I run a ubiquity edgemax router so I don't think I need to upgrade and iperf says I have plenty of bandwidth. My TTS timing improved when I went to pre-recorded files because I was getting delays on up to 10 seconds with TTS conversion.

      Below is the site I used to build my pre-recorded text to speech files.

      https://soundoftext.com/

      Hope this helps.
      Thanks for the reply and suggestions. I'm hopeful I can solve the problem in some other way since I've had no delay problems until very recently. If it's due to the network segmentation it seems like I should be able to correct it. But if not I'll look into the pre-recorded speech files.
      -Wade

      Comment


      • #4
        I've done a bit more testing. If I remove the play audio (.wav) action, the TTS plays immediately on trigger, as expected. As soon as I insert the audio action, the .wav plays immediately and the TTS is delayed ~ 2 min. (3 consecutive tests using the Run button in the action). Checking or unchecking "Wait for audio to finish" has no effect. Puzzling. It worked correctly for months.

        Originally posted by cc4005 View Post
        I have several event notifications consisting of a .wav tone followed by a speak action. Of late I'm having consistent delays of ~120 seconds for the audio to play on my GH minis via the chromecast PI. (Sometimes the .wav plays immediately, but the TTS seems to always be delayed). I've confirmed that the events are firing properly, just the audio is delayed.

        The problem seems to have started when I segmented my IoT devices--including the minis--to a separate vlan/subnet, and I'm hoping someone here can give me advice on troubleshooting. My HS server and z-net are on my trusted network (vlan1/192.168.0.xxx) and minis are on vlan107/192.168.107.xxx. Firewall rules allow established and related connections from vlan107 -> vlan1, and all other traffic is dropped. No restrictions from vlan 1 -> vlan107. Might I need to poke another hole for the minis to work properly? I have no understanding of how Bonjour works and whether my firewall may be causing a problem there. I also read elsewhere about an issue with the GH going to sleep although I doubt that's the issue as I've repeated the test within minutes with the same results--and they shouldn't have gone to sleep that quickly.

        I've attached a debug log that I started just before manually running an event with the notification actions. I disabled the log just after the audio actually played--about 2 minutes later.

        Any advice appreciated. Thanks.

        -Wade

        edit: On the past 4 tests, 3 times the .wav file played immediately and the TTS was delayed 2+ minutes. The other time both were delayed.


        MESSAGE BOARD (copy/paste section below to message board posts)

        Current Date/Time: 7/1/2019 9:13:25 PM
        HomeSeer Version: HS3 Standard Edition 3.0.0.534
        Operating System: Microsoft Windows 10 Pro - Work Station
        System Uptime: 0 Days 4 Hours 21 Minutes 58 Seconds
        IP Address: 192.168.0.16
        Number of Devices: 683
        Number of Events: 393
        Available Threads: 400
        HSTouch Enabled: True
        Event Threads: 1
        Event Trigger Eval Queue: 0
        Event Trigger Priority Eval Queue: 0
        Device Exec Queue: 0
        HSTouch Event Queue: 0
        Email Send Queue: 0
        Anti Virus Installed: Windows Defender
        In Virtual Machine: No MFG: dell inc.
        Enabled Plug-Ins
        2.0.59.0: BLBackup
        3.0.25.0: BLLock
        2.0.28.0: BLOccupied
        2.0.66.0: BLOnkyo
        3.1.3.33206: Blue-Iris
        3.0.0.34: Chromecast
        3.0.0.65: EasyTrigger
        3.0.0.31: EnvisaLinkAdemco
        3.0.0.8: MeiUnifi
        1.2019.211.1740: MyQ
        3.0.0.33: Nest
        3.0.0.63: PHLocation2
        1.0.0.7: Restart
        3.0.7.0: SDJ-Health
        0.0.0.5: Sure Petcare 3P
        3.0.2.261: Z-Wave
        -Wade

        Comment


        • #5
          I added a HS speaker client to the speaker list. The .wav file immediately plays on the speaker client, followed by the speak action as expected. The .wav file never plays on the GH minis and the TTS plays 2 minutes later. Possibly a problem with the .wav file playing and there's a 2 minute timeout before moving on to the TTS? Note that unchecking "wait for audio to finish" on the .wav action has no effect.

          I substituted a different .wav file, but no change. Next uninstalled and reinstalled the chromecast PI--made sure the .ini was deleted and recreated. No change.

          I guess next test will be to put one of the GH minis back onto my secure network (off my IoT segment). Appreciate any thoughts.

          -Wade

          Comment


          • #6
            Moving the GH mini onto the same network segment with HS seems to have fixed the problem so presumably it's a firewall issue. The problem occurs when the GH minis are on the IoT network. HS3 is on my secure network. Right now I'm allowing all established and related traffic from IoT network to secure network. All other traffic is dropped. No restrictions from secure to IoT. spud Are you aware of any other firewall holes that might be needed to make this work correctly?

            Thanks.
            -Wade

            Comment


            • #7
              When using system TTS or when playing a .wav file, the HS3 web server is leveraged to serve the audio file to the GH/Chromecasts. So your GH need to be able to access the HS3 web server.

              When using Google TTS, the GH/Chromecast directly access the audio from a google URL.

              Comment


              • #8
                Originally posted by spud View Post
                When using system TTS or when playing a .wav file, the HS3 web server is leveraged to serve the audio file to the GH/Chromecasts. So your GH need to be able to access the HS3 web server.

                When using Google TTS, the GH/Chromecast directly access the audio from a google URL.
                Thanks for the reply. I'm a bit out of my depth here so please bear with me. Are you saying I would need to allow traffic initiated by the GH device to the network where the server resides? I.e., the GH mini needs to establish new communication to the server in addition to the server establishing communication to the GH mini?

                If yes, it seems I have 2 options:
                1. Move my GH devices back onto my secure network, or
                2. Add pinholes to my firewall to all the GH devices to establish comms to the server.


                The other thing that is confusing here is that the TTS will eventually play, just not immediately.
                -Wade

                Comment


                • #9
                  Getting erratic response from all my GH devices now. Manually triggering an event with a .wav and speak action...the GH on the same network segment with HS worked once, then subsequently hasn't worked with repeated tests. Got one on another network segment to emit the the built-in GH "b-dink" notification once, but not my .wav or speak action. But now even my HS speaker client running on the same PC as HS isn't working reliably--seems to no longer play any speak actions even though the test in the client UI works fine. TTS actions are showing up in the HS log as expected. Looks like I may have a bigger problem than the chromecast PI. If anyone has any ideas for troubleshooting, I'm listening. May move this to the general forum. Thanks.
                  -Wade

                  Comment

                  Working...
                  X