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 <[EMAIL PROTECTED]> 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 _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list