what do you consider many? i counted 8 [line~]s and 4 [vline~]s in the main patch. the main patch is using 10 instances of an abstraction, that has a [line~], so the sum of all is around 22 [line~] objects.
i could narrow it a little bit down. i replaced the tracker patch by a dummy data sending patch and indeed:
if i send the same message to the audio patch with a constant rate (16.66ms, respectively 60Hz), there are no dropouts. now, if i alternate between two different messages at the same rate, the audio patch just keeps stuttering, while the cpu load increases from 55% to ~70%.
i also tried a much lower rate: 100ms (10Hz) and 200ms (5Hz) and even with 5 messages per second, there are dropouts.... strange....
the same test on the other (slower) box doesn't cause any drop-outs.
i am a bit stumped.
roman
On Sat, 2008-05-17 at 19:17 +0100, Andy Farnell wrote:
Roman, are you using many [line] objects to interpolate the incoming tracker data?
On Sat, 17 May 2008 20:08:26 +0200 Roman Haefeli reduzierer@yahoo.de wrote:
hi all
i am setting up a box for an installation. it runs two instances of pd:
audio: pd -rt -jack (with only very few externals loaded)
tracking: pd -nrt -noaudio (with quite a lot of externals loaded, such as Gem, comport, wiimote and others).
both instances talk with each other over two [netsend]/[netreceive] connections (one for each way). the main part of the tcp connection bandwith is tracking data sent from the tracking patch to the audio patch at fixed rate, where each message is 12 floats long.
all that runs fine and smooth on my own mobile box: pentium M 1.7GHz 1.5GB RAM ubuntu dapper pd 0.40.3 over jack (48KHz, 1024 frames/period, 2 periods/buffer ) cpu usage is around 80%
the same two patches on the installation box cause lots of drop-outs: AMD Athlon XP 2.8GHz 512MB RAM ubuntu gutsy with rt-kernel and everything setup for low-latency pd 0.40.3 (with same jackd settings) cpu usage around 60%
funny enough, that the much faster machine with the more appropriate setup (rt-kernel) is having the drop-outs. usually i would suspect [netsend] or [netreceive] to be the cause of the problem. but in this case the data rate sent over the tcp socket is constant, whereas the dropouts only happen, if the tracking data changes values, but not, if the stream from the tracking patch keeps sending the same values. the major part of the audio patch is just some synth stuff, that is constantly running, so there aren't big jumps in cpu usage expected. from what i can tell, the only thing, that happens in the audio patch, when the received stream changes its values, is, that around 10 [partconv~] objects switch tables from a preloaded set of around 1400 tables, where each table is 512 samples long. i don't have an explanation, why this could affect audio (and why it doesn't on my slower mobile box), but this is what i observed. i am happy with any possible explanation of that behaviour and even more with an idea how to solve it. i really would like to avoid not to have to use my personal laptop for the installation.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de