delay between request and actual sound

delay between request and actual sound

edited 12/06/2017 - 16:16 in SoundTouch API
habedakhabedak Posts: 6Member

Hi,

I've been playing with the audio notification api for a while now, and it seems to work pretty well. I did notice that there's about a 5-second delay between the request and the moment the notification actually starts playing, and I was wondering if this was 'normal behavior', or whether I could do something to shorten that period.

I'm simply using a curl request to play a small mp3-file (50 KB) located on the local network (so network speed shouldn't be an issue). After I send the request, it takes about a second before the player hits my fileserver, but then it takes about four more seconds before the curl command gets a response (<status>/speaker</status>), after which the selected audio file is played.

I'd like to use the audio notification api for my doorbell, and as such I'd like the sound to play as soon as possible after the doorbell is rung, but five seconds feels like a really long time... so any tips on shortening this period are more than welcome :)

Comments

  • Zach@Bose[email protected] Posts: 156Admin

    Hi habedak,

    Some delay can be expected, but 5 seconds is a lot -- I just experimented with this using a couple different (internet-hosted) audio files and typically saw the response and time from request-to-playback both clock in at ~1 second, with the exception of one clip that was consistently at ~2 seconds.

    As part of processing the API call, the speaker does make a call out to our servers just to verify your API key - is your internet connection limited in a way that this could be the cause of the delay? If that's not the case, then we might need to work to capture logs to better look into what might be the problem - let me know if you're up for going that route.

  • habedakhabedak Posts: 6Member

    As far as I can tell there's no issue with my internet. I'll test a bit more tomorrow, but I'm certainly up for log capturing if it'll help reduce the delay.

    Does the API-key verification mean that I won't be able to audio-notify when my internet doesn't work? If the hypothetical internet repair guy's at my door, I would really like to hear the doorbell as well... Is there a way to opt-out of the whole API-key thing? (I'm not really interested in viewing statistics, and since this is just a silly local application that spots button presses on my EIB/KNX system and plays a sound, I can't imagine it'll be very interesting for you people either ;)

  • edited 12/07/2017 - 18:19
    Zach@Bose[email protected] Posts: 156Admin

    Unfortunately, an API key and check is required and can't be opted-out of :-. You're right that audio notifications won't work without a network connection as a result, too. Apologies for this.

    Let me know how your testing goes, and if needed I can get you log-capture instructions.

  • habedakhabedak Posts: 6Member

    What exactly is the philosophy behind the API-key? This wouldn't only cause problems when I lose internet connection, but it also requires that your server is accessible (and responsive) at all times. Don't get me wrong - I'm certain that you have the best of intentions - but this adds a lot of dependencies to something as simple as a doorbell. Since none of the other components of my home automation system have any such dependencies, I'm pretty hesitant to actually use this API 'in production'.

  • TvDanTvDan Posts: 5Member

    Only using short, locally hosted .mp3 files.
    I'm getting responses within 1s and the bose server reporting a small number of mili-s to process the key.
    Is there a way you could ping the bose servers to see if network to bose is the issue?

  • TvDanTvDan Posts: 5Member

    By the way, a great idea but I personally wouldn't rely solely on a music system to be the only doorbell notification.
    As you already said, there are many points of failure - imho, best to keep the original doorbell and back it up with the soundtouch.
    Perfect for when you're in the back garden with the music playing, out of hearing distance of the important delivery man ... or listening to "piped" music in the warehouse when the doorbell rings.

  • edited 12/10/2017 - 04:21
    habedakhabedak Posts: 6Member

    @TvDan

    The original doorbell is a $10 wireless thing that's eating batteries like there's no tomorrow, so keeping that isn't really an option. It has always been my intention to integrate the doorbell with my home automation system, but our audio system isn't ready for that yet. I'm currently investigating where to throw my money at, and as a long-time Bose fan I started by testing a Soundtouch-30. It's a great system, but until recently it was a bit lacking in the notification department. That's 'fixed' now (at least for the ST-30, the other rooms have built-in speakers in the ceiling so I'm looking at an SA-5 for that, which sadly doesn't have notification support as of yet).

    I agree that there are too many 'points of failure' now, but most of these seem to be introduced by choice, rather than absolutele necessity, and I have a hard time wrapping my head around that. There's the added dependency on my ISP and the Bose servers I'm not a big fan of, but the '100 times' limit will also be a problem on certain days of the year (for instance when kids come trick-or-treating). Since this is a simple home-built plug-in to my automation system I don't want to jump through too much hoops to get those limits raised - I don't actually need a 'works with bose' label for it. Which is why I hoped that there'd be a "personal use only" option, ignoring the entire api-key verification thing altogether.

    @Zach

    I've tried a couple more things (other dns-server, wired instead of wireless), but the delay hasn't improved yet. Could you please inform me how to get some more logging out of the SoundTouch?

  • edited 12/10/2017 - 08:25
    Zach@Bose[email protected] Posts: 156Admin

    @habedak - First, sorry for the delay! The last couple days got away from me. Fair questions asking about why we have the API key dependency. We see this notification API as a pretty powerful one, and we want to work with developers to make sure that power is being used for good when deployed to many customers. The API key approach lets us release this API here for anyone to use in development or home environments, while simultaneously limiting broader use until after we've worked through a certification process. This certainly has it's trade-offs, some of which you've outlined, but we found it to be the best balance for now.

    As for the delay problem, can you email [email protected] so we can troubleshoot further directly?

  • dhinchakTaDumdhinchakTaDum Posts: 1Member

    Has thus delay been resolved? I am trying this with soundtouch 10s (not door bell) and face this too.. If there was a solution I would like to know.

  • thewildthewild Posts: 6Member

    Hi Zach,
    thanks for the explanation, this API Key dependency also intrigued me.
    I have a suggestion that might answer both to your control needs (which I do understand), and our performance concerns : couldn't the API Key authorization be cached by the ST device ? Maybe for sometime, like 24h ? This way, you would be notified when a new device gets accessed via a certain key, but the internet round trip of the key authorization would only happen once per cache period.

  • Zach@Bose[email protected] Posts: 156Admin

    Hi all -- no resolution yet on this. We're looking into reproducing this internally, so that we can try to identify the root cause of the issue.

    If anyone is interested/willing to capture logs to help us troubleshoot, you can do so by following the instructions here: https://community.bose.com/t5/SoundTouch-Archive/Collecting-and-Submitting-SoundTouch-Application-and-System-Logs/td-p/82906 -- specifically the part starting with "To collect system logs". Send any logs you capture to [email protected] -- thanks!

Sign In or Register to comment.