Thursday, 24 March 2016

Audio Recording/Playing

A feature for the feeder is to play the owners voice from the feeder to attract the cat(s). To do this, the owners needed the option to upload a recording. Using HTML5's ...

To upload the file, the POST method was used on the same page and would upload the file to a temporary directory and would then move it to the correct directory which would be the folder where audio is played from. 

The max file size able to upload was also changed to 10 MB from the default 2 MB. This was changed in the php.ini file (/etc/php5/apache2/php.ini). It was also important to note that the uploading process took between 30-40% of the CPU usage as this could potentially overload the CPU whilst the cameras are streaming.

To play the audio uploaded first I tried the in-built aplay from the ALSA system, however it did not play the audio and instead just played noise. So instead the mpg123 package was installed and tested. This was easily installed and used a small amount CPU between 1-5%. After modifying the permissions for the site to be able to run the mpg123 package on the audio folder, the audio could be played as many times as possible. To make sure it can only be played once,  a setuid was used to kill the process at any point - as this is a prototype this is acceptable to show the behaviour of the system, however its likely this would need changing to ensure that this does not open a security issue. 

After testing the audio from mobile devices, the mobile audio was in the format .m4a. The package mpg123 only plays mp3 formatted files. So initially converting any file to MP3 was considered, but it would be the most inefficient method. Instead, more console players were looked into, and eventually the player called SoX was found which supported a lot of different formats. Following the same process for setting up mpg123, SoX was easily installed and was successful with running mobile recordings. SoX also has a built-in function to repeat audio files however many times specified. This was implemented later as an additional function which seemed beneficial to the system - as owners call for their cats multiple times sometimes. This would add a layer of personalisation.

Once implemented, there was one issue that was incurred randomly, where the speaker would not be recognised when all of the usb devices were plugged in, usually this could be resolved by restarting the RPi. However, in an effort to eliminate the issue, I decided to overclock the device to the preset Medium setting for overclocking (along with a small amount of overvolting). This did improve the issue and did not appear too frequently, and hopefully provided an added level of stability with the amount of devices connected.

Tuesday, 22 March 2016

Video/Audio Streaming Testing

The following options were looked into for video streaming and/or VoIP:

  • uv4l
  • Motion
  • MJPG-Streamer
  • Asterisk & freebpx
The first attempt at achieving this function was using 'uv4l', which allows for streaming video and audio over various platforms. It was able to be hosted on the RPi. The primary reason for trying this software was due to the convenience of how both video and audio could be streamed between the RPi and another device in a browser. The software is exactly what was required. However, testing the server on a mobile device showed how it would not work on mobile - although this was on iOS, and is likely to have worked on Android. This was due to the software using video files that the mobile device did not understand. As a result of this I decided to look into other options.

Motion was the next option looked into, where the software features the ability to detect motion in the video. Instead of being an encoded video, it was images captured from the camera and then encoded into a format that would be able to be viewed on any device. Out of all of the software tested, Motion was by far the easiest to setup and configure. It was configured to update the the feed every second, but if motion was detected (which is done by detecting a specified amount of change from the previous frame) then the fps would increase to around 5fps to get a smoother stream. The biggest drawback with using Motion is that only a video stream is produced, there is no audio - so the research continued.

Similar to Motion, MJPG-Streamer compiled images into a simple video stream of JPG images. Motion was easier to setup and implement, however MJPG-Streamer performed better and allowed for both cameras to run, this can be seen below when it was implemented onto the website. As this simple stream did not use stream audio, I carried on my research in an attempt to find a better solution which supported 2-way audio streaming.



The final software looked into was the software Asterisk and freebpx. These are to be used together as a pure VoIP method. This would be accessed externally to the video stream, and would require the use of an external VoIP app such as Zoiper.

However, in attempts to do this, the Asterisk and freebpx did not work and resulted in the use of just streaming video - not audio. As a result, I needed to make sure the video streaming was optimised for the project. Therefore, further testing using MJPG-Streamer to ensure the best output for mobile and ensuring the RPi would not be overloaded by the process.

Initially, at 640 by 480 resolution for each camera without compression, each stream took up between 35-45% of the CPU and showed a lot of delay in the FPS along with approx. 600ms latency. To help all of the issues here, I decided to use different parameters. Below shows the results.



This resulted in the choice to use 160x120 without compression at 20 FPS. The compressed version was not chosen because the image was noticeably worse.

Monday, 21 March 2016

Researching server options to be hosted on Raspberry Pi

After deciding the best method of being able to operate the feeder and comply to its required functionalities was to host a website on the Raspberry Pi server. So I began looking into possible options.

Below are some of the most popular and most well known that were recommended to use on the Raspberry Pi:

  • Apache - Free & Open-Source - Most Popular Web Server (Netcraft)- Written in C, XML
  • Lighttpd - Free & Open-Source - Written in C
  • Nginx - Free & Open-Source - Written in C
  • Monkey - Free & Open-Source - Written in C
  • Tornado - Free & Open-Source - Written in Python
Apache appeared the most suitable and is pre-installed on the Raspberry Pi. Therefore it was selected as the web server of choice.

References:
http://news.netcraft.com/archives/2015/11/16/november-2015-web-server-survey.html