GNOME Bugzilla – Bug 774050
audiotestsrc: Improvements to the "ticks" waveform
Last modified: 2018-11-03 11:51:20 UTC
The ticks waveform can be useful for audio synchronization diagnostics and other cases where the time offset between waveforms is important. However, in its current form, it is too limited, and has problems with discontinuities, which result in severe artifacts when this waveform is output by a DAC. These patches fix some discontinuities and considerably expand the ticks waveform's flexibility. They also introduce the notion of a "marker tick"; every Nth tick can have a different amplitude (usually one that is larger than the others). This is useful for combining frequent oscilloscope triggering with large time offset detection. For example, without marker ticks, the tick intervals must not be too small, otherwise the maximum time offset that can be unambiguously detected is quite small (for example, if the interval is 50ms, then no time offset larger than 25ms can be unambiguously recognized). If the tick intervals are too far apart, then no sudden changes can be clearly observed, since the oscilloscope is not updated quickly enough. But with marker ticks, this is not an issue: If there's for example a tick every 100 ms, then the oscilloscope can be triggered every 100 ms. And, if every 20th tick is a marker tick, then time offsets of up to 1 second can be discovered, even though the time between ticks is 100 ms. The patches also apply some minor cleanup to the audiotestsrc documentation.
Created attachment 339243 [details] [review] Fix incorrect start of tick waveform
Created attachment 339244 [details] [review] Improve ticks waveform
Review of attachment 339243 [details] [review]: ::: gst/audiotestsrc/gstaudiotestsrc.c @@ +748,3 @@ + if (samplemod == 0) \ + src->accumulator = 0; \ + else if (samplemod < 1600) { \ {} please
Review of attachment 339244 [details] [review]: Maybe it makes sense to add a new element at some point for these complicated testing sounds, instead of adding a million new properties that only apply to some modes. ::: gst/audiotestsrc/gstaudiotestsrc.c @@ +56,3 @@ + * 100ms, and make every 20th tick a marker tick (meaning that every 2 seconds + * there is a marker tick). This is useful for detecting large time offsets + * while still frequently triggering an oscilloscope. Why did you decide on volume instead of frequency? @@ +61,3 @@ + * Also, a "ramp" can be applied to the begin & end of ticks. The sudden + * start of the sine tick is a discontinuity, even if the sine wave starts + * at 0. The* resulting artifacts can often make it more difficult to use the Why *? @@ +275,3 @@ + "Distance between start of current and start of next tick, in nanoseconds.", + 1, G_MAXUINT64, DEFAULT_TIME_BETWEEN_TICKS, + G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS)); These two properties can conflict, right? If there are more sine periods in a tick than the time between ticks...
Comment on attachment 339243 [details] [review] Fix incorrect start of tick waveform Pushed with cosmetic changes: commit a257a177c35645191fda34fba7a0182a40041457 Author: Carlos Rafael Giani <dv@pseudoterminal.org> Date: Fri Sep 2 15:23:18 2016 +0200 audiotestsrc: Fix incorrect start of tick waveform Make sure ticks start with an accumulator value of 0 by incrementing it after filling in samples instead of before and by resetting the accumulator every time a tick begins. This prevents it from being discontinuous at the beginning of the tick. https://bugzilla.gnome.org/show_bug.cgi?id=774050
I think the extra properties are okay, it'll still be less than videotestsrc ;) I wonder about some of the properties though: - "time-between-ticks" --> "tick-interval" - "marker-tick-interval" should also be in nanoseconds then, or we should find a different name, I think "interval" implies time so the description "Make every Nth tick a marker tick" seems a bit odd to me. "marker-tick-distance" perhaps? Dunno. - "marker-tick-volume" - is that useful to configure vs. just picking some defaults? Is there a tick volume property too? > Why *? I suspect this is just a gtk-doc chunk reflowing artefact (line break changed).
Carlos?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/305.