I've tried with [textfile] some times ago, I don't remember why it wasn't working.
Anyway, I found a way

This is working well, and doesn't escape the backslashes (therefore they don't appear in the textfile)

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

@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

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

by Tcl you mean netsend? I'm using it locally with pdreceive, I receive the messages but only with the backslashes escape characters.

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

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.

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:

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

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?