Closed twischer closed 4 years ago
aguedes
commented
4 years ago Hi @twischer, thank you for this PR, I'll review it soon. If you don't hear from me in about a week, feel free to ping me on this thread :)
Meanwhile, are you familiar with avtpcrfsync and avtpcrfcheck elements provided by the GStreamer AVTP plugin? At a glance, it seems the issue mentioned in the PR description is already covered by the GStreamer AVTP plugin.
twischer
commented
4 years ago Hi @aguedes,
are you familiar with avtpcrfsync and avtpcrfcheck elements provided by the GStreamer AVTP plugin?
Thanks a lot I was not aware that there are also already GST plugins which are suing the CRF. The GST CRF solution is near to what I am looking for. Actually I was not aware that different crf-listeners can use the same CRF stream simultaneously. Therefore I am no longer sure if this POC would be really beneficial because it is already without this PR possible with the crf-listener to have multiple AAF talker using the same CRF on the same machine. (May be this PR makes still sense to do the CRF decoding only once and not for each AAF talker/listener application on the same machine)
But I am still missing one small part in the GST CRF and in the crf-listener implementation. @aguedes may be you could provide me your opinion before I am starting implementing something. My final use case are multiple AAF talkers doing a file playback which should be synchronised with the same CRF. In addition in my use case the gPTP master and the CRF talker are running on two different machines. Therefore they are using different clocks and can drift away from each other (less than 100PPM). Due to this drift the difference between the CRF timestamps can differ from the actual period time of the audio samples. For example in case of sending 300 CRF timestamps per "audio clock" second in best case we should see a difference of 3,33ms (=1sec/300) between the CRF timestamps (in gPTP time). But due to the difference between the audio clock and the gPTP clock of 100PPM the actual difference can differ by +-333ns. The timer used in the crf-listener for the AAF talker mode (and gst audiotestsrc) is based on the gPTP time. Therefore the timer interrupts can drift away by 100PPM from the actual audio clock (CRF) used by the AAF listener. This means that an audio buffer of 8ms would under run after 80sec in case the audio clock is 100PPM faster than the gPTP clock.
Do you see the same problem? Do I miss something?
As a solution I am currently thinking about resetting the timer with current interval (difference between CRF timestamps) and the next presentation time whenever the next timer event would drift away to much from the actual presentation time. Do you see already any issues with this idea?
aguedes
commented
4 years ago The GST CRF solution is near to what I am looking for. [...] Therefore I am no longer sure if this POC would be really beneficial because it is already without this PR possible with the crf-listener to have multiple AAF talker using the same CRF on the same machine.
Glad to hear that! :) Yes, after taking a look at this PR, I see this functionality is indeed already provided by the GStreamer AVTP plugin.
Also, I'd like to take this opportunity to clarify that the applications provided in examples/ are kept very simple on purpose. They are meant to provide examples on how to use the library APIs only. They are not truly AVTP talker and listener applications. Functionalities such as Talker, Listener, CRF synchronization, etc. should be implemented in application frameworks such as GStreamer.
(May be this PR makes still sense to do the CRF decoding only once and not for each AAF talker/listener application on the same machine)
Depending on the use-case, maybe you could build one single gstreamer pipeline that generates multiple AAF streams and funnel them into one crfsync. That way, the CRF decoding would happen only once and serve multiple AAF talkers.
Do you see the same problem? Do I miss something?
Yes, I think I see the problem you described. However, since the ptp clock is constantly adjusted to match the GM, I'm not sure if that problem could happen.
BTW, if you have questions regarding the GStreamer AVTP plugin, feel free to open an issue at gst-plugins-bad project. The community will be glad to help!
twischer
commented
4 years ago @aguedes Thanks a lot for your detailed answers.
I will close this PR due to it does not keep the example simple. In addition the same use case can already be full filled by GST plugins.
The following patch set provides a prove of concept for supporting multiple AAF talker and listener to use the same timestamps of one CRF stream. Without this patch only on AAF talker or AAF listener could use a CRF stream exclusivly.
This patch introduces a CRF daemon which receives the CRF packages of one CRF stream. It extracts the CRF timestamps and forwards them to all connected clients. A client can connect to the daemon by using the new avtp_crf_daemon_connect() API. To enable the transmission of timestamps the client has to sent an AVTP_CRF_DMN_REQ_REGISTER request to the server. Afterwards the client will receive a timestamp from the daemon whenever a new CRF was received by the daemon. Those timestamps are sent via AVTP_CRF_DMN_RESP_EVT responses. The following commands can be used to start an AAF talker:
The second command can be running in parallel for different [DEST_MAX].
Related to IEEE 1722-2016 chapter 10.8 "Relationship between CRF timestamps and stream timestamps" the AVTP timestamp used by an AAF talker should not differ more than 5% from the CRF timestamp. In case of 48kHz this results into 1/48kHz * 5% = 1,04µs. I do not expect that it would be possible on Linux to read the current gPTP timestamp when sending an AAF package with such an accuracy. Therefore I think anyhow the CRF timestamps have to be propagated to each AAF talker which wants to synchronize to the CRF stream and only recovering the media clock from the CRF stream is not sufficient. Therefore I see a good advantage in providing such a crf-daemon with the libavtp. This daemon could also be used by other plugins like ALSA and GStreamer AAF plugins to easily extend those plugins to use CRF streams.
I have not yet fully tested this prove of concept. Anyhow I would be quite happy to get some feedback what you think about this approach. Or may be you have any better approach in mind.