Debugging audio_common - audio_play has poor quality
I've followed the tutorial on audio_common, and the command
gst-launch-0.10 alsasrc ! audioconvert ! audioresample ! alsasink
results in audio playback with no noticeable loss in quality.
However, when I capture audio via audio_capture and play it via audio_play, the audio quality is very poor, sounding as if segments of audio are being lost. (It's a lot like the choppy voice quality in 1980s fast food drive-throughs.)
When I play a rosbag of what was captured and listen to it via audio_play, the quality is similarly poor. A sample rosbag can be found here. My intuition, though, is that the audio being captured---and the rosbag---is actually full quality or close to it, and the issues are coming from audio_play. However, I don't know how to listen to the audio from audio_capture without audio_play, which would test this conjecture.
Additionally, audio_play varies in how it responds to messages from new nodes publishing to /audio. It often will not play these messages. Restarting it in such cases does result in the messages being played. This issue might be related to unanswered question. This older question also seems relevant.
A strange clue: if I keep audio_capture running while also running a rosbag of audio_capture, once the rosbag is finished, the audio comes through audio_play with full quality, though the playback is 5-10 seconds delayed.
I'd appreciate any tips on how to debug or solve these issues. I'm running hydro on a natively installed Ubuntu 12.04, with all ROS activity on the same machine. GStreamer version is 0.10.36.
More clues!
(1) The audio_capture is working just fine (maybe some tiny glitches here and there). The next clue contains the evidence for this assertion.
(2) There are two ways to make the audio come through without noticeable quality loss. First, I can start audio_capture and audio_play, and then plug in my microphone. There's a ~0.5 second delay, which is a big improvement over the previous hack. Second, if I play a rosbag on loop, the audio quality is awful on the first iteration of the loop and then subsequent iterations.
Even more!
I created an Ubuntu 12.04 virtual machine on OSX Parallels that used the default Parallels installation and then only had ros-hydro-desktop-full and ros-hydro-audio-common installed via apt-get. I installed nothing else. The issues described above were present this time as well. My intuition is increasingly that this problem affects a large percentage of systems that have installed ROS according to official directions. Unfortunately, audio_common does not seem to be actively maintained, based on timestamps of activity by its official maintainer, Austin Hendrix, who I could not reach by email.
An improved hack for rosbag playback (with accompanying clues)
I recently realized that if I play a rosbag with increased speed (using the -r <speed> argument, where <speed> > 1.0), the audio comes out perfectly. Small and very interesting caveat: If I use 1.01 speed, the audio has a few seconds of bad playback and ...
I'm sorry; while I am the maintainer on audio_common, I picked it up from another developer, and I don't know much about the audio_capture and audio_play nodes.
Hi, Austin. It's great of you to have taken audio_common on. Thanks for responding. If we end up digging in deeply enough to make a real fix, we'll be sure to post it and/or commit it to the repository.
Did you manage to find a fix for this? I am seemingly having the same issues as you had..
Unfortunately, we ended up using hacks because of time constraints. For real-time audio play and recording, we both had audio_capture pipe into a rosbag while we listened via the gst-launch-0.10 ... command above. But only works if the microphone is on the same computer as where you want output.
For play from rosbag, we used the "improved hack for rosbag playback" above. If you want to try a fix, it's relatively easy to get the audio_common source and compile it. If I recall correctly, there's one main file that seems relevant and its use of gstreamer is what seemed to need fixing.