@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.
David.

@ReLLiK Ah!.... thank you for the info.
David.

@ReLLiK That browser problem is 10 years ago now......

@raynovich The simple way is to buy a second-hand router....... a Linksys WRT54 series can be found for about €10...... just for your project.
Then set the router with an SSID name, wireless security etc.
Then as you connect your phones and your computer choose to set static addresses. That will be remembered by the phones and the computer so that when they connect to this router in the future they will always have the same IP address.
Set them to "connect automatically".
So when you go out to a show and turn on the router all the devices will connect exactly as they did the last time.

Without multicast you will need to set each mobmuplat app to send to a different port (but always the same IP). In [computer_control] you will need a [netreceive] for each of those ports....... and a [netsend] for each phone IP (but always the same port)....
I hope that makes sense.

David.

@raynovich And then wrong again.
I am hoping to find a way around the crazy Mobmuplat internal comms........ but in the meantime here is a working solution....... control.zip

Put control.mmp and control.pd into the mobmuplat folder on your phone.
computer_control.pd runs on your computer.
Set mobmuplat to send to your computer Wi-Fi IP address.
Set computer_control.pd to send to your phone's IP address.

I cannot find any vanilla objects that will talk multicast address...... you would be stuck with 32-bit extended (mrpeach required) if you want to use that.
This with extended will do it (talking with "Tutorial 4 Networking" if you set the network to 224.224.224.1 in mobmuplat....... udpreceive-help.pd

"control" is proof of concept..... simple and probably not the best way..........
David.

@raynovich I had forgotten what I learnt before about Mobmuplat....sorry
It runs a Pd patch on a phone...... but doesn't communicate with anything else over Wi-Fi or Bluetooth.
It just runs a Pd patch on the phone.
So it will not do what you are looking for.

The osc messages in the wrapper are purely for testing the Pd patch before uploading it to the Mobmuplat app.

So you will have to look for free osc apps for apple and android if you don't want to use TouchOSC.

The only other way I can think of at the moment would be to use a VNC app on the phone and share the computer desktop. I will google some more looking for other solutions when I get time.
David.

@raynovich I was involved with some Mobmuplat issues a year ago........ https://forum.pdpatchrepo.info/topic/12748/mobmuplat-grid-not-receiving-message-from-pd/7
The "wrapper" is the important part of Pd that deals with the comms for the Mobmuplat app.
The original "wrapper" was 32-bit MrPeach and I don't know whether it has been updated....
That thread might help..... it was a bit long but got there in the end.
There are some patches toward the end that worked for a "grid" and you could use for testing in Vanilla.
David.

@ricky I think that is just to work out a good window size with enough samples in it but not too many,
The relationship between a semitone interval and frequency is a ratio....... discovered long before digital audio when "samplerate" might have referred to wine tasting (a bit before cocktails too........).
As I said I could be wrong but I cannot see anything in the patch and cannot imagine how the samplerate could be relevant to the [phasor~] frequency.
Sorry about the "arguing"..... and thank you for the link. I always thought Millers book was a real paper thing, and didn't know it was online.
David.

@ricky It's [- 1] because the exponent of 0 (no shift) is 1 but the tape head has to be stationary (no rotation = 0) for playback at normal speed......
And [* -1] because (although it seems wrong until you really think about it) the tape head has to be turning backwards relative to the tape (negative values for [phasor~]...) for the pitch to increase (positive transposition values).
There is no point arguing with the patch because it works as expected.......

[cos~] windows the output so that amplitude sums are "sort of" ok (with the in and out of phase bits) and the vertical edge of the [phasor~] saw is declicked.
And of course the change of delay gives the rotating read head effect.

@katjav gave it a lot more thought here........ https://www.katjaas.nl/pitchshift/pitchshift.html
I could be wrong but I don't see why the samplerate would be part of the calculation (it isn't)...... as all variables are relative.
David

@ingox Yes it looks like Mobmuplat can post messages now so it is an option.
@raynovich Bluetooth range could be a problem on stage..... and especially off stage if they wander about.
David.