Hello,
I tested pd 0.40-2 (its also in Debian Lenny) on 64 Studio and still got the table writing bug, where all tables are modulated with a square wave. Isnt it supposed to be absent from 0.40 onwards?
Cheers,
Malte
Malte Steiner media art + development -www.block4.com-
next concert: Elektronengehirn 30.8. ICMC 2007, Copenhagen, Denmark
I think most of the 64-bit bugs only got cleaned up for 0.41 (and the test version in CVS is pretty stable at the moment)
cheers M
On Thu, Aug 16, 2007 at 02:37:34AM +0200, Malte Steiner wrote:
Hello,
I tested pd 0.40-2 (its also in Debian Lenny) on 64 Studio and still got the table writing bug, where all tables are modulated with a square wave. Isnt it supposed to be absent from 0.40 onwards?
Cheers,
Malte
Malte Steiner media art + development -www.block4.com-
next concert: Elektronengehirn 30.8. ICMC 2007, Copenhagen, Denmark
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Miller Puckette wrote:
I think most of the 64-bit bugs only got cleaned up for 0.41 (and the test version in CVS is pretty stable at the moment)
ok, I give it a try tomorrow and post back here. Thanks for the info,
Malte
Am Donnerstag, 16. August 2007 03:59 schrieb Malte Steiner:
Miller Puckette wrote:
I think most of the 64-bit bugs only got cleaned up for 0.41 (and the test version in CVS is pretty stable at the moment)
ok, I give it a try tomorrow and post back here. Thanks for the info,
just run 0.41 on 64studio 64 bit and a complex patch (CUBEmixer) just run fine. But the disk access makes a DAC-slip on the 2.6.22 realtime kernel, much worse than on non-realtimekernel. Is there anything to adjust on the kernel site to get better disk access scheduling ?
mfg winfried
I've been getting various real-time problems too, but I'm not sure whether to blame the new Pd version, or the 64-bit kernel, or the new machines I'm running it on.
Just to make things one bit more compicated, I've updated the included version of portaudio and added optional callback scheduling too -- I'll probably upload changes to CVS after another day or so of testing.
cheers Miller
On Thu, Aug 16, 2007 at 11:25:17AM +0200, Winfried Ritsch wrote:
Am Donnerstag, 16. August 2007 03:59 schrieb Malte Steiner:
Miller Puckette wrote:
I think most of the 64-bit bugs only got cleaned up for 0.41 (and the test version in CVS is pretty stable at the moment)
ok, I give it a try tomorrow and post back here. Thanks for the info,
just run 0.41 on 64studio 64 bit and a complex patch (CUBEmixer) just run fine. But the disk access makes a DAC-slip on the 2.6.22 realtime kernel, much worse than on non-realtimekernel. Is there anything to adjust on the kernel site to get better disk access scheduling ?
mfg winfried
--
- ao.Univ.Prof. DI Winfried Ritsch
- ritsch@iem.at - http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171
- PGP-ID 69617A69 (see keyserver http://wwwkeys.eu.gpg.net/)
--
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Just to make things one bit more compicated, I've updated the included version of portaudio and added optional callback scheduling too -- I'll probably upload changes to CVS after another day or so of
testing.
I'm very curious about your implementation. Tim and I had to make
various tricky things to achieve proper timing and audio device
configuration within devel_0_39. I'll check in some more fixes
hopefully tomorrow. Looking forward to the pdconf!
greetings, Thomas
Hello,
I've been getting various real-time problems too, but I'm not sure whether to blame the new Pd version, or the 64-bit kernel, or the new machines I'm running it on.
Just to make things one bit more compicated, I've updated the included version of portaudio and added optional callback scheduling too -- I'll probably upload changes to CVS after another day or so of testing.
just found out that afeter 2hours and more, netconnections between GUI-Instance and PD-DSP become notible long (> 300ms), maybe the networking ?
But since one rule is, never guess, measure why, I have a quick question. Is there a profiling tool on oject or message base ? I can remember there was one in Max/FTS, so I can find out the bad objects... ?
mfg winfried
cheers Miller
On Thu, Aug 16, 2007 at 11:25:17AM +0200, Winfried Ritsch wrote:
Am Donnerstag, 16. August 2007 03:59 schrieb Malte Steiner:
Miller Puckette wrote:
I think most of the 64-bit bugs only got cleaned up for 0.41 (and the test version in CVS is pretty stable at the moment)
ok, I give it a try tomorrow and post back here. Thanks for the info,
just run 0.41 on 64studio 64 bit and a complex patch (CUBEmixer) just run fine. But the disk access makes a DAC-slip on the 2.6.22 realtime kernel, much worse than on non-realtimekernel. Is there anything to adjust on the kernel site to get better disk access scheduling ?
mfg winfried
--
- ao.Univ.Prof. DI Winfried Ritsch
- ritsch@iem.at - http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171
- PGP-ID 69617A69 (see keyserver http://wwwkeys.eu.gpg.net/)
--
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
d'oh... no such tools in Pd. (Was there suc ha thing in Max/FTS? I don't remember it :)
cheers M
On Fri, Aug 17, 2007 at 11:07:08AM +0200, Winfried Ritsch wrote:
Hello,
I've been getting various real-time problems too, but I'm not sure whether to blame the new Pd version, or the 64-bit kernel, or the new machines I'm running it on.
Just to make things one bit more compicated, I've updated the included version of portaudio and added optional callback scheduling too -- I'll probably upload changes to CVS after another day or so of testing.
just found out that afeter 2hours and more, netconnections between GUI-Instance and PD-DSP become notible long (> 300ms), maybe the networking ?
But since one rule is, never guess, measure why, I have a quick question. Is there a profiling tool on oject or message base ? I can remember there was one in Max/FTS, so I can find out the bad objects... ?
mfg winfried
cheers Miller
On Thu, Aug 16, 2007 at 11:25:17AM +0200, Winfried Ritsch wrote:
Am Donnerstag, 16. August 2007 03:59 schrieb Malte Steiner:
Miller Puckette wrote:
I think most of the 64-bit bugs only got cleaned up for 0.41 (and the test version in CVS is pretty stable at the moment)
ok, I give it a try tomorrow and post back here. Thanks for the info,
just run 0.41 on 64studio 64 bit and a complex patch (CUBEmixer) just run fine. But the disk access makes a DAC-slip on the 2.6.22 realtime kernel, much worse than on non-realtimekernel. Is there anything to adjust on the kernel site to get better disk access scheduling ?
mfg winfried
--
- ao.Univ.Prof. DI Winfried Ritsch
- ritsch@iem.at - http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171
- PGP-ID 69617A69 (see keyserver http://wwwkeys.eu.gpg.net/)
--
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Miller Puckette wrote:
d'oh... no such tools in Pd. (Was there suc ha thing in Max/FTS? I don't remember it :)
I remember a performance by Ben Bogart on last years Piksel tapping pds internal network communication and listen to its heartbeat, maybe that can be abused? Ben?
Cheers,
Malte
Am Freitag, 17. August 2007 17:41 schrieb Miller Puckette:
d'oh... no such tools in Pd. (Was there suc ha thing in Max/FTS? I don't remember it :)
maybe its to long ago, but I thought in max/fts you could print out a "time of operation of each object in the dsp-stack over an amount of ticks on the console, but maybe I am wrong and only we did it an IEM to track down DSP-efficiency.
mfg winfried
cheers M
On Fri, Aug 17, 2007 at 11:07:08AM +0200, Winfried Ritsch wrote:
Hello,
I've been getting various real-time problems too, but I'm not sure whether to blame the new Pd version, or the 64-bit kernel, or the new machines I'm running it on.
Just to make things one bit more compicated, I've updated the included version of portaudio and added optional callback scheduling too -- I'll probably upload changes to CVS after another day or so of testing.
just found out that afeter 2hours and more, netconnections between GUI-Instance and PD-DSP become notible long (> 300ms), maybe the networking ?
But since one rule is, never guess, measure why, I have a quick question. Is there a profiling tool on oject or message base ? I can remember there was one in Max/FTS, so I can find out the bad objects... ?
mfg winfried
cheers Miller
On Thu, Aug 16, 2007 at 11:25:17AM +0200, Winfried Ritsch wrote:
Am Donnerstag, 16. August 2007 03:59 schrieb Malte Steiner:
Miller Puckette wrote:
I think most of the 64-bit bugs only got cleaned up for 0.41 (and the test version in CVS is pretty stable at the moment)
ok, I give it a try tomorrow and post back here. Thanks for the info,
just run 0.41 on 64studio 64 bit and a complex patch (CUBEmixer) just run fine. But the disk access makes a DAC-slip on the 2.6.22 realtime kernel, much worse than on non-realtimekernel. Is there anything to adjust on the kernel site to get better disk access scheduling ?
mfg winfried
--
- ao.Univ.Prof. DI Winfried Ritsch
- ritsch@iem.at - http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171
- PGP-ID 69617A69 (see keyserver http://wwwkeys.eu.gpg.net/)
--
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 17 Aug 2007, Winfried Ritsch wrote:
But since one rule is, never guess, measure why, I have a quick question. Is there a profiling tool on oject or message base ? I can remember there was one in Max/FTS, so I can find out the bad objects... ?
Since I reimplemented the stack overflow checker so that it really checks every sent message, it's now easier to make a profiler. Actually, I just made one tonight, when reading your email. It looks like this:
http://artengine.ca/desiredata/gallery/simple-benchmark.png
those green numbers represent real time, measured hierarchically (that is, all sent messages count as part of the sender), whereas it could have excluded sent messages so that all visible times add up (either is more useful than the other sometimes). It is an exhaustive measurement, that is, every message is counted, whereas it could be statistical instead, using unix alarms to make statistics on stack snapshots.
You make the green numbers appear by selecting "get elapsed" from the View menu.
This example was made from making a few clicks on the messagebox and it is measured such that 1 unit = 800000000 cpu ticks. in practice my cpu switched to a higher speed. Correct profiling involves setting the speed of the cpu to a fixed value so that the values can be displayed in actual seconds.
If you want to try it out we could meet online and set it up on your computer.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
Malte Steiner -
Mathieu Bouchard -
Miller Puckette -
Thomas Grill -
Winfried Ritsch