Investigate support for standard audio message from audio_common

[sbrodeur]

If would be better if the audio streams where compressed, as to same disk space when recording. The audio_common package provides a way to stream in mp3 using gstreamer. One problem is that the message audio_common_msgs/AudioData is not timestamped, which is a problem for us because we need synchronization between sensors. There is however some work in that direction that hasn't been merged yet:
ros-drivers/audio_common#20

First, we would need to evaluate how much disk space would be saved using mp3 encoding. If it is significant compared to the video streams, we may think of moving to the audio_common package.

[sbrodeur]

Some relevant links:

Use (Python) Gstreamer to decode audio (to PCM data)
http://stackoverflow.com/questions/3507746/use-python-gstreamer-to-decode-audio-to-pcm-data

Decode streaming audio with gstreamer 1.0 and access the waveform data?
http://stackoverflow.com/questions/38542953/decode-streaming-audio-with-gstreamer-1-0-and-access-the-waveform-data

[sgcarrier]

Following graph shows the partitioning of data (compressed via rosbag compress and raw). Audio represents a small fraction of the the overall data, and video is already being transmitted in compressed format (compressed_image_transport) so would compressing audio as well be worth it?

[sbrodeur]

Audio is less than 10% of the bandwidth, so adding compression within the stream will not bring much improvement in storage space. The custom audio message should be kept.