Hi,
ok, a lot in the title.
I have trouble with a patch playing wav 44100 files. The files are exactly 10', verified mounting them on some DAWs.
But:
-if I use alsa @ 44100, [readsf] plays the files in 9'13'', too quickly
-with portaudio:

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?

The Bela runs on 44100 only, so your audio files should play fine, unless you've already tried this on a Bela.

@rph-r I think @jameslo's solution is plain vanilla....... apart from [readsf~] which you seem to have working...... but maybe not on the Bela.
It shouldn't be too heavy.

[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.

Ok, pulseaudio or something in between is probably guilty:
I made this patch to test and it unsync on my regular linux system. It could be the 44100/48000, but the weird thing is it doesn't unsync the same manner with alsa or portaudio.
On my sound production system (lowlatency, and with Jackd), it remains perfectly synchronized.
I'll try tomorrow on the Bela, hopefully it will be ok...
TEST_timerVSrealtime.pd

@whale-av said:

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

I seems to work on Bela too... ouf

@alexandros said:

The Bela runs on 44100 only.

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

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 (!!).

@rph-r The only way Pulse could be the culprit is if you are running jack/portaudio through Pulse, but that is generally not done since Pulse has too much latency for realtime audio. I can't speak of portaudio (never used it) but with jack the general setup is to either have Pulse as a client of jack or have jack kill Pulse when it starts and restart Pulse when it shuts down. I would guess that the later is your setup, Pulse configures your audio card and jack is not great at doing that so just accepts what Pulse set it at. You might be able to get jack to set it properly or configure Pulse to use 44.1. Some soundcards jack just can not configure as far as I can tell so if you are using Pulse and having jack kill Pulse you need to either configure the soundcard manually or do it in Pulse before starting jack, I have to do this with my laptop, jack can not select between headphone and speaker outs and will use which ever is enabled when it starts.

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

@rph-r said:

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

@ddw_music said:

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.

@oid said:

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

thank you for all your infos and suggestions.

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

@rph-r If your installation can be connected to the internet, and bela can push the data to Pd, then you can re-sync without errors. [zexy/time] would work but maybe not on the bela.
If no internet then an old phone with a free sim card and a hotspot.
The computer would need to be set to automatically update time from an internet time server.
Otherwise the computer time will always drift..... and by a lot even over a month..
David.
P.S there might be a way to get the time into the bela from a GPS module..... then you don't need the sim card........ https://forum.arduino.cc/t/time-and-date-from-gps/686778

@whale-av This point is solved, I actually wrote an object. I was using [shell] with date command but it was generating errors in the sound stream, like xruns. You can already try it (linux and Bela versions), but I will rewrite it soon to be easier portable.
And yes, the Bela is connected to internet and automatically sync the time. Syncing is not a big deal, but syncing without glitch is another story...
x86 Linux version here
ahora.pd_linux

and Bela, written with xenomai wrappers, otherwise it generates errors also.
ahora.pd_linux