@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?

@dfkettle That's unfortunate.
Maybe try Asio4All...... https://www.asio4all.org/....... as a universal driver for Pd and Audacity.
It will have a settings window...... individual for each application..... so try to keep them as identical as possible.
It will give you lower latency and allow you to use multiple soundcards so it can be useful anyway.
David.

@dfkettle what does the 'playback' tab look like for them?

@dfkettle said:

So I tried a three-way comparison. I played the file back in Audacity, my patch and WIndows Media Player. None of them matched...

It seems, if you want them to match, that using a different operating system may be the only solution.

I know, that's a terrible answer... but "terrible" is also a kind word to describe the utter disaster that is professional audio in Windows.

How about this: Record your Pd patch to a disk file, and measure the number of samples between soundfile attacks (or phasor jumps). This will either match the sample rate (assuming the 1 Hz cycle) or it won't.

If it does match (give or take one sample, due to fp rounding), then you know definitively that Pd is producing a correct sequence of samples and the situation in your patch cannot be improved. At that point, it's irrelevant that Audacity and WMP are wrong -- evaluating the worth of a correct result, against other software's incorrect behavior, is not useful.

If it doesn't match, then it would be a bug report. But I'm quite confident that won't be the case.

hjh

@whale-av said:

@dfkettle That's unfortunate.
Maybe try Asio4All...... https://www.asio4all.org/....... as a universal driver for Pd and Audacity.
It will have a settings window...... individual for each application..... so try to keep them as identical as possible.
It will give you lower latency and allow you to use multiple soundcards so it can be useful anyway.
David.

I don't think that's an option for Audacity, at least not under Windows. It uses PortAudio for all three "hosts" (MME, Windows DirectSound or WASAPI), as you can see in the screen capture above. I have to confess that I don't really understand the difference between audio "host" and "driver", though, as they're called in Audacity. Maybe there's a way to tell Audacity to use ASIO4All, but I don't know how. I already have ASIO4All installed, I use it with other programs.

@dfkettle Sorry...... I see Audacity has to be recompiled to use ASIO.
That's unfortunate too...
David.

possibly related? idk: https://github.com/pure-data/pure-data/issues/1998