I will preface this by saying that I know close to nothing about PD but I am willing to learn if it can help me with the following issue:

I am trying to delay the passage of an inaudible audio signal transiting between two devices. The waveforms we are using are between frequency ranges between 25 KHz and 100 KHz. I realize that it would be almost impossible without specialized equipment to reach the 100 KHz but I figure that with an audio card sampling at 192 KHz I could reach somewhere upwards of 50 KHz.

Here is my issue: can I process this signal in PD to delay the transmission, without modifying it otherwise (ie: no modulation, no decay, a few errors would not be such a big problem but the waveform has to be pretty consistent with what it was in the first place) in PD successfully? Has PD any limitations in the range of audio frequencies it processes?

Thanks for your help

hopefully someone with a bit more of an idea will be able to help you, but here's my thoughts...take it all with a grain of salt though, because i very well could be wrong.

firstly, pd's internal sampling rate is set to 44.1khz by default, which means you can get frequencies up to 22050hz. synthesizing or sampling the highest of those frequencies will lead to aliasing unless you use careful bandlimiting / filtering., etc.

as far as i know, there are two ways to change the samplerate in pd:
(a) you can change the global sample rate in the audio preferences menu (not sure if there is an upper limit though?)
or (b) you can use the [block~] object to upsample. for example [block 64 1 4] would give 4X upsampling, so 44.1khz X 4 = 172.4khz samplerate.

then, the [delwrite~] / [delread~] objects should create a delayed signal at the samplerate you have specified.

the problems i can imagine though, are the aliasing i already mentioned, and then the fact that the analogue audio would be converted to samples once by the soundcard, and then once more by the delayline,

how detailed is the signal you need to send? if you need a lot of subtlety to remain, i think it will be quite difficult, but if you just need to know whether the waveform is positive or negative, then it might be easier.

Just to add a little to what hardoff said...

You also might want to consider how long the delay is. If it's really short, like what you would use in comb filtering, the default vector size of 64 might be a problem. I'm not positive on this, but I think this will give you a minimum delay of 64 samples. You can also change that in [block~], say with [block~ 1 1 4] for a vector size of 1 sample and upsampling of 4x. Someone please correct me if I'm wrong on this. The [vd~] helpfile says something about this, but I'm not fully clear on it. But if all you're doing is delaying the signal, and you keep the [block~] in a subpatch just for the delay and nothing else, I can't imagine it would be too much of a burden on your CPU, so it may not be a bad "just in case."

Also remember that the maximum frequency for a given sample rate in digital audio (half the sampling rate) is more theoretical and a little different in practice. First, slope on the brick wall filters in the a/d converters isn't completely vertical, so those extreme high frequencies get attenuated. And even then, if you could get a 22050 Hz signal in at 44.1 kHz sample rate, the peaks would have to fall right on the samples in order to faithfully replicated the amplitude. So make sure to think of the maximum frequency as a little less than the theoritical maximum.

Oh, and if you delay the signal by an integer number of samples, I don't think you'll have to worry too much about the delay altering it, as it should be an exact copy in that case.

If indeed Pd can handle a sampling rate of 192000 Hz then you should just experiment, as this should be fairly simple to do with relatively easy to obtain equipment. I imagine an oscilloscope will be a good friend.

This also sounds like a problem which Radio Frequency circuit designers would regularly encounter. Some quick research led me to this article, which may be of some value if there isn't an affordable digital solution to your problem: http://mysite.du.edu/~etuttle/electron/elect39.htm