Normal lead time of a command or a sound

[Tulud]

Hello. I am french so I'll like even trying to make me understand .

I am currently trying Sighthound with a webcam (before a future IP camera). My problem is that I have a time prior to the execution of a sound évent. I know that this problem has already been exposed in any other subject. But I would like to know, how much time do you consider "normal" ? Currently I have a delay of 5 or 7 seconds before the outbreak of a sound event with a 1% CPU use.

Config: Windows 7 64 bit Intel I7 960 Ram: 6 GB 1066 mhz

[Semper Vaporo]

Yes, there is a delay between an event actually occurring in the scene and the playing of the sound file by the computer to tell us about it.

Part of that is "processing time" to determine that motion has occurred and then to determine if it is a person or something else, and then scheduling the playing of the sound file. I am finding that the major portion of the delay is not in the SH processing, but in the operating system getting around to executing the software to actually play the requested sound file.

I believe the bottleneck in this process is the speed of the Harddrive where the program (CODEX) resides that processes the sound file, and the sound file itself.

SH tells the OS to play a sound file and the OS then had to load from the disk the program that handles it, which then in turn retrieves the sound file from the disk to actually send the data to the sound card to play it. Depending on the sizes of the directories that these 2 files (CODEX and the sound file itself) reside in, it is possible that the drive must churn a while before it finds the CODEX file name, and then it has to churn some more to actually load the program. The process repeats for the search and load for the sound file itself. If the directories are long/large, it might take extra time to load enough of it to find the desired files.

Normally, in a computer, there is a buffer that can hold a sizeable portion of the directories and that speeds up the searches because the directory is already in the buffer, but in such a disk intensive process as SightHound (lots of data is flowing to and from the disk drive on a near constant basis) these buffers get overwritten rather quickly, so they are near useless for speeding up the search of directories.

One thing that MIGHT shorten the delay would be to move the OS (at least the CODEX files) and the Sound files to a separate drive so that maybe the directories for those two will remain in the disk buffers for that drive and make the search for them faster (after the first time they are called, which fills the buffer) because the buffer won't be overwritten by SH doing its other work of storing video and updating the database.

Another thing would be to get a faster drive. Look for drives with faster rotation speeds (5400 is slower, 7200 is faster... I think those are the two most common speeds these days). The ultimate would be to use a solid state drive because then there is no rotational latency to contend with (reads occur immediately instead of having to wait for the disk to spin around to get the desired sector to pass under the read/write head).

Beyond that, I don't think there is much that can be done to reduce the delay between a motion event occurring and the computer playing the sound file to alert us to the event.

The folk at SightHound might have different ideas on this, but that is what I have determined in my experimenting with computers (both using SightHound and other systems over 45 years as a programmer myself). (My next system will have a solid state drive to see if it proves my theories!)

[Tulud]

Thanks for that detailed reply. Do you know if the time to execute a command will be the same?

[Semper Vaporo]

DRAT! I composed the most eloquent reply yesterday... the most beautiful bit of prose that was ever written... answered your question as well as provided a solution to the Unified Theory, a cure for the common cold, and what happened to Jimmy Hoffa's body... but alas it took me so long to compose it, the system logged me off and I forgot to save the text before I clicked "Submit" and it didn't get posted and will never be seen again.

Of course, now I cannot remember what I wrote!

But to attempt to answer your question (again)... yes, I think the time to interpret the video and determine if the rule is met and then schedule playing the sound would remain the same. I have 7 cameras now and a quad core CPU and it is idle 30% to 50% of the time. That is time waiting for the next frame of video to become available from any camera so that it can be added to the analysis stream and the rules tested to see if motion has occurred that fits the rule. So, there is plenty of CPU time available to process things and schedule the OS to load the CODEX and play the sound file,...

But there is still that latency between the postman walking up on my porch and the alert sound, and by the time I look at the screen (I am sitting right next to it) the postman is already three-quarters of way across the yard to the next door neighbor.

I gotta get an SSD to see if that improves things. My theory says it will, but I have no proof.

I don't think there is anything that SH could do to speed up the playing of the alert. It still must gather multiple frames of video, average out the noise, compare one set to another and then test the rule... most of that is hardly any time at all, but the time between frames is fixed and SH must simply wait until it has a bunch to analyze... no way around that.

[Tulud]

Thank you Semper VAPORO.

I tested today the execution time of a command (run the command). And I think it is about the same as playing a sound.
In my first message I was trying to put a webcam. The running time was about 5-7 seconds. Today I tested an Android phone and an IP webcam application. The execution times are now 3 seconds. I think I added a webcam additional delay.

I do not have a SSD, but one day I'll try maybe with windows 7 live, fully loaded into RAM if it exists. I think a WinBuilder ...