@lacuna said:

clocks are famously inaccurate

As I have been writing, this is what we assumed - and still might be most likely

In SuperCollider, after booting the audio engine, you can ask it .sampleRate and .actualSampleRate. The latter fluctuates, sometimes as much as a dozen or two samples per second (especially for built-in audio interfaces).

Once the signal is sampled, you're stuck with it, apart from resampling after the fact.

but as far as I remember Audacity on a Mac has been involved in the post-production, too.

Audacity should not resample anything unless you tell it to, by "Change Speed." It will not automatically fix a recording rate mismatch (it can't, because there's no way to determine from a stream of audio samples how fast it was actually recorded vs the nominal sample rate) and it should definitely not make matters worse. Let's nip this bit of folklore in the bud. Audacity, /n/ samples imported --> /n/ samples exported.

Audacity playback and Audacity export are different mechanisms.

hjh

@ddw_music You could well be right........ waspi soundcard rate mismatch in windows 10 (the screenshots look like Windows >7)..... https://forum.audacityteam.org/t/audacity-playback-is-too-fast/45964

Except that the sample was copied to Pd from a recording in Audacity, and the Audacity problem is famously intermittent.
David.

@ddw_music
agree with everything you said about how such an offline DAW, as Audacity, should be working, but do not remember how the recordings have been processed, just know it has been rather complicated, there might have been some resampling involved as well.

Is it 100% guaranteed that Audacity is playing it at the right speed?

was your question and I read it like: can we trust Audacity more than Pd? My answer was no, with my experience, which is most likely offtopic.
Now I realize that you might have adressed the settings with your question.
....
@dfkettle said:

The clock would have to be very inaccurate to produce a noticeable difference

Agree with this.

anyway

.actualSampleRate

is interesting. Do you know how SC measures this?

In PD, all I could come up is this:

clock-jitter-pd.pd

but feels like measuring bullshit, as it just compares the drift of two clocks against one another, or worse, one calculation on top of a clock against another, within the same system (while the control objects have a lower priority in the schedule, are not time-critical). I think a "real" measure would require an external calibrated frequency-counter device.

How accurate is [realtime] ?
[cputime] doesn't seem to work here on Windows.

re: guard points: You're still telling tabread4~ to go from 0 to 44099 in 1 second. The only thing that will happen is that the read point is clipped between the 2nd and 2nd-to-last samples, but that doesn't influence the playback rate at all. You'll get repeated values where you 'would' read the 1st and last samples, that's it.

@seb-harmonik.ar
to be precise: reading from sample 1 (skipping sample 0, as it is a guard point) to arraysize-2
makes still 44100 samples. And yes, doesn't influence the playback-rate, neither the perceived pitch at all.

also I don't think I can hear any difference in vlc vs. pd here in jack on linux. So I don't think it's a pd issue.
edit: maybe you could somehow record the stuff going to your soundcard (or some capture software) and try to figure out the difference between the sound files when they're played in pd vs. played in audacity, if you're really curious. To me it seems most likely to be an audacity playback issue.
edit: seems possibly like what's mentioned in david's forum link above. Check your device playback and recording advanced property settings in the windows settings. (specifically device sample rate)
https://forum.audacityteam.org/t/playback-is-too-fast-and-high-pitched/61159/2

@lacuna you tell it to read from 0 and go to arraysize-1, but where it would read the 1st sample it outputs the value of the read point for the 2nd sample (as the 1st is a 'guard point') and where it would read the last sample it reads the value at the read point for the 2nd-to-last (as the last is another 'guard point')
I'm not sure I'd say they get 'skipped', but maybe 'replaced' or 'clipped'

@seb-harmonik.ar

please try this help file:
https://forum.pdpatchrepo.info/topic/14301/add-delete-guard-points-of-an-array-for-4-point-interpolation-of-tabread4-ect

The Lagrange interpolation uses n-1, n, n+1 and n+2 for interpolation at sample n+frac.

The only way without harsh artifacts with such a small array of 32 samples + 3 guardpoints = 35 (sample 0 to 34)
is reading it from sample 1 to 32
reading the sine wave only and using the guard points (0, 33, 34) for interpolation.
As patched above.

Looking again into

else\Live-Electronics-Tutorial\Part.07-Sampling.Delay.Granulation\27-Sampling(buffer)\3.Interpolation

Yes, the read-points are clipped. But that clipping causes a discontinuity of the sine.

It gets less obvious and even non-perceivable with higher resolution samples, because the artifacts become more silent and phasor~'s frequency running it, stays the same.

B04.tabread4.interpolation.pd is using [+~ 1] instead of the [1( into the right inlet of [tabread4~] :

I'm not sure how many of these comments are addressed to me or the other David, but in any case, I'm getting a little confused. To get back to my original post (and ignoring the issue of guard points, which I know is important but not really relevant to my question), I'd like to reiterate:

1. I didn't use Audacity to record anything, I just used it to create a sound file with one of the built-in UGEN's (create a new track, then click on 'Generate->Pluck...' in the toolbar). Really, the file could have originated anywhere, and whether or not there were timing inaccuracies when it was created is completely irrelevant. I'm just comparing the way it sounds when played back in Audacity vs. when it's played back in my Pure Data patch.

2. Someone asked me "how much is it off by"; I'm not sure how to answer that, except to say that it sounds about one semi-tone higher in Audacity than it does in Pure Data, although I don't have a very good ear for pitch. (If the problem was in Audacity, wouldn't the frequency be lower in Audacity than in Pure Data or is that an over-simplification?)

3. I don't think I mentioned this, but I'm running both on the same computer, a HP-P6230F (with a quad-core processor running at 2.60 GHz running Windows 10 64-bit). I was going to provide a link to the specs on the HP web site, but they seem to have removed the page (it's an old computer). I'm running Pure Data 0.53.2, 64-bit, and Audacity 3.2.5, 64-bit.

4. Also not previously mentioned, I tried running Pd in both real-time and non-real-time mode, but it didn't seem to make any difference.

I appreciate everyone's help, but can we limit the discussion to my original question and ignore other issues like guard points, interpolation (which I don't think applies to my question, since I'm playing the file back at the original speed) and problems related to recording in Audacity? They probably deserve a thread of their own, anyway.

@dfkettle well sorry for my part in derailing (in my defense, originally clarifying that it wasn't the 'guard points' that were responsible for any pitch difference)
Now, the issue is not so much recording in Audacity as it is playing back in Audacity. Did you look at the link I posted above and the link from other David? What is your current system device playback sample rate?
edit: to clarify, it could very well be that audacity is generating plucks for 44,100 samplerate but playing them back at a higher one.

@seb-harmonik.ar said:

Now, the issue is not so much recording in Audacity as it is playing back in Audacity. Did you look at the link I posted above and the link from other David? What is your current system device playback sample rate?
edit: to clarify, it could very well be that audacity is generating plucks for 44,100 samplerate but playing them back at a higher one.

I don't know why it would play back at a higher rate, unless I changed the SR, which I didn't.

Edit: My audio interface is running at 44,100 (a Steinberg UR22), and so are Audacity and Pure Data.

@ddw_music I ran your test patch and it seems that 'phasor~' runs a tiny bit slow on my machine, even though the CPU usage is only fluctuating between 5 and 15%. I ran the test several times, and it consistently reports 999.909 instead of 1000. Would that be enough to cause a perceptible drop in pitch? I'm not sure of the arithmetic to figure that out.

Edit: Actually, I guess this means it's running faster, right?

@dfkettle ok well it seems like other people have had the exact same problem on windows with audacity and you're assuming the only reason why your sound settings are messed up is explicitly changing the sample rate. If you read the posts you'll see that one person had to reinstall some audio drivers. Sometimes OSs and programs don't work together exactly as they should.

@dfkettle as for your [phasor~] test the result is most likely due to floating point math and block boundary stuff. Pd is compiled in such a way that this might not be completely consistent across systems either but the discrepancy wouldn't create any significant pitch difference.

@dfkettle said:

Edit: My audio interface is running at 44,100 (a Steinberg UR22), and so are Audacity and Pure Data.

@ddw_music I ran your test patch and it seems that 'phasor~' runs a tiny bit slow on my machine

Nope.

Pd's control block resolution is 64 samples. [timer] can report only on 64 sample boundaries.

Now... what is 44100 / 64? ... It's 689.0625.

This is not an integer.

Therefore there is no way, at 44.1 kHz, that a number of control blocks can add up to exactly one second.

When I did it in the morning, my internal soundcard supports only 48 kHz... which is a multiple of 64.

There will be no deviation in pitch based on the divisibility of the sample rate. That isn't how soundcards work.

even though the CPU usage is only fluctuating between 5 and 15%.

That isn't how soundcards work either.

hjh

@seb-harmonik.ar said:

@dfkettle ok well it seems like other people have had the exact same problem on windows with audacity and you're assuming the only reason why your sound settings are messed up is explicitly changing the sample rate. If you read the posts you'll see that one person had to reinstall some audio drivers. Sometimes OSs and programs don't work together exactly as they should.

So I'm starting to think this could be a driver issue. In Pure Data, I have the choice of using MMIO or ASIO. I was using MMIO (ASIO doesn' seem to work at all). In Audacity, I have the choice of using MME, Windows DirectSound or Windows WASAPI (all of which use PortAudio); I was using MME. Could this explain the problem? It would make sense to use the same host for both, but they don't seem to offer the same choices, so I'm forced to use different ones.

@ddw_music said:

@dfkettle said:

Edit: My audio interface is running at 44,100 (a Steinberg UR22), and so are Audacity and Pure Data.

@ddw_music I ran your test patch and it seems that 'phasor~' runs a tiny bit slow on my machine

Nope.

Pd's control block resolution is 64 samples. [timer] can report only on 64 sample boundaries.

Now... what is 44100 / 64? ... It's 689.0625.

This is not an integer.

Therefore there is no way, at 44.1 kHz, that a number of control blocks can add up to exactly one second.

When I did it in the morning, my internal soundcard supports only 48 kHz... which is a multiple of 64.

Gotcha. I changed the SR to 48000 and now the test shows exactly 1000 ms.

There will be no deviation in pitch based on the divisibility of the sample rate. That isn't how soundcards work.

even though the CPU usage is only fluctuating between 5 and 15%.

That isn't how soundcards work either.

I know that, but I thought maybe the CPU might be too busy and the data wasn't being sent to the audio interface fast enough. So I checked the CPU usage in the Windows system monitor.

I'm going to create another file in Audacity at a SR of 48000, then try playing it back at 48000 in both. Maybe I'll have better luck. I'll also try using a different driver (audio host?) in Audacity.

@dfkettle said:

Gotcha. I changed the SR to 48000 and now the test shows exactly 1000 ms.

... which, to be clear, has nothing to do with the original problem.

I know that, but I thought maybe the CPU might be too busy and the data wasn't being sent to the audio interface fast enough.

If that's the case, then there would be noticeable glitches in the audio. If the outgoing signal is smooth, then all of the blocks of samples are being delivered on time.

I'm going to create another file in Audacity at a SR of 48000, then try playing it back at 48000 in both. Maybe I'll have better luck.

At this point, I'm pretty well satisfied that Pd's behavior is fine, and your patch is doing the right thing. So the real point of this test is to find out the boundaries of Audacity's correct behavior, not really anything else.

hjh

@ddw_music said:

At this point, I'm pretty well satisfied that Pd's behavior is fine, and your patch is doing the right thing. So the real point of this test is to find out the boundaries of Audacity's correct behavior, not really anything else.

Likewise, although I'm a little surprised, given that Audacity has been around for so long, and since I'm playing back at the same sample rate no interpolation is required. It's just sending the sample data in blocks to the audio driver or host. Maybe something to do with the latency setting? I'm just letting it default, I've never played around with it before.

So I tried a three-way comparison. I played the file back in Audacity, my patch and WIndows Media Player. None of them matched, they all varied in frequency, although Audacity and WMP came the closest to matching. Any thoughts on that?