as always: i forgot the attachment........
On Wed, 2007-02-28 at 23:24 +0100, Roman Haefeli wrote:
On Wed, 2007-02-28 at 07:14 -0600, chris clepper wrote:
On 2/28/07, Roman Haefeli reduzierer@yahoo.de wrote:
i might be wrong but in my eyes it doesn't make sense to do all the work that could be done in 50ms in only 1.45ms.What? GEM doesn't use the DSP clock. It will take as much time as needed to render.
oops. ok....
For example, the current work I have uses three or four 1080i clips, a live feed and records to disk and there is no way that all runs in 1.45ms. It takes about 12-15ms!
anyway, i get dropouts when doing gem-rendering, although 'top' tells me that pd uses only 20% cpu-time. i don't care much about the audio (as IOhannes mentioned, i could run two instances of pd). the problem is that the timing is not nice. i'd like to run the patch with 20 frames per second. but in praxis each cycle needs 70ms, which gives me a framerate of 14.
is my gpu too slow? what happens, when the gpu is overloaded? can that cause pd to stuck?
i attached a little gem-benchmark-test. although you say, gem doesn't use the dsp-clock, it takes much longer to compute the first block after a gem-rendering command. why is that? and: here on my system, the [realtime] measures up to 70ms, when i go over [repeat 1400] (under 1400 it's 50ms). the funny thing is, that it stays around 70ms, even if i set the [repeat] up to 3000 or more. why is that? here on my system, cpu-time used by pd is always 20%.
sorry to ask you so much...... but i try to understand things a bit better.......
roman
___________________________________________________________ Der frhe Vogel fngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list