o I connected the UGREEN to my Pi and selected it (USB Audio Device (Hardware)) as an output on my pd.
Same problem as before. the audio distorted at unity gain (I'm multiple the audio playback by 1 and then send it to the dac~
In order to have clean sound I need to multiple the playback audio by 0.1 - 0.05. I don't understand why is happening?

Could it be something with my pi audio setting?

Thanks

edit: I connected my Motu ultra lite mk4 and the output is not distorted even when multiple by 1 (as it should be)
So I can assume the USB Audio Interface I bought is just not good enough?

What you can recommend me for small audio interface with stereo output? that for sure is not distorted the audio...

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

@bobpell You can check in /etc/security for limits.conf or limits.d/, grep limits.conf/the files in limits.d/ for audio, grep audio limits.conf or grep audio limits.d/*, you should have

@audio   -  rtprio     95
@audio   -  memlock    unlimited

If you have them but the settings for rtpro or memlock are different, than change them to 95 and unlimited. If you do not have anything for audio then if you have limits.conf, add the lines, if you have limits.d/ then add the file audio.conf with those lines and restart. If you do have those or adding them does not work than it is a quirk of LinuxMint and you will have to ask in a LinuxMint forum how to set it up or wait for someone more familiar with LinuxMint to show up. LinuxMint is Ubuntu based so this should already be setup and just adding your user to the audio group should work, but LinuxMint may have decided to change this and you will need to ask people well versed in the distro or do some searching to find what you need to do. One thing you can do is install the Ubuntu Studio package, but that is a great deal of software so somewhat overkill.

Edit: looks like I missed an update and duplicated a response, either of our numbers will work. Regarding the niceness line, from what I understand that is a hold over from bygone days and not needed on modern systems, does not hurt to have it but it does not actually accomplish anything.

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

I searched through many of the s~/r~ throw~/catch~ hops in my own code for mistakes based on what I've learned, and it looks like ~50% of all my non-local audio connections carry modulation signals that originate from control rate objects, so those aren't affected much. Only a few programs would have been broken had the non-local connections not matched, but because things were created in signal-flow order where it mattered, there was a consistent (and often unnecessary) 1 block delay everywhere. Many of those patches were later converted to use tabsend~/tabreceive~ under a small block size, and a few were converted to use delay lines. I was burned by the creation order side effect of delwrite~/delread~ once, but it wouldn't have happened had I not taken a lazy shortcut. Hilariously, I also found one test patch that I used to declare definitively, once and for all, that s~/r~ always introduces a 1 block delay if the sort order isn't controlled using the G05 technique. To paraphrase Agent K in the movie Men in Black, imagine what I'll "know" tomorrow!

So as a practical issue, I doubt coders are getting tripped up by this frequently. If you're like me you tend to code in signal flow order, and so you are mostly just introducing latency unnecessarily. RE advice, I agree with @Nicolas-Danet: use local audio connections wherever it matters and never mind the clutter. Even my worst spider web isn't so bad. Subpatches and abstractions can help hide the mess.

But when things are broken and showtime is looming, you'd be foolish not to use what you know, especially when you can always go back after curtain calls and adjust things to satisfy the style police. Here is a summary of the sort rules as best as I've been able to figure them out so far:

• A patch orders its constituent audio subpatches and abstractions, but has no influence over their internal ordering. Consequently, these rules are applied starting at the top level patch and recurse into each subpatch and abstraction.
• Audio chain tributaries and independent audio chains are executed in reverse order of their head's creation, except for those created by [clone], which are executed in the order of their creation (i.e. ascending clone index order).
• Audio branches that start from fanout connections are executed in reverse order of their start connection's creation.
• Whenever the rules conflict, the rule that places the tilde object the latest in line takes precidence.

These sort rules can affect your patch because unless s~ and throw~ buffer their data before their corresponding r~ and catch~ are executed, the latter will have to wait a block to access it. Delread~ will have a minimum 1 block delay.

Finally, I thought of this technique if you're absolutely certain you are going to get burned (or are just paranoid): wrap all s~, r~, throw~, catch~, delwrite~, delread~, and audio chain heads in their own subpatches. I noticed that if you modify the contents of a subpatch, it doesn't change its sort order in the containing patch, so you can add test code (e.g. [sig~ <uniqueNr>]->[tabsend~ <sharedArray>]) to subpatch pairs and check their execution order without changing it. If the order is wrong, then you cut and repaste the appropriate subpatches or audio connections according to the rules above until it isn't. That should take 15 mins, not days.

@jyg What do you want Jack to do for you?
Pd asks the OS for a list of audio drivers and their "pins" at startup..... audio connections in and out..... so you can then select the ones you want to use in the audiosettings menu.
If you want low latency and/or to use multiple devices then Asio4All is a good driver...... http://www.asio4all.org/
It will give you the same function as "aggregate device" on osx.
If you want to pass audio between applications then you can use virtual audio cables.... https://vb-audio.com/Cable/
They and Asio4All will all appear in the audiosettings menu (select asio first) and you can route your audio where you wish.
If you choose to use Asio4All as the driver then you will also see the virtual cables in its window.
You can then route Pd audio anywhere you wish using [adc~ x] and [dac~ x]
David.

@nicnut said:

I don't know if this helps, but sometimes the audio output level will make the audio sound bad. I have a RPi 4 and I am using a soundcard with a seperate audio output volume knob. And I use the alsamixer.

At first I turned everything up as much as possible. It sounded terrible and sometimes no audio came out. Now I have alsa mixer at about 60% and my soundcard at 80%. I control the volume from my amp and faders in Pd. It sounds way better.

If you are using the 8th inch jack out of the Pi something related to this could be an issue.

@EEight said:

@nicnut A dedicated soundcard is the way to go AFAIK. Also using jack and controlling the buffer (if you don't need low latency then use a big buffer like 1024).

I plugged in a USB audio dongle, and it seemed to stop the crackling but I still get the following audio dropouts

more info on how to set up jack or alsa would be appreciated

[4] error: audio I/O dropout
loading cached help index from ~/.purr-data/search.index
finished loading help index (0.20 secs)
[4] error: audio I/O dropout