@lacuna said:

Don't know about phasor's right inlet, but I guess for more precision on the outside of objects we'd have to use 'Pd double precision'.

Yes, I confirmed that my test patch runs without issue under Pd64. Unfortunately, my real patch doesn't

Also remember @ddw_music different approach than [phasor~]:

I think that "different approach" is a different issue--I'm not multipying its output to index into a large table. I'm just using it as an oscillator/LFO. Are you suggesting that there's a way to build an oscillator with [rpole~] that is as frequency-accurate as [phasor~] but without the single vs double precision issue?

On one sample late: It is [snapshot~] who is early, not [phasor~]:
...
I would call this a bug of [snapshot~] !%§$*(

I don't understand your conclusion about the timing of [snapshot~]. Here's how I would analyze your demonstration patch: the top bang is processed in-between audio blocks. Therefore, [tabplay~] and [fexpr~] run in the following audio block. [snapshot~] is different though, because it's a bridge between control rate and audio rate--like bang, it also runs between audio blocks. Therefore, the best it can do (without having to predict the future) is to return the last sample of the previous audio block. So it's not surprising for [fexpr~] to have to reach back into the previous audio block to get the same value as [snapshot~]. If [snapshot~] were to return the first sample of the following audio block, it couldn't pass that value to control rate code until that audio block's processing is complete. Do you see my point?

Also, I'm not saying [phasor~] is early, I'm just saying its right inlet isn't a mechanism for restoring its state. It's just for what the documentation says it's for: to reset its phase to a given value.

@nenleh said:

In an tutorial I have seen that someone marked the checkbox "compute audio" in the main window of PD (first picture) to solve this poblem.
But I do not have this checkbox (second picture).

Ancient tutorial, then. The current "DSP" checkbox is the same as the old "compute audio" box.

What can be the problem?

The console messages that you get after clicking DSP say that it's an audio driver problem: Pd is trying to connect to an Advanced Linux Sound Architecture instance and this is failing.

Linux audio is famously messy. The current best attempt to clean up the mess is Pipewire, so I guess your best option may be to install Pipewire and run pd under its power. If it's me, I'd use the Media menu to choose the JACK backend and then run pd as "pw-jack /path/to/pd-gui" (I think; not at the computer right now, and the path may vary depending on Linux distro).

I have not yet used Pipewire, though, so I couldn't troubleshoot beyond that. Linux audio forums could help more. (Note that Linux audio being chaotic and disorganized isn't Pd's fault -- but once you get the audio subsystem configured, then it works for every app. It's painful only the first time.)

Also, "priority 6 scheduling failed" means that you should add your user to the "audio" group.

hjh

@Pandas As above..... Pd has an input > output delay equal to its block size.
Put something in and it will output 64 samples later.
But the soundcard cannot convert that to analogue instantly... so we add a buffer that gives it time to process the audio before the next block arrives.... MOTU 2-3ms with ASIO... On board soundcard usually 30-80ms.
I see you posted elsewhere on the forum..... https://forum.pdpatchrepo.info/topic/14495/sync-to-external-daw-midi-clock-audio-latency
I don't know those programs and maybe someone else will help.
Sending the audio samples to another program through a port will still not be instantaneous... but should be close unless you are listening to it at the same time.... but even media players will buffer at least 512 samples before they play a stream.

Does QSynth have compensation settings to delay the midi and attempt to match the audio timing?
What is your OS?
As you are communicating with software rather than a DAC you could try reducing the Delay (mSecs) in Pd media settings,,,,,, down to 3, then 2, then 1.. 0 probably not but you never know.... basically until it hangs and then go back to the last setting that worked.
Apply but don't save the settings until you are done.... or Pd might not start or might not let you change them again while it is "stuck" even if you restart it.
There is a fix for that..... I will upload it if that happens..

Running Pd at 96kHz audio rate should I think reduce the 64 sample (Pd internal) block delay.... you could try that too...... I think it should output in half the 48kHz time.

And try this..... it might help....... depends what you are wanting to achieve...... https://forum.pdpatchrepo.info/topic/13125/batch-processing-audio-faster-than-realtime
David.

Hello all,

Running 'Pd-0.52-1-really' on a 2021 M1 Macbook Pro. When I need to change my audio preferences (namely my audio output device) in PD, I can select the output I need, but when I click 'Save All Settings' or 'Apply' the following happens:

• 'Audio off' switches to 'Audio on' in the main PD window (the DSP checkbox does not respond, it remains unchecked)
• PD freezes: clicking OK or cancel in the Audio Settings window yields no response, the window will not close via any means. Similarly, if I have a patch open this will also freeze and cannot be closed. I have found I can close the main PD window, but I cannot quit PD- I have to force quit via the finder.

Upon reopening PD it's a gamble as to whether the audio setting I changed has even been remembered. This is extremely frustrating and is rendering the software very unreliable and hard to use (especially as I use it almost exclusively for audio).

Also, if I skip the process of clicking 'Save All Settings' or 'Apply', and just hit 'OK', the audio settings window closes, but the program still freezes in the same way.

Additionally, I'm trying to open a patch that contains a load bang to start DSP, and this will also freeze the program.

Has anyone else experienced this, and can they suggest any solutions? Thanks!

@esaruoho Updating the array while recording will probably cause dropouts. Redrawing onto the screen is hungry and unadvisable in Pd.

You can stop and start from the same point..... using a counter and restarting with a [start index(...... message, index being the next sample after where you stopped.
But.
Complicated.

It will probably be easier to stop audio computation when you press the [stop( button..... which will pause the writing to the array.
That will "freeze" audio for that window..... so you will no longer hear any audio that the window generates...... but other windows being unaffected you should be able to organise the patch to still hear what you need from elsewhere.
Put a [switch] object in the window with [tabwrite~] and toggle audio on off with a message..... 1 on.... 0 off.
Then connect [stop( to a 0 message and [resume( to a 1 message to [switch].
It will cause clicks, but you can stop that, while only losing a tiny bit of precision for the stop point, by "ducking" the audio before and after the [switch] operation like this.....

Use the [line~] output to duck the audio to [tabwrite~] so that there are no clicks on the recording as [switch] stops processing..... the audio recording level will be at 0 when processing stops and then fade up from 0 in 5ms when you start again (3ms after audio is turned on fully in the screenshot).
Set the [pipe] value lower if you wish..... 3 might be sufficient with 2 for the message to [line~].

The clicks might not matter at the stop/resume point of course....... and might make it easier to spot the "join" later.
David.

@jameslo said:

Honestly, I didn't know if that was @fintg's requirement,

It's certainly a reasonable guess. If the requirement instead were "I just played something cool; write the last 10 seconds to disk" you can do that without a circular buffer at all.

I was just surprised and annoyed that one can only access the delay line's internal buffer at audio rate (and was hoping that someone would prove me wrong).

Access to the internal buffer wouldn't be very useful without also knowing the record-head position. In that case delwrite~ would need an outlet for the current frame being written.

That would actually be a very nice feature request.

In SuperCollider as well, DelayN, DelayL and DelayC don't give you access to the internal buffer. But you can create your own buffer and write into it, with total control over phase, with BufWr -- and, because you control the write phase, you already know what it is. It's quite nice way to do it.

Basically the lack of ipoke~ in vanilla causes some headaches.

Look at the hoops I have to jump through! The extra memory I have to use!

I don't think there is any way to do this without using some extra memory.

In a circular buffer, you have:

|~~~~~~ new audio ~~~~~~|~~~~~~ old audio ~~~~~~|
                        ^ record head

When you write to disk, naturally you want the old audio earlier in the file. There are only two ways to do that. One is to write the "old" chunk without closing the file, and append the "new" chunk, and then close the file.

In SC, if I know the record head position, I'd do it like:

buf.write(path, "wav", "int24", startFrame: recHead, leaveOpen: true, completionMessage: { |buf|
    buf.writeMsg(path, "wav", "int24", numFrames: recHead, startFrame: 0, leaveOpen: false)
});

AFAICS Pd does not support this, so you're left with duplicating new after old data. (FWIW, though, there's plenty of memory in modern computers; I wouldn't lose sleep over this.)

Then there is the problem of synchronous vs asynchronous disk access. AFAICS Pd's disk access is synchronous, and because the control layer is triggered from the audio loop, slow disk access could cause audio dropouts. OS file system caching might reduce the risk of that, but you never know. Ross Bencina's article about real-time audio performance advises against time-unbounded operations in the audio thread.

SC's buffer read/write commands run in a lower priority thread; wrt audio, they are asynchronous. This is good for audio stability, but it means that, by the time you get around to writing, the record head has moved forward. So, even though I could do the two-part write easily, I'd get a few ms of new data at the start of the file. I think I would solve that by allocating an extra, say, 2 seconds and then just don't write the 2 seconds after the sampled-held recHead value: startFrame: recHead + (s.sampleRate * 2). (If it takes 2 seconds to write a 10 second audio file, then you have bigger problems than circular buffers.) Then the record head can move freely into that zone without affecting audio written to disk.

hjh

This is a continuation to the issue I wanted to solved in this topic. It just went to different places so I though I will open a new topic to this problem I'm facing.

I have a pd patch that doing some audio playback reading some files from buffer. I'm running it on my Pi4.

I wanted it to start on boot every time and to be able to reset itself if crashing for some reason.
I was suggested to use that service script:

[Unit]
Description=My PureData service

[Service]
Type=simple
LimitNOFILE=1000000
ExecStart=/usr/bin/puredata -nogui  -open /home/pi/mypatch.pd
WorkingDirectory=/home/pi
User=pi
Group=pi
Restart=always
# Restart service after 10 seconds if service crashes
RestartSec=10

[Install]
WantedBy=multi-user.target

The above was working great using the built in 3.5mm audio jack.
I then bought UGREEN USB audio interface as I was facing with some poor audio quality at the output.

I set the audio preference in PD to choose the USB Audio Interface as the output.

When I boot the Pi I'm getting this error from the service (see picture)

If I'm typing sudo systemctl restart my_puredata.service the PD patch is back to work just fine. No Alsa error, but on the initial boot it is not working.

Any idea why this happen when using the USB AudioInterface? anything I can do in order to make it work?

So If to conclude:

When I start the same pd patch using the same service script but without a USB audio interface is working just fine.

When I start the same pd patch with the USB audio interface but using the autostart file:

sudo nano /etc/xdg/lxsession/LXDE-pi/autostart

Is also working just fine.

But the combination of the USB audio interface and the service script is just not working.

Thanks for any help.

@eulphean said:

I'm using pure data on a raspberry pi 3+ for a project. I have bluetooth configured properly on it. I can send regular audio to bluetooth speaker connected, but the preferences -> audio in PureData doesn't show the bluetooth speaker. It only shows internal audio card or if I have a USB audio card, that shows too. But no bluetooth device.

How do I configure that? Do I need to use jack or something to route audio to bluetooth for Pd?

My experience with Bluetooth audio in Linux has been:

• JACK has zero tolerance for the audio driver ever being late -- expect crashes or system lockups if you try to route audio from JACK to Bluetooth. That is, just don't.

• PulseAudio's support for BT audio is pretty good -- the "regular audio" that you spoke of. Audio production apps typically bypass PulseAudio, in which case BT audio may simply not be supported for them. That is, I expect you'd hit the same problem with SuperCollider, Audacity, Ardour, VCV Rack etc etc etc.

I'm not aware of a solution... That's not to say that there absolutely isn't one, but the Linux audio space is not unified as it is in Mac so audio device support may not be universal.

hjh

@raynovich I use [switch~] to pause audio playback of a file here...... cart_wav_simple.pd
The audio is muted in 5ms with [line] and at 8ms the audio processing for the patch is turned off.
Other patches will still have their audio running.
Taking the audio output to zero before turning audio off avoids clicks.
A 1 into switch turns audio on and a 0 turns it off.
When it is off there is no cpu load for the patch as there is no audio process running (for that patch).
David.

According to block~ help, if you bang [switch~] it runs one block of DSP computations, which is useful for performing computations that are more easily expressed as audio processing. Something I read (which I can't find now) left me with the impression that it runs faster than normal audio computations, i.e. as if it were in control domain. Here are some tests that confirm it, I think: switch~ bang how fast.pd

The key to this test is that all of the bangs sequenced by [t b b b b] run in the same gap between audio block computations. When [switch~] is banged, [osc~] fills array1, but you can see that element 63 of array1 changes after [switch~] is banged. Furthermore, no logical time has elapsed. So it appears that one block of audio processing has occurred between normal audio blocks. [bang~] outputs when that accelerated audio block processing is complete.

This next test takes things further and bangs [switch~] 10 times at control rate. Still, no logical time elapses, and [bang~] only outputs when all 10 bangs of [switch~] are complete. [rzero_rev~ 0] is just an arcane way of delaying by one sample, so this patch rotates the contents of array1 10 samples to the right. switch~ bang how fast2.pd

(There are better ways to rotate a table than this, but I just needed something to test with. Plus I never pass up a chance to use [rzero_rev~ 0] )

Finally, I've seen some code that sends a 1 to [switch~] and then sends 0 after one block of processing. In this test you can see that one block of audio is processed in one block of logical time, i.e. the normal way. switch~ bang how fast3.pd

But that second test suggests how you could embed arbitrary offline audio processing in a patch that's not being run with Pd's -batch flag or fast-forwarded with the fast-forward message introduced in Pd 0.51-1. Maybe it's an answer to two questions I've seen posted here: Offline analysis on a song and Insant pitch shift. Here's a patch that writes 20s of 440 Hz to a file as fast as possible (adapted from @solipp's patch for the first topic). You just compute how many blocks you need and bang away. write440File.zip

Here's another that computes the real FFT of an audio file as fast as possible: loadFFT.zip

But as with any control rate processing, if you try to do too much this way, Pd will fall behind in normal audio processing and stutter (e.g. listen to the output while running that last patch on a >1 minute file). So no free lunch, just a little subsidy.