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.<div>
<br></div><div>*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] </div>
<div><br></div><div><br></div><div>[1] Some cards offer you their own sample-sync possibilities such as some MOTU hardware... (<a href="http://www.motu.com/techsupport/technotes/phase-accurate-versus-sample-accurate-sync">http://www.motu.com/techsupport/technotes/phase-accurate-versus-sample-accurate-sync</a>) although I do not recommend MOTU =P<br>
<br><div class="gmail_quote">On Sun, Jul 4, 2010 at 9:26 PM, Henrique <span dir="ltr"><<a href="mailto:jhgoulart@gmail.com">jhgoulart@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Thanks for your observation, Mathieu.<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br>--<br><font color="#888888">Henrique</font><div><div></div><div class="h5"><br>
<br><br><div class="gmail_quote">On Sun, Jul 4, 2010 at 5:12 PM, Mathieu Bouchard <span dir="ltr"><<a href="mailto:matju@artengine.ca" target="_blank">matju@artengine.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Sun, 4 Jul 2010, Henrique wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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 <a href="http://puredata.info" target="_blank">puredata.info</a> website.<br>
</blockquote>
<br></div>
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).<br>
<br>
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).<br>
<br>
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.<br>
<br>
The total digital delay is soundcard-dependent, driver-dependent, and OS-dependent, on top of being dependent on a setting in pd.<br><font color="#888888">
<br>
_ _ __ ___ _____ ________ _____________ _____________________ ...<br>
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801</font></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
<a href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Pedro Lopes<br>contacto: <a href="mailto:jazz@radiozero.pt">jazz@radiozero.pt</a><br>website: <a href="http://web.ist.utl.pt/Pedro.Lopes">http://web.ist.utl.pt/Pedro.Lopes</a> <br>
</div>