Announcement

Collapse
No announcement yet.

SpeakEasy and Speaker App

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    SpeakEasy and Speaker App

    I have SpeakEasy working fine with my HS generated voice responses (i.e. hs.speak, etc). I only have one instance of the speaker app running on my HS machine and multiple wirelss speakers driven from the one speaker instance so I use SpeakEasy to turn the individual speakers on and off via X10 commands and appliance modules.

    My question relates to the acknowledge phrase generated when the speaker app does VR. As it is now I can't get the speaker app to turn on any speakers when it recognizes the attention phrase. I tried placing the GML tag in the speaker app VR configuration page but it appears that SpeakEasy only intercepts phrases from HS, not the Speaker app.

    Am I missing something, is there another way around this?

    Thanks.

    #2
    That's true. HS only passes phrases to the SpeakProxy server (SpeakEasy) that are internally generated in HS. If Rich passes me the acknowledge phrase then SE can process it but it seems to handled in the Speaker App and not HS.

    Sorry,
    G

    Comment


      #3
      Thanks for the quick reply George.

      I'll submit it as a feature request. Hopefully there can be something implemented for you to access the speaker app or for the speaker app can generate some sort of trigger in HS when VR is recognized so that one can use an HS event to replace the native acknowledge phrase from the speaker app.

      I guess while there are benefits of distributing the VR function as HS2 did it does also remove a linkage that was useful.

      (Rupp, if you're watching can you also pass this along, thanks)

      Comment


        #4
        That would work. If the speaker app can just generate a callback to the speakproxy upon recongnition then Speakeasy can issue the acknowledgement. You're right, it doesn't make much sense being able to route all speech except for certain phrases.

        If HSTgives me something I'll implement it.

        Comment


          #5
          OK, I got the helpdesk request, and since it came in as a trouble ticket rather than a feature request, I change it to being a feature request. We (Rich and I) talked about ways of fixing this, but it has to wait until the next release because we are days away from starting a public beta of the next release of HomeSeer (2.1).

          First of all, there is a bit of a flaw in the reasoning (only a bit). While it is true that HomeSeer 1.7 did route all TTS through the speaker proxy programs, 1.7 never had the ability for multiple TTS or ASR instances either, and when used as designed with the speaker app running on a remote computer, the responses automatically go to the instance that VR was initiated from. Also, 1.7 had no way to have multiple attention words, and so with 1.7, the only way for you to switch speakers was to somehow create a method that told SpeakEasy how to switch the speakers. For example, you might have set your attention word acknowledgement to the phrase "Hello, where may I ask are you?" and then your response triggered a macro that programmed the speakers accordingly.

          Be that as it may, there is a difference from 1.7 to some degree above and beyond the whole speaker client architecture, and so we do want to help resolve this...

          First of all while you are waiting, let me point out that you can simply change your default speaker selection to be the speaker selection that you use for voice recognition, and then use the SpeakEasy pre-processor script so that everything spoken THROUGH SpeakEasy goes to your whole-house speaker setup that you want for non-VR TTS events. SpeakEasy already has the option to restore the speakers to the prior state after TTS.

          There is a technical reason why we cannot simply route the ASR acknowledgement phrases through HomeSeer so that SpeakEasy will work - for one thing, it will significantly slow the ASR interaction, but the speaker app also cannot enable ASR until TTS is finished, and if it is routing through HomeSeer, it does not know when it will get the acknowledgement phrase back from HomeSeer much less whether it will get it at all (connection could have been busted) -- so that is not a possibility at all.

          When we work on this, we are looking at two possible solutions:
          • Create event triggers for VR starting on host:instance and VR done on host:instance. The event action can then set the speakers accordingly or perhaps call a new SpeakEasy action to do something. As a part of that, we will enhance the legacy LastVRCommand script command to accept optional parameters that specify getting the last VR command for a specific speaker host:instance in case you want to trigger off of any VR starting and then let a script determine what to do given the speaker app that started ASR, or if there are multiple ones doing ASR.
          • When responding locally like it does today, the speaker app would also send a signal to HomeSeer, that would appear just like any other hs.speak command, except that it would be halted from being sent back to the speaker client to be spoken. We might capture the host:instance that it came from and store it for the LastVRCommand, and then change the host:instance to NULL:NULL so that HomeSeer does not route it back out to the speaker client.


          One or both of these methods should take care of this adequately.
          Regards,

          Rick Tinker (a.k.a. "Tink")

          Comment


            #6
            Rick;

            Thanks for your quick and thoughtful response.

            Your solution of adding an event trigger for VR starting/stopping is exactly what I had in mind. I would guess if you are going that far you also might as well make it reflect all states (waiting for attention, waiting for command, stopped).

            Your suggestion of the interim workaround by setting a default speaker setting for VR would not be best in my case as I am using wireless speakers. My main interest in using SpeakEasy was to be able to turn off all the speakers when not in use to avoid the interference that is caused by GSM phones in the 850-900 MHZ bands when signaling - this also happens on wired powered speakers at times and really causes one to rethink the whole "put the phone next to your head" thing.

            Having said all that I also agree with your priorities of getting 2.1 out first and understand that this is not a time critical issue.

            Lastly, while thinking about the subject another thought came to mind - have you considered releasing a linux version of the speaker app so that an option would be to place "cheap" vr boxes in multiple locations? Just another thought for the future.

            ---------

            Oops, realized the error of my ways with the last Linux comment, since Speaker App uses SAPI I won't hold my breath for a non-windows version....
            Last edited by Rube Goldberg; March 7, 2006, 06:01 PM.

            Comment

            Working...
            X