“Nineteen users have pushed for Push-to-Talk, so we gotta get audio out!”

In the past few months, one of the features that you, our users, have often asked for is focused around the audio features available from your cameras. And, as usual, what seems like a simple thing (making the audio work with little problem) turns out to be a big challenge. We have to decipher audio protocols, how one camera supports audio being sent to it, while another may have a completely different protocol which can make any man swear in Italian.

So, when the guys spent a bunch of time bringing about one-way audio (Listening) to the Foscam 9800s and the 8900s, they were particularly happy – especially since the viewer was not supporting things in a much better fashion. And to celebrate this update, they were excited to release this new capability to the waiting userbase, but discovered a strange change: the original player we used for the MJPG video feeds was terrifically snappy – appeared in a moment – when the user turned to the camera.
But with the advent of audio streams, the team wanted to move to the newer tech – which would also reduce user bandwidth – but realized that there was a 3-5 second connection delay every time the user switched to the full screen player. While this was acceptable in the other RTSP cameras, the 8900 series never had this delay. Would the users really care about it?

As an engineer, you have to balance out the good with the not-so-good: do you wait until you figure out how to get the snappiness back before launching audio? Or do you launch the audio and promise corrections in the near? And keeping other people happy with audio AND reduced bandwidth?

As you may have guessed, we chose the later path – and were hoping on your happiness being overwhelming for the audio feature over the connection delay we found. And, while we have heard some happy exclamations, we also have heard of some frustration with the app on the connection time.

Without a Beta Team, we are shooting dangerously

So, we had a powwow about this problem – and the fact that the user feedback on the feature change was not being understood, only the engineers were abstractly getting the point of continual usage. So, as of this week, a couple of things are being implemented here at OWLR as we speak:

  • We have tasked one of our team to capture any and all performance complaints and will be following up on them for your enjoyment.
  • We will be tracking specific metrics for each release and can see the performance if we increase or decrease with the apps.
  • We will be creating a OWLR Friendly Fliers group – essentially some brave souls like yourselves – who can participate in the growth of our app – and the early releases, before we are ready to ship.

To join this flock, all you need to do is email friendlyfliers@owlr.com and your name, email, camera models and other contact details. We would then enter you into our beta group and may draft you to help us with our next releases.

And, the next release, 0.9.7 – will have the connection time reduced to sub one-second speed for all connections. We spent the last two days addressing this – and should have the feature in the upcoming release.

If you have any questions or concerns, please communicate with us at support@owlr.com and let us know – we are hear to help you see things better – and it is your feedback that truly drives us – both good and bad.

All the best and Happy Viewing!

Sanford and the OWLR Team