Ask Your Question

Revision history [back]

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 Ubuntu 12.04, with all ROS activity on the same machine.

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 Ubuntu 12.04, with all ROS activity on the same machine.


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.

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.


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 a 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.

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.


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 a 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.

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.


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 then perfect playback after. If I use 1.001 speed, the audio has tens of seconds of bad playback and then perfect after. This pattern seems to indicate that audio_play performs correctly once some amount of its buffer has been filled. (If I had time and C++ skills, I'd dig in and try to create a fix!)

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.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 then perfect playback after. If I use 1.001 speed, the audio has tens of seconds of bad playback and then perfect after. This pattern seems to indicate that audio_play performs correctly once some amount of its buffer has been filled. (If I had time and C++ skills, I'd dig in and try to create a fix!)