ros-drivers
Convert AudioData stream to arrays of floats, and convert arrays of floats to AudioData
I think this needs some work before merging, but I'd like to draw attention to it to get some advice.
The audio_to_float node converts gstreamer encoded AudioData packets into easy to process and understand ChannelFloat32 messages.
I have a viewer that will plot the ChannelFloat32 messages, it takes up a lot of cpu however, and it probably ought to exist elsewhere as a generic utility for plotting arrays (of more types) topics in a way that assumes they are actually 1-D and in sequence. Maybe this is already solved elsewhere?
ChannelFloat32 was used because it was the first message type I found already installed on my system that had floats in an array, but maybe there is something else I ought to use?
The float_to_audio node is resistant to dying with ctrl-c, it would be nice to fix that.
The audio_to_float node makes assumptions about the data format when it converts it, I think I understand gstreamer well enough now to have gstreamer convert to floating point for me.
I'd really like to reformat the code to be roslint compliant, though both cpp files are adapted from code here and mostly the existing style hasn't been changed.
Possibly this should just be a standalone package?
I like the goal here; it aligns closely with one of the overall goals for the package, to provide a more general audio transport within ROS: #12
I don't work with audio data frequently so I don't know what the preferred format is, but choosing ChannelFloat32 as the message type seems a bit limiting. I think a new message type for formatted audio data would be fine, and there is already the audio_common_msgs package for it.
The comments in ChannelFloat32 indicate that it is used for 3D point cloud data, so if you do want to use it for audio you should probably request an update to the comments.
Some of the most common requests I get for audio_capture and audio_play are for a more understandable message format, so I think it would make sense to integrate this directly into those nodes. (it would probably decrease the latency too)
I'm not aware of a viewer like this elsewhere. I'd be happy to accept it here.
My experience (long ago) working with the JACK Audio Connection Kit suggests that an array of 32-bit floats for each channel is a very good way to exchange audio data between different programs.
However, I feel that we should not re-pupose ChannelFloat32 for that, because it already exists with different semantics. We can define a new specifically-audio message, instead.
