ST30p audio timestamps rounding to packet boundaries - bug or limitation?

[DianaEs2]

It appears that the TAI timestamps provided by the user get rounded/truncated to an audio packet boundary (e.g. ptime 1ms). Is it expected that 2110 audio data can only be provided starting on an audio packet boundary?
It seems no matter what timestamp I proivde to MTL, it's always results in RTP timestamp withich is mutliple to ptime 1ms, (rtp_timestamp % 48 == 0)

[cwhite102]

To add some clarification.
We are providing audio frames to MTL in st30p mode. We have user pacing and timestamps enabled. We provide the TAI time of the first sample in the 10ms frame of data, as we give it to MTL. However, when MTL packetizes the data, the RTP timestamp given to the first packet is not the RTP equivalent of the TAI time we provided. Instead, the MTL algorithm rounded the timestamp to the nearest 1ms boundary from the PTP epoch. This shouldn't be done to the timestamp. The audio data should be allowed to start at any arbitrary point in time.

Ideally, the MTL packetization timestamping should be fixed.
However, if this is not possible, let us know and we will work around the issue by throwing away some data to align the audio to the 1ms boundaries.

This timestamping offset is currently causing audio Tx to fail compliance. It also introduces an offset between the audio and video streams (a lip-sync issue).

The offending code appears to be in:
st_tx_audio_session.c - tx_audio_session_sync_pacing()