Hello everyone,
I have recently downloaded PD and I am using it to estimate the acoustic response of a room. To do this, I am following the procedure described at http://cnx.org/content/m15945/latest/.
However, I have a question about how Pure Data works when I simultaneously play a waveform and record the output using a microfone (that is required for the estimate). Is the clock frequency of the D/A converter which produces the output syncrhonized with the clock frequency of the A/D converter wich produces the recorded signal?
That is a very important question when trying to measure an acoustic response, and I couldn't find the answer at puredata.info website.
Regards,
-- Henrique Goulart University of São Paulo, Brasil
On Sun, 4 Jul 2010, Henrique wrote:
However, I have a question about how Pure Data works when I simultaneously play a waveform and record the output using a microfone (that is required for the estimate). Is the clock frequency of the D/A converter which produces the output syncrhonized with the clock frequency of the A/D converter wich produces the recorded signal? That is a very important question when trying to measure an acoustic response, and I couldn't find the answer at puredata.info website.
The total delay is the sum of the logical delay as written in the audio settings dialogue of Pd, plus the digital in-delay and out-delay of the soundcard and/or driver, plus any analogue delay introduced by the soundcard due to filtering, plus the microphone's delay, plus the speaker's delay, plus the room's delay (relative to position and orientation of both speaker and microphone).
In the end, any digital delay can be counted by easy addition, whereas the analogue delays are frequency-dependent and thus have to be counted as filters. So, to measure a room's response, you'd first just subtract the digital delay, but after that, for the analogue effects, you'd need to deconvolve instead (but I suppose that you already know that).
It may be tricky to know the digital delay beforehand... but if you put the microphone and speaker really next (in)to each other, then just look in your recording for the point when the response begins, then it might be quite close to a digital delay, IF your impulsion contains enough high-frequencies. But I don't know how close it is, as I haven't tried it.
The total digital delay is soundcard-dependent, driver-dependent, and OS-dependent, on top of being dependent on a setting in pd.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Thanks for your observation, Mathieu.
However, I think the total delay itself is not a problem, because it will appear in my acoustic response estimate. That is, if I compute the convolution of the estimated impulse response with the excitation signal, the result should have the same delay (assuming the convolutive model is valid). So, both the digital delay and the analog filtering that occur are also part of my estimated acoustic response.
But, in order to the IR estimation be correct, there must be a synchronization between the clock frequencies of the: (1) D/A converter at the output generator and the (2) A/D converter on the input recorder. If the "sampling ticks" of these clocks are not (at least approximately) synchronized, then a significant error is expected on the estimate.
-- Henrique
On Sun, Jul 4, 2010 at 5:12 PM, Mathieu Bouchard matju@artengine.ca wrote:
On Sun, 4 Jul 2010, Henrique wrote:
However, I have a question about how Pure Data works when I simultaneously
play a waveform and record the output using a microfone (that is required for the estimate). Is the clock frequency of the D/A converter which produces the output syncrhonized with the clock frequency of the A/D converter wich produces the recorded signal? That is a very important question when trying to measure an acoustic response, and I couldn't find the answer at puredata.info website.
The total delay is the sum of the logical delay as written in the audio settings dialogue of Pd, plus the digital in-delay and out-delay of the soundcard and/or driver, plus any analogue delay introduced by the soundcard due to filtering, plus the microphone's delay, plus the speaker's delay, plus the room's delay (relative to position and orientation of both speaker and microphone).
In the end, any digital delay can be counted by easy addition, whereas the analogue delays are frequency-dependent and thus have to be counted as filters. So, to measure a room's response, you'd first just subtract the digital delay, but after that, for the analogue effects, you'd need to deconvolve instead (but I suppose that you already know that).
It may be tricky to know the digital delay beforehand... but if you put the microphone and speaker really next (in)to each other, then just look in your recording for the point when the response begins, then it might be quite close to a digital delay, IF your impulsion contains enough high-frequencies. But I don't know how close it is, as I haven't tried it.
The total digital delay is soundcard-dependent, driver-dependent, and OS-dependent, on top of being dependent on a setting in pd.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
As far as I know: sampling ticks-sync from A/D or D/A is a responsibility of the soundcard (or at least all the architecture behind it: a/d + soundcard driver). Pd just accesses that to fetch the values or to write to it, It wouldn't make any sense that it would change the sync* - but maybe someone with deeper knowledge of pd-arch can assure that.
*I'm thinking from a point of view of audio applications that I've prototyped in the past from scratch (C), there's no access besides reading or writing data to the audio buffers provided by the OS, so apart from the latency that the audio app adds (apart form all the other latency that Mathieu already pointed out) it shouldn't interfere with the sampling sync, that's responsibility of the sound card[1]
[1] Some cards offer you their own sample-sync possibilities such as some MOTU hardware... ( http://www.motu.com/techsupport/technotes/phase-accurate-versus-sample-accur...) although I do not recommend MOTU =P
On Sun, Jul 4, 2010 at 9:26 PM, Henrique jhgoulart@gmail.com wrote:
Thanks for your observation, Mathieu.
However, I think the total delay itself is not a problem, because it will appear in my acoustic response estimate. That is, if I compute the convolution of the estimated impulse response with the excitation signal, the result should have the same delay (assuming the convolutive model is valid). So, both the digital delay and the analog filtering that occur are also part of my estimated acoustic response.
But, in order to the IR estimation be correct, there must be a synchronization between the clock frequencies of the: (1) D/A converter at the output generator and the (2) A/D converter on the input recorder. If the "sampling ticks" of these clocks are not (at least approximately) synchronized, then a significant error is expected on the estimate.
-- Henrique
On Sun, Jul 4, 2010 at 5:12 PM, Mathieu Bouchard matju@artengine.cawrote:
On Sun, 4 Jul 2010, Henrique wrote:
However, I have a question about how Pure Data works when I
simultaneously play a waveform and record the output using a microfone (that is required for the estimate). Is the clock frequency of the D/A converter which produces the output syncrhonized with the clock frequency of the A/D converter wich produces the recorded signal? That is a very important question when trying to measure an acoustic response, and I couldn't find the answer at puredata.info website.
The total delay is the sum of the logical delay as written in the audio settings dialogue of Pd, plus the digital in-delay and out-delay of the soundcard and/or driver, plus any analogue delay introduced by the soundcard due to filtering, plus the microphone's delay, plus the speaker's delay, plus the room's delay (relative to position and orientation of both speaker and microphone).
In the end, any digital delay can be counted by easy addition, whereas the analogue delays are frequency-dependent and thus have to be counted as filters. So, to measure a room's response, you'd first just subtract the digital delay, but after that, for the analogue effects, you'd need to deconvolve instead (but I suppose that you already know that).
It may be tricky to know the digital delay beforehand... but if you put the microphone and speaker really next (in)to each other, then just look in your recording for the point when the response begins, then it might be quite close to a digital delay, IF your impulsion contains enough high-frequencies. But I don't know how close it is, as I haven't tried it.
The total digital delay is soundcard-dependent, driver-dependent, and OS-dependent, on top of being dependent on a setting in pd.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Henrique wrote:
But, in order to the IR estimation be correct, there must be a synchronization between the clock frequencies of the: (1) D/A converter at the output generator and the (2) A/D converter on the input recorder. If the "sampling ticks" of these clocks are not (at least approximately) synchronized, then a significant error is expected on the estimate.
As long as they are on the same card, they will be in perfect sync at the clock level unless you have some really unusual hardware. This is because the same clock is used for A/D and D/A. Usually they are on the same chip and the data from the ADC is clocked out using the same clock that loads the DAC.
Martin
Ok, I guess that's good news then :)
Thank you all for helping me in this question.
Regards,
-- Henrique
On Sun, Jul 4, 2010 at 6:40 PM, Martin Peach martin.peach@sympatico.cawrote:
Henrique wrote:
But, in order to the IR estimation be correct, there must be a
synchronization between the clock frequencies of the: (1) D/A converter at the output generator and the (2) A/D converter on the input recorder. If the "sampling ticks" of these clocks are not (at least approximately) synchronized, then a significant error is expected on the estimate.
As long as they are on the same card, they will be in perfect sync at the clock level unless you have some really unusual hardware. This is because the same clock is used for A/D and D/A. Usually they are on the same chip and the data from the ADC is clocked out using the same clock that loads the DAC.
Martin
On Sun, 4 Jul 2010, Martin Peach wrote:
As long as they are on the same card, they will be in perfect sync at the clock level unless you have some really unusual hardware. This is because the same clock is used for A/D and D/A. Usually they are on the same chip and the data from the ADC is clocked out using the same clock that loads the DAC.
Can you just explain to us why sync has to be done when you have two soundcards that are supposed to be sending you the same number of blocks per second ?
I mean, for example, suppose a soundcard that is nominally set at 44100 Hz is actually running at 44098 Hz ; then what happens to Pd objects that depend on the samplerate (such as [osc~], [lop~], etc) ? Do they use 44098, or 44100 ? that would be the same as whatever [samplerate~] says, but somehow, it always says exactly 44100.000 ... why ? Is it because my soundcard's clock is that much accurate ? (it's a cheap on-board thing)
I recall seeing precisely "44098 Hz" when my soundcard was an ISA Ultrasound (Gravis) some 5-10 years ago, but I don't recall whether it was at Pd's startup, another programme's startup, or both.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Mathieu Bouchard wrote:
On Sun, 4 Jul 2010, Martin Peach wrote:
As long as they are on the same card, they will be in perfect sync at the clock level unless you have some really unusual hardware. This is because the same clock is used for A/D and D/A. Usually they are on the same chip and the data from the ADC is clocked out using the same clock that loads the DAC.
Can you just explain to us why sync has to be done when you have two soundcards that are supposed to be sending you the same number of blocks per second ?
?
I mean, for example, suppose a soundcard that is nominally set at 44100 Hz is actually running at 44098 Hz ; then what happens to Pd objects that depend on the samplerate (such as [osc~], [lop~], etc) ? Do they use 44098, or 44100 ? that would be the same as whatever [samplerate~] says, but somehow, it always says exactly 44100.000 ... why ? Is it because my soundcard's clock is that much accurate ? (it's a cheap on-board thing)
The sample rate is set by the frequency of the crystal on the card, which is supposed to run at some multiple of 44100 or 48000, but that's set by the manufacturing tolerances and nothing is actually measuring it. Also because the crystal changes in size with temperature the frequency will change slightly as it warms up. Precision oscillators are kept inside ovens for that reason.
Pd assumes 44100Hz even if the card isn't doing that. (Some of the code seems to be actually hard-wired for 44100). For instance if I clock one sound card with the SPDIF output of another card on another machine that's running at 22050Hz, the test tone is 220Hz instead of 440 and Pd is none the wiser.
I recall seeing precisely "44098 Hz" when my soundcard was an ISA Ultrasound (Gravis) some 5-10 years ago, but I don't recall whether it was at Pd's startup, another programme's startup, or both.
I guess if you know the CPU frequency you can count samples to determine the sample rate, but that assumes that the CPU clock is what it says it is. Relativity and all that...
Martin
On Mon, 5 Jul 2010, Martin Peach wrote:
Mathieu Bouchard wrote:
I recall seeing precisely "44098 Hz" when my soundcard was an ISA Ultrasound (Gravis) some 5-10 years ago, but I don't recall whether it was at Pd's startup, another programme's startup, or both.
I guess if you know the CPU frequency you can count samples to determine the sample rate, but that assumes that the CPU clock is what it says it is. Relativity and all that...
If you throw a 44100 Hz soundcard in space at 259627884 metres per second, it will appear to run at 22050 Hz.
...
Anyway, thanks for your answer, seriously.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
:D you just made my day Mathieu.
On Tue, Jul 6, 2010 at 2:37 AM, Mathieu Bouchard matju@artengine.ca wrote:
On Mon, 5 Jul 2010, Martin Peach wrote:
Mathieu Bouchard wrote:
I recall seeing precisely "44098 Hz" when my soundcard was an ISA Ultrasound (Gravis) some 5-10 years ago, but I don't recall whether it was at Pd's startup, another programme's startup, or both.
I guess if you know the CPU frequency you can count samples to determine the sample rate, but that assumes that the CPU clock is what it says it is. Relativity and all that...
If you throw a 44100 Hz soundcard in space at 259627884 metres per second, it will appear to run at 22050 Hz.
...
Anyway, thanks for your answer, seriously.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sun, 4 Jul 2010, Henrique wrote:
However, I think the total delay itself is not a problem, because it will appear in my acoustic response estimate.
I think I misread the question. Sorry.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On 2010-07-04 22:12, Mathieu Bouchard wrote:
The total delay is the sum of the logical delay as written in the audio settings dialogue of Pd
i wouldn't give a groschen for what is written in the audio settings dialogue of Pd. i dare say that the value you see in the dialog jhas a direct relationship [1] to the actual delay you are experiencing.
mfgasdr IOhannes
[1] http://en.wikipedia.org/wiki/Direct_relationship
, plus the digital in-delay and out-delay of the soundcard and/or driver, plus any analogue delay introduced by the soundcard due to filtering, plus the microphone's delay, plus the speaker's delay, plus the room's delay (relative to position and orientation of both speaker and microphone).
In the end, any digital delay can be counted by easy addition, whereas the analogue delays are frequency-dependent and thus have to be counted as filters. So, to measure a room's response, you'd first just subtract the digital delay, but after that, for the analogue effects, you'd need to deconvolve instead (but I suppose that you already know that).
It may be tricky to know the digital delay beforehand... but if you put the microphone and speaker really next (in)to each other, then just look in your recording for the point when the response begins, then it might be quite close to a digital delay, IF your impulsion contains enough high-frequencies. But I don't know how close it is, as I haven't tried it.
The total digital delay is soundcard-dependent, driver-dependent, and OS-dependent, on top of being dependent on a setting in pd.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Henrique -
IOhannes m zmoelnig -
Martin Peach -
Mathieu Bouchard -
Pedro Lopes