Forums > Jitter

Re: is it safe to usurp OpenSoundControl FullPacket messages?

October 25, 2006 | 5:56 pm

On Oct 22, 2006, at 3:45 PM, jennek geels wrote:

> [udpreceive]
> |
> [jit.qball]
> |
> [OpenSoundControl]
>
> but is it safe to usurp "FullPacket" messages output by [udpreceive].
> Or will the usurped FullPacket never be freed from memory?

I don’t believe this will be safe. I would suggest you use something
like the following instead (i.e. use jit.qball after
OpenSoundControl). Or have some means of the client acknowledging the
data before transmitting new data.

> [udpreceive]
> |
> [OpenSoundControl]
> |
> [jit.qball]

I also might plug the udpsend/recv objects which are now standard in
the distribution, or using jit.netsend/recv which can also send
messages (using tcp).

-Joshua


October 25, 2006 | 7:37 pm

On 25-okt-2006, at 17:56, Joshua Kit Clayton wrote:
> On Oct 22, 2006, at 3:45 PM, jennek geels wrote:
>
>> [udpreceive]
>> |
>> [jit.qball]
>> |
>> [OpenSoundControl]
>>
>> but is it safe to usurp "FullPacket" messages output by [udpreceive].
>> Or will the usurped FullPacket never be freed from memory?
>
> I don’t believe this will be safe. I would suggest you use
> something like the following instead (i.e. use jit.qball after
> OpenSoundControl). Or have some means of the client acknowledging
> the data before transmitting new data.
>
>> [udpreceive]
>> |
>> [OpenSoundControl]
>> |
>> [jit.qball]
>
> I also might plug the udpsend/recv objects which are now standard
> in the distribution, or using jit.netsend/recv which can also send
> messages (using tcp).
>
> -Joshua

Joshua,
thanks for your answer.
I have just found the time to run a test:
- send OSC packets at 60 fps from computer A
- recieve them on computer B. keep the receiving max patch busy so
that half of the packets are dropped.
Using Apple’s Activity Monitor to watch real memory, there is a
memory usage increase of 1.5 Mb per minute.
This is not acceptable for a patch that should run all day long.

This seems bad news, but actually it made me discover something
important.
I had to look for another spot in the patch to put the jit.qball in.
And I found out that there is a much better one than between
udpreceive and OpenSoundControl.

The strategy I was after (drop frames as they enter the patch) is wrong.
The incoming frames build up state in the receiving patch, state
which accumulates over multiple frames.
This state is rendered to video and audio.
It is OK to slow down rendering, but it is a flaw to drop state changes.
So now I keep the updreceive generated events at high priority, up to
the point where they have
fully propagated to the client state.
Next I pass the bang that drives all the rendering thru jit.qball.
Thus the frame rate of
the renderer may drop from 60 fps to whatever, without freezing the
patch or missing state transitions.
This is with max in overdrive.

I have been struggling with this for over a week now, and today it
all fell into place.
Key ingredients:
- your article "Event Priority in Max (Scheduler vs. Queue)"
- Trond Lossius’ pointer to the java goodie ‘WhichThread.help’
Both are great resources that deserve much more attention.
I hope they will make it into a Max Topics chapter one day.

What a wonderful resource this community is.
-jennek


Viewing 2 posts - 1 through 2 (of 2 total)