hello martin peach
i tested your external a bit more deep on the 'good' soundcard, where i can exclude aliasing introduced by the soundcard. it turned out, that a bit of aliasing is audible in the range above 5000Hz. i think this is not tooo bad, maybe for 'pure'ists. but i had serious troubles, when loading some patches, that contain [sqosc~]. it can happen, that after loading the patch, pd is sending constantly a dc to my soundcard. even when i close pd, the dc stays on these channels, where pd was connected before over jack. to get rid of the dc, i must restart jackd again. because of that, i assume it is related to jackd (is it possible to crash jackd from pd?). i attached a test-patch. when loading that patch, jackd (and pd) get unusable for sure.
my system: ubuntu dapper i386 pd-0.40.2 jackd 0.100.0
when i create a patch from scratch with [sqosc~], i have no troubles. i get the dc also, when i open the help-patch of [sqosc~].
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Sun, Mar 25, 2007 at 07:23:13PM +0200, Roman Haefeli wrote:
[sqosc~]. it can happen, that after loading the patch, pd is sending constantly a dc to my soundcard. even when i close pd, the dc stays on these channels, where pd was connected before over jack. to get rid of
This happens on my laptop and I am pretty sure it occurs on a hardware level (in my case). The DC is present sometimes after just playing half an mp3 file and then hitting ctrl-C, and definately happens when doing stuff in Pd sometimes.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
Chris McCormick wrote:
On Sun, Mar 25, 2007 at 07:23:13PM +0200, Roman Haefeli wrote:
[sqosc~]. it can happen, that after loading the patch, pd is sending constantly a dc to my soundcard. even when i close pd, the dc stays on these channels, where pd was connected before over jack. to get rid of
This happens on my laptop and I am pretty sure it occurs on a hardware level (in my case). The DC is present sometimes after just playing half an mp3 file and then hitting ctrl-C, and definately happens when doing stuff in Pd sometimes.
How can you guys tell if there's DC in the signal? I'd love to get a sound card that outputs DC!
Martin
On Sun, 2007-03-25 at 21:46 -0400, Martin Peach wrote:
Chris McCormick wrote:
On Sun, Mar 25, 2007 at 07:23:13PM +0200, Roman Haefeli wrote:
[sqosc~]. it can happen, that after loading the patch, pd is sending constantly a dc to my soundcard. even when i close pd, the dc stays on these channels, where pd was connected before over jack. to get rid of
This happens on my laptop and I am pretty sure it occurs on a hardware level (in my case). The DC is present sometimes after just playing half an mp3 file and then hitting ctrl-C, and definately happens when doing stuff in Pd sometimes.
How can you guys tell if there's DC in the signal? I'd love to get a sound card that outputs DC!
hehe, actually i am not sure, if my soundcard physically outputs dc or if the output is high pass filtered. maybe i should elaborate a bit more my setup and what i did in order to explain, why i assume dc on the output.
i run pd over jackd and jackd runs on the rme card. the hdspmixer has a levelmeter for each input and output, so i can see the signal-levels that are sent from jackd to the outputs of the card.
here the jack-routing: pd out 1 -> hdsp out 1 pd out 2 -> hdsp out 2
now, when i load the help-patch of [sqosc~], the level-meters of hdsp out 1 and 2 show full amplitude and i hear a hard click on the loudspeakers (similar to the sound, when sending dc to the speakers). when i close the patch, the amplitude remains. when i disconnect pd from jack, the amplitude goes away and i hear a hard click again. but even if i restart pd, the amplitude comes immediately again (with the loud click, of course). also if i connect other softwares over jack to the hdsp out 1 and 2, the high amplitude comes again. to get rid of that, i must restart jack. but as soon as i load the help-patch of [sqosc~] again, i have the same situation again (loud click and full amplitude on the meters). i don't know of any other setup with that behaviour. this happens only, when i load a patch with one or more [sqosc~]s. that is why i assume, it is (at least a bit) related to [sqosc~].
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
hi again
i've come a bit closer to the source of the problem:
when i load patch that contains a [sqosc~], whose first inlet~ is connected with a tilde-object, that sends a zero-signal immediately after loading the patch (e.g [line~]), the first outlet~ of [sqosc~] sends a 'nan' (not a number?). at least, this is what [env~]-[nbx] tells me. when i change the frequency to some non-zero value and change it back to zero, [env~]-[nbx] says '96.47', which is the expected value, i think. i assume, this 'nan'-signal is the reason, why my jackd goes crazy. the problem does not occur anymore when i send [0.001, 0 1( to the [line~] on loadbang.
i attached a little test-patch to show you, what happens here. i couldn't test it on other systems/versions of pd/audio-apis.
roman
On Sun, 2007-03-25 at 21:46 -0400, Martin Peach wrote:
Chris McCormick wrote:
On Sun, Mar 25, 2007 at 07:23:13PM +0200, Roman Haefeli wrote:
[sqosc~]. it can happen, that after loading the patch, pd is sending constantly a dc to my soundcard. even when i close pd, the dc stays on these channels, where pd was connected before over jack. to get rid of
This happens on my laptop and I am pretty sure it occurs on a hardware level (in my case). The DC is present sometimes after just playing half an mp3 file and then hitting ctrl-C, and definately happens when doing stuff in Pd sometimes.
How can you guys tell if there's DC in the signal? I'd love to get a sound card that outputs DC!
Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I get "nan" when I blow up a filter or delay line. It's synonymous with pure DC offset to me. The soundcard of course filters it, but it's basically a pure positive or negative signal up to that point. Some LADSPAs do it to me as well, like "Foldover Distortion" and some others.
best, d.
Roman Haefeli wrote:
hi again
i've come a bit closer to the source of the problem:
when i load patch that contains a [sqosc~], whose first inlet~ is connected with a tilde-object, that sends a zero-signal immediately after loading the patch (e.g [line~]), the first outlet~ of [sqosc~] sends a 'nan' (not a number?). at least, this is what [env~]-[nbx] tells me. when i change the frequency to some non-zero value and change it back to zero, [env~]-[nbx] says '96.47', which is the expected value, i think. i assume, this 'nan'-signal is the reason, why my jackd goes crazy. the problem does not occur anymore when i send [0.001, 0 1( to the [line~] on loadbang.
i attached a little test-patch to show you, what happens here. i couldn't test it on other systems/versions of pd/audio-apis.
roman
On Sun, 2007-03-25 at 21:46 -0400, Martin Peach wrote:
Chris McCormick wrote:
On Sun, Mar 25, 2007 at 07:23:13PM +0200, Roman Haefeli wrote:
[sqosc~]. it can happen, that after loading the patch, pd is sending constantly a dc to my soundcard. even when i close pd, the dc stays on these channels, where pd was connected before over jack. to get rid of
This happens on my laptop and I am pretty sure it occurs on a hardware level (in my case). The DC is present sometimes after just playing half an mp3 file and then hitting ctrl-C, and definately happens when doing stuff in Pd sometimes.
How can you guys tell if there's DC in the signal? I'd love to get a sound card that outputs DC!
Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
#N canvas 276 167 640 276 10; #X obj 25 80 sqosc~ 300 0.5 15000; #X obj 25 103 env~; #X floatatom 25 125 0 0 0 0 - - -; #X obj 25 53 sig~ 0; #X obj 227 76 sqosc~ 300 0.5 15000; #X obj 227 99 env~; #X floatatom 227 121 0 0 0 0 - - -; #X obj 227 50 sig~ 1; #X text 226 28 non-zero signal; #X text 27 27 zero signal; #X text 84 129 <- nan; #X text 287 123 <- 96.48; #X obj 448 142 sqosc~ 300 0.5 15000; #X obj 448 165 env~; #X floatatom 448 187 0 0 0 0 - - -; #X obj 447 65 loadbang; #X text 443 29 solution; #X msg 447 91 5 , 0 1; #X obj 447 118 line~; #X text 505 190 <- 96.48; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 3 0 0 0; #X connect 4 0 5 0; #X connect 5 0 6 0; #X connect 7 0 4 0; #X connect 12 0 13 0; #X connect 13 0 14 0; #X connect 15 0 17 0; #X connect 17 0 18 0; #X connect 18 0 12 0;
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 3/26/07, Derek Holzer derek@umatic.nl wrote:
I get "nan" when I blow up a filter or delay line. It's synonymous with pure DC offset to me. The soundcard of course filters it, but it's basically a pure positive or negative signal up to that point. Some LADSPAs do it to me as well, like "Foldover Distortion" and some others.
I've generated some inf and -inf's, before when trying to write externals... To my recollection, those numbers were treated as 0's when passed through an outlet (returned by the function). Your explanation makes a lot of sense, but it still seems like a mystery to me.
Chuck
Roman Haefeli wrote:
hi again
i've come a bit closer to the source of the problem:
when i load patch that contains a [sqosc~], whose first inlet~ is connected with a tilde-object, that sends a zero-signal immediately after loading the patch (e.g [line~]), the first outlet~ of [sqosc~] sends a 'nan' (not a number?). at least, this is what [env~]-[nbx] tells me.
Thanks for the feedback Roman. I just now put a modified sqosc~.c in cvs; it calls finite() to detect NaNs and replace them with zeros. I only tested it on WinXP so far. Maybe you could try the new version and see if it works better. Thanks, Martin
I get this too. It's never seemed worth filing a bug report because it's not clear whether Pd or an external or Jack itself it where the problem occurs. Sometimes a channel just locks up and all I can get is nans until the application is restarted. It's quite rare, but annoying if it happens during a talk or performance.
Andy
On Mon, 26 Mar 2007 09:14:22 +0800 Chris McCormick chris@mccormick.cx wrote:
On Sun, Mar 25, 2007 at 07:23:13PM +0200, Roman Haefeli wrote:
[sqosc~]. it can happen, that after loading the patch, pd is sending constantly a dc to my soundcard. even when i close pd, the dc stays on these channels, where pd was connected before over jack. to get rid of
This happens on my laptop and I am pretty sure it occurs on a hardware level (in my case). The DC is present sometimes after just playing half an mp3 file and then hitting ctrl-C, and definately happens when doing stuff in Pd sometimes.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
After having done lots of work with recursive feedback structures in PD using delays and filters, I can positively say that PD (rather then Jack) is making the problem in every one of my cases. YMMV. But for me, it always happens when delay lines or resonant filters become feedback saturated to the point of being pure DC. The offending object must then be cut and pasted (i.e. reset) to get rid of the "nan" signal, so try cut/paste rather than restart and see if it helps you next time. I've always considered this something that is inherent in DSP with no sanity checks, as PD often is, rather than a bug specific to PD. The CSound manual mentions this "blowing up" of filters quite frequently, so I know it happens in other applications.
best, d.
padawan12 wrote:
I get this too. It's never seemed worth filing a bug report because it's not clear whether Pd or an external or Jack itself it where the problem occurs. Sometimes a channel just locks up and all I can get is nans until the application is restarted. It's quite rare, but annoying if it happens during a talk or performance.
Does anyone know how to tell, in c, if you're getting nans? It should be easy enough in the dsp routine to replace nans with zeros. It's just a question of detecting them in time. I remember you could do it in SANE, the old Apple math system, there was some function like isnan(). I don't see how [sqosc~] could be generating them though, since it's deliberately operating in a fixed range of float, the same way [osc~] does.
Martin
Derek Holzer wrote:
After having done lots of work with recursive feedback structures in PD using delays and filters, I can positively say that PD (rather then Jack) is making the problem in every one of my cases. YMMV. But for me, it always happens when delay lines or resonant filters become feedback saturated to the point of being pure DC. The offending object must then be cut and pasted (i.e. reset) to get rid of the "nan" signal, so try cut/paste rather than restart and see if it helps you next time. I've always considered this something that is inherent in DSP with no sanity checks, as PD often is, rather than a bug specific to PD. The CSound manual mentions this "blowing up" of filters quite frequently, so I know it happens in other applications.
best, d.
padawan12 wrote:
I get this too. It's never seemed worth filing a bug report because it's not clear whether Pd or an external or Jack itself it where the problem occurs. Sometimes a channel just locks up and all I can get is nans until the application is restarted. It's quite rare, but annoying if it happens during a talk or performance.
On 3/26/07, Martin Peach martin.peach@sympatico.ca wrote:
Does anyone know how to tell, in c, if you're getting nans? It should be easy enough in the dsp routine to replace nans with zeros. It's just a question of detecting them in time. I remember you could do it in SANE, the old Apple math system, there was some function like isnan().
I'm reading through the math headers, and there's functions isinf(x) and isnan(x) I'm not yet sure of the syntax.... it's not so common to see these, like this. Typically the math functions will add 'f' at the end to denote a float argument, instead of a double. Probably there's more I haven't found yet
I don't see how [sqosc~] could be generating them though, since it's deliberately operating in a fixed range of float, the same way [osc~] does.
it is coming from tabosc~ (I think)... it's just one of those problems where the lack of default arguments leads to an unexpected result...
okay, (on linux) you find math.h in /usr/include/ which includes a file /usr/include/bits/mathcalls.h there are three functions int finite(double x) -- returns 1, if x is not NaN or inf int isinf(double x) -- returns 1, if x is inf or -inf int isnan(double x) -- returns 1, if x is NaN
int finitef(float x), int isnanf(float x), and int isinff(float x) are the float versions.
Thanks, Charles, For Windows, I found int _isnan(double x) in float.h; it returns non-zero if x is NaN. Also in float.h, int _finite(double x) returns zero if the number is +- infinite or a NaN, so that would seem to cover every possibility. and int _fpclass(double x) returns a specific code for each type of NaN as well as zero and non-zero numbers. There don't seem to be any float versions of these. If the overhead is not too high it would make sense to use one of these in any dsp routine that might generate such values. Ideally it should be on the input to [dac~] so it only needs to be called once per sample, but I'll try it on sqosc~ to see what happens...
Martin
Charles Henry wrote:
okay, (on linux) you find math.h in /usr/include/ which includes a file /usr/include/bits/mathcalls.h there are three functions int finite(double x) -- returns 1, if x is not NaN or inf int isinf(double x) -- returns 1, if x is inf or -inf int isnan(double x) -- returns 1, if x is NaN
int finitef(float x), int isnanf(float x), and int isinff(float x) are the float versions.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, 2007-03-27 at 01:37 +0200, Derek Holzer wrote:
After having done lots of work with recursive feedback structures in PD using delays and filters, I can positively say that PD (rather then Jack) is making the problem in every one of my cases. YMMV. But for me, it always happens when delay lines or resonant filters become feedback saturated to the point of being pure DC. The offending object must then be cut and pasted (i.e. reset) to get rid of the "nan" signal, so try cut/paste rather than restart and see if it helps you next time.
sometimes it helps to delete the object, that outputs a 'nan'-signal. but sometimes, as andy said, just cutting this object doesn't help to get rid of the 'nan'. i even had some cases, where i had to restart jackd. i don't know the internals behind pd/jackd, but i can say for sure, that it is _possible_ to turn jackd unusuable with a 'nan'-signal (i don't say, it happens each time). but i can't tell, whether pd or jackd is the cause of the problem (maybe both?).
roman
I've always considered this something that is inherent in DSP with no sanity checks, as PD often is, rather than a bug specific to PD. The CSound manual mentions this "blowing up" of filters quite frequently, so I know it happens in other applications.
best, d.
padawan12 wrote:
I get this too. It's never seemed worth filing a bug report because it's not clear whether Pd or an external or Jack itself it where the problem occurs. Sometimes a channel just locks up and all I can get is nans until the application is restarted. It's quite rare, but annoying if it happens during a talk or performance.
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
-
Charles Henry -
Chris McCormick -
Derek Holzer -
Martin Peach -
padawan12 -
Roman Haefeli