warning: requested samplerate 44100 not supported, using 48000.

but anyway I played the files: 10'3''

The patch will then run on a Bela board, who knows what will happen there...

The [timer] issue:
I used it to measure playing time, but this object seems to be related to the samplerate, since I always measure 10'00''+/-some milliseconds.
This is not fair, I spend two days figuring out what causes issue.
Now I measure with [realtime].

How can I fix the play speed?

@rph-r Looking at the warning it seems alsa will not run at 44100..... so Pd is probably running at 48K.

The message appears with portaudio, not alsa. But you're right, I suspect Pd to follow something @ 48k (Pulseaudio? Alsa?), although [samplerate~] indicates 44100.

I can't use most of externals on Bela, and since the patch will be running for a veeeery long time, I have to keep it light.
I don't really understand why a simple and so common object doesn't work...

[readsf~] is working properly.
The problem is that if Pd is processing 48000 samples per second then a file recorded with 44100 samples per second will play too fast.
If you can get Pd to run at 44100 [readsf~] will work..... if it can be loaded on the Bela.
Maybe that is the first thing to check, and if it will work then you could maybe resample the files at 48K.. and use those.
David.

I remember that [sf-play2~] can autocorrect, if it is available for your system.......

[sf-play2~] is an abstraction based on cyclone/play -- which probably rules it out for Bela.

In the same pack, however, there's [sf-varispeed2~] which is (I think) pure vanilla.

https://github.com/jamshark70/hjh-abs

@rph-r

I don't really understand why a simple and so common object doesn't work...

FWIW in SuperCollider you'd run into the same issue. The difference is that SC makes it easier by providing a unit generator, BufRateScale, that you can just plug into a Phasor or PlayBuf and get the right speed.

In Pd vanilla, you have to get the file sample rate from [soundfiler] and the system sample rate from [samplerate~] (and there's an interesting caveat about that, noted in the help file), and divide them on your own: playspeed = file_sr / system_sr.

I made [sf-play2~] and [sf-varispeed2~] and their supporting abstractions because I agree -- generally users shouldn't have to think about this. The abstractions do exactly what I just described, only behind the scenes.

hjh

@alexandros said:

The Bela runs on 44100 only.

that is why I use 44100. So there is definitely something wrong with pulseaudio.

Edit: I suppose it could also be the case that your soundcard is 48k only?

but anyway I'll figure out how I could use [sf-varispeed2~] since I need to fine tune and resync. I have to guarantee the installation for 5 years (!!).

BUT... the bad news... I just noticed that you said the files are 10 minutes. sf-varispeed(2)~ depends on loading the file into an array, where the Pd-canonical way to stream it out is by feeding sample indices to tabread4~. (This is under the hood of sf-varispeed~.)

32-bit floats are precise up to about six minutes or so. There's nothing Pd can do about that (except if you build a 64-bit version -- not sure how that would run on a Bela). This isn't Pd's fault btw -- SuperCollider's BufRd has the same limitation.

So I guess your choices are:

• [sf-varispeed2~] and split the files across multiple buffers, trying somehow to hide the seams. (Or, split the files and work out your own play mechanism that crossfades over the seams.)
• OR: Sample-rate-convert the files. You could have, on your dev computer, a "myfile-0-44100.wav" and a "myfile-0-48000.wav" (and myfile-1, myfile-2 etc.) and then select the file by a numeric index and sample rate:

Then when you move the patch over to the Bela, just copy the -44100 file and the patch will still find it according to the sample rate.

@oid

Edit: I suppose it could also be the case that your soundcard is 48k only?

That could be -- it's the case on my current laptop. If I request qjackctl* to start at 44.1 kHz, it will not do that for the built-in sound card -- 48 kHz only.

• I know, I know... planning to upgrade to Ubuntu Studio 24.04 over the winter holiday... then hello pipewire.

hjh

I know, I know... planning to upgrade to Ubuntu Studio 24.04 over the winter holiday... then hello pipewire.

Might want to check the pd github, there is at least one pd killing bug when using Pipewire's Jack, saw it yesterday but did not look into it since I have also let updating my system slide and don't feel like updating quite yet.

Edit: never mind, you use plug data. But might be of interest to OP in case he decides to update so I will leave it.

Might want to check the pd github, there is at least one pd killing bug when using Pipewire's Jack, saw it yesterday but did not look into it since I have also let updating my system slide and don't feel like updating quite yet.

The only bug report I see is that it fails when you toggle "use callbacks" -- so it looks like the old joke, "'Doc, it hurts when I move my arm like that!' -- so don't move your arm like that."

Btw I use both Pd-next and plugdata -- I'm not at all a fan of the Tcl/Tk interface, though, so I tend to reach for plugdata first. But if I'm making an abstraction that I know people will use in vanilla, then it makes more sense to build it in vanilla so that it looks nicer in that environment.

hjh

The thing is: I play back field recordings recorded twelve hours before. I divided the recording into 10m slices. The playbacks have to be on time +/-1 or 2 seconds. For example the church bells ringing at midnight have to be played back on time at noon. The installation is permanent, so I need to resync if the offset - the junction between the files - moves.

I finally use the simple [sfplay~]. I made 12 hours tests and it is not so bad: it moves +/- 1sec, but finally keep sync with tenths minutes +/-2sec.

I noticed a strange behavior: sometimes I start the patch and it reads the files too quickly (they finishes after 9' and some seconds). But after restarting the patch it is ok again...
I'll provide more tests soon