@romulovieira-me The audio will arrive pretty much instantaneously at the receiving computer, but the object receiving the audio stream will buffer the data... requesting a resend of corrupt packets.... attempting to prevent dropouts.
That introduces a delay that depends on the size of the buffer.
If you have an oscilloscope you can connect the original audio to one input and the received audio to the other and measure it.
The audio should be a pulse....... every "more than the delay" seconds so that you can see the spikes.
Otherwise use [timer] started by the pulse on the sending computer, and detect the pulse on the receiving computer, and send a message back to the first computer through [netsend] and [netreceive] to stop the timer.
The message coming back should go through with only a minuscule delay (microseconds)..... but in Pd that message will only be processed every 64 audio samples so you could have up to 1.45ms of delay at both ends for the returned message.
It might be possible to timestamp the pulse at each end against internet time for more accuracy if both computers have very recently synced to that.
Or if there are no buffer re-sync requests you could guess (calculate in fact) that the delay will be the length of the buffer of the stream receiver.
That delay will be greater before the sound reaches the speaker of course..... you can add the 1.45ms Pd 64 sample delay and any soundcard latency to that stream buffer.