No time in the messages

[v4hn]

Hey @knorth55 , I didn't know you maintain this nowadays :+1: :smile_cat:

I work on an audio application right now where dropped samples and accurate times are important. AudioData does not have a header/stamp/serial number, so there is no way to detect lost samples on the subscriber side. The best solutions I found online subscribe to AudioData and put it in a custom message that includes a stamp filled in with Time::now() which is of course nonsense.

I wonder whether others have problems with this. I mean, changing the message for everyone would sadly be a rather drastic (but from my perspective justified) change...

[knorth55]

I agree with the idea. MessageFilter needs stamp data, so I'm also thinking of adding timestamp info in the message. My opinion is adding AudioDataStamped message, to keep backward compatibility. IMO, header data is huge for micro controller, so AudioData is useful in that case.

[knorth55]

My idea:

• [x] add AudioDataStamped
• [ ] publish both AudioData and AudioDataStamped in audio_capture
• [ ] subscribe both AudioData and AudioDataStamped in audio_play

[v4hn]

publish both AudioData and AudioDataStamped in audio_capture

I implemented stamping simply like this: https://github.com/ros-drivers/audio_common/compare/master...v4hn:audio_common:master-audio-stamped#diff-9a3a6c75b5666c38b65ede971b37b77fc1ebdeb2706e27041e0ff2a103391b0aR177

But I believe gst can provide better timing information through some metadata. It was not immediately clear to me what time you can get from there though and whether we would want to mix it in with ros::Time (which might come from simulation or at least might use a different system clock). Also I'm not sure whether gst itself can point out when samples were dropped in the pipeline...

Actually, it would have been better to implement an audio capture in jack or at least alsa instead...

[v4hn]

You implemented the important parts in #202 and #204 . Thanks :)