With some patches the audio is a bit glitched and the console spits out these “snd_pcm_delay failed” messages
Sometimes it does it right away, sometimes after half a minute or more
More in detail these are the error messages that I see (btw. is there a way to save the console output somehow?), right at the beginning when launching the patch:
but I have seen it when setting up PD on other platforms.
when ive seen its, its been similar, always snd_pcm_delay, and you seem to get a variety of error codes.
in those scenarios, Ive usually put it down to underruns. i.e. the audio buffer is not ready in time.
you could try upping the audio buffer size in PD… though in the past this has only been partially successful for me.
also iirc, PD give you the option of ‘plugin’ and ‘hardware’ , i seem to remember one of these worked better than the other for some soundcards.
ultimately, I suspect the ‘cure’ is the normal things for audio underruns, a leaner/meaner distribution, and to check that your dsp code is not doing something it shouldn’t.
I’ve been meaning to do a couple of things, (but lack of time etc) :
check the alsa source code to see what is the cause,
snd_pcm_delay() is a function, thats calcs the delay, but Im not sure why its this function that seems to have an issue… or why we get a variety of codes.
see if I switch PD over to jack running at RT priority, does this perhaps perform better than alsa? or at least more consistently.
anyway, Ive recently been testing Orac on the rPI3 and PiSound, so far even with heavy racks, Ive not seen the issue. but I will keep an eye out for it.
definitely will be interested to hear if others have the issues, and if blokas can reproduce given your reproduction hints.
I’ve made a new Raspbian SD following mzero’s guide, so I’m pretty sure it’s pretty lean. No desktop software is running (as long as I don’t do a startx) and only the essential packages for Pd are installed. I didn’t even install supercollider.
Can’t say my own patches don’t do anything weird DPS wise, and cannot judge if Patrick’s patches do or not.
When I tried to run Pd via Jack that turned out to be a major mess. Nothing seemed to work and Pd crashed a lot. But maybe I did it wrong.
I’ll happily switch to Orac once it’s finished for rpi use! Though I must say that with the new app you have some good competition. While of course lacking the “modular” approach in Orac, loading and unloading patches is really quick and easy, and MIDI control and mapping is now also really great.
Actually, I have to admit that getting a monome norns has become much less of a priority now that Pisound has been updated with all these new features (though I can still see where it could have an edge).
Yeah I know, wasn’t really intending it like that. It’s one of the things I like about these projects, there’s none of that negative super-competition thing, where anybody is just waiting for the right moment to stab somebody in the back.
Oh right, that was in the release notes indeed. Well then let me say that again: great job with that, it really works like a charm and makes the whole thing so much more useful!!!
So basically you’re your own competition now!
Yeah, I think checking the code of ALSA and PD is necessary for this one, also backtracking to older releases of PD and RPi kernel to see whether this issue started occuring since some particular versions. I definitely don’t recall these errors happening with the Arp Odyssey or other patches around the time they were released.
On the error codes - I think it’s actually returning not error codes, but a duration in milliseconds or something, and Pure Data is trying to wrongly interpret the returned value as an ‘errno’ error code, hence giving the wide distribution of errors, some even involving the network. Anyway, code inspection should clear this up.
Exactly, not a competition, more like a collaboration working towards similar goals.
Yeah really, sorry for the bad wording, wasn’t really hinting at there being any real competition, and as stated above, that’s really one of the things I appreciate about these projects and the communities that revolve around them!
Can I bump this issue? Has it been resolved?
I too have followed the minimum, headless mzero install precisely, and actually have done it twice at this point, removing and reinserting the pisound from the pi inbetween the tries. and I am getting constant “snd_pcm_delay” errors trying to run even a simple automatonism patch with like one oscillator and a mixer.
e.g.:
hrm… what has changed? I will dig a bit… can @miker2049 and/or @anon86906493 tell me what Pd patch you are plaything that gets this? Are you launching these via the new app… I’ll go try that…
Update: I just up’d my system to the latest of everything (both Blokas & Raspian). And launched many of the new Pd patches via the Andriod app… all works splendidly. I was even doing this with X going, and VNC connection in… SO I’m really keen to find out what is different about your set ups, so we can solve this!
I can upload some screenshots later, but these errors would pop up for me when I opened up the test audio/midi patch, just 1-3 errors every time it was opened. Further, the example polysynth in the “stuff” folder of pd help would do this, but they would not happen in other simpler patches. Maybe something to do with pd-gui, as it only happens when actually loading up these patches? I am using the standard apt-get pd 0.47, with no externals or libraries installed other than having updated deken (through deken) to 0.5.
Its very strange considering there are not a lot of variables here right? I would say its maybe some kind of defective hardware thing… but jack does seem to work ok after having installed that and played around a little.
I am using a raspberry pi 3B+… maybe its a plus thing?
I dived into the Pure Data source code, and then into the ALSA library API… There seems to be some confusion this particular function… In short, the ALSA library doc is a tiny bit confusing…
warning: geekery ahead
The routine snd_pcm_delay is supposed to return the latency from the next buffer write to the DAC. But by “return” they mean set a value via a pointer argument. The actual return value of the function is supposed to be an error code.
The actual implementation of snd_pcm_delay is, of course, delegated to the drivers, and I checked what I could there… all looks fine…
BUT - The error messages are suspicious: The “Unknown error” codes look suspiciously like available buffer size: Each time it decreases by exactly 658. And it’s positive. It doesn’t look like an error code at all (the “Unknown error” message comes from ALSA, which doesn’t recognize it, either!). Furthermore, “astate 3” means things are running, and not in xrun. So, ALSA thinks things are fine.
658 is an odd number of samples: It is almost 15ms at 44,100Hz. But isn’t anything I’d expect to arise from normal settings.
Something is wrong somewhere in a driver…
end geekery
Can you all run this for me?
dpkg-query -l 'pisound*' 'libasound*'
I get:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=======================-================-================-====================================================
un libasound-dev <none> <none> (no description available)
ii libasound2:armhf 1.1.3-5+rpi3 armhf shared library for ALSA applications
ii libasound2-data 1.1.3-5+rpi3 all Configuration files and profiles for ALSA drivers
ii libasound2-dev:armhf 1.1.3-5+rpi3 armhf shared library for ALSA applications -- development
un libasound2-doc <none> <none> (no description available)
un libasound2-plugin-equal <none> <none> (no description available)
un libasound2-plugins <none> <none> (no description available)
ii pisound 1.03-1 all Pisound meta package.
ii pisound-btn 1.05-5 armhf Pisound Button daemon.
ii pisound-ctl 1.03-1 armhf Bluetooth service for Pisound companion mobile app.
I’m not sure how to query the version of the driver that ends up running the Pisound hardware… @Giedrius?
@mzero Thank you for looking into this! Great analysis!
pi@raspberrypi:~ $ dpkg-query -l 'pisound*' 'libasound*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=================================================-=============================-=============================-=======================================================================================================
un libasound-dev <none> <none> (no description available)
ii libasound2:armhf 1.1.3-5+rpi3 armhf shared library for ALSA applications
ii libasound2-data 1.1.3-5+rpi3 all Configuration files and profiles for ALSA drivers
ii libasound2-dev:armhf 1.1.3-5+rpi3 armhf shared library for ALSA applications -- development files
un libasound2-doc <none> <none> (no description available)
un libasound2-plugin-equal <none> <none> (no description available)
un libasound2-plugins <none> <none> (no description available)
ii pisound 1.03-1 all Pisound meta package.
ii pisound-btn 1.05-5 armhf Pisound Button daemon.
ii pisound-ctl 1.03-1 armhf Bluetooth service for Pisound companion mobile app.
The Pisound driver version number can be known from the kernel version number, using uname -a and the source code is in the Raspberry Pi’s Linux repo:
I also suspect it could be related to 3B+, I don’t remember these errors myself when using plain 3B, I will try reproducing it on plain 3B later today.
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===============-==============-============-=================================
ii libasound2:arm 1.1.3-5+rpi3 armhf shared library for ALSA applicati
ii libasound2-dat 1.1.3-5+rpi3 all Configuration files and profiles
un libasound2-plu <none> <none> (no description available)
un libasound2-plu <none> <none> (no description available)
ii pisound 1.02-2 all Pisound meta package.
ii pisound-btn 1.05-5 armhf Pisound Button daemon.
ii pisound-ctl 1.03-1 armhf Bluetooth service for Pisound com
I have a Rpi 3b not the “plus” version.
My install is just what’s in mzero’s guide, minus supercollider. Pd is the current one from the repo, I’ve got a bunch of externals installed from the repo, but haven’t added them to path.
I do get far less snd_pcm_delay errors than miker2049, I just see them with patches that do requite a bit of processing power / memory. I did experiment a bit with a patch that used to make lots of these before and I could clearly see that these started to happen as soon as I started to add more cpu-intensive things like partconv~
Hey does look like I am different here! Nothing here for me on “libasound2-dev:armhf”… edit fixed my output to show everything. This also seems to be @anon86906493 's difference with this stuff too
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-========================-=================-=================-======================================================
ii libasound2:armhf 1.1.3-5+rpi3 armhf shared library for ALSA applications
ii libasound2-data 1.1.3-5+rpi3 all Configuration files and profiles for ALSA drivers
un libasound2-plugin-equal <none> <none> (no description available)
un libasound2-plugins <none> <none> (no description available)
ii pisound 1.03-1 all Pisound meta package.
ii pisound-btn 1.05-5 armhf Pisound Button daemon.
ii pisound-ctl 1.03-1 armhf Bluetooth service for Pisound companion mobile app.
The -dev variation packages are needed when you’re building stuff from sources that depend on some package, in this case it looks like me and @mzero built something on our systems that depended on libasound2.
I can’t reproduce the snd_pcm_delay error messages anymore, but there are moments when the audio output is glitchy, especially when there’s processing in the background, however running this:
echo performance | sudo tee /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
improves things a lot. Looks like this needs to be done on every reboot, the default value ends up being ‘ondemand’, which I think is changing the CPU speed based on the current system load, and it may affect software that assumes constant CPU frequency.
Can you try reproducing the issue with the above command executed once after booting?
went ahead and tried apt-getting libasound2-dev, and the errors still persist. The “priority 6 scheduling failed; running at normal priority” at pd boot is now gone, but there are still errors on opening and closing even simple patches… most tellingly perhaps still happens in the Test Audio Midi.
But I did realize something, and maybe the plot thickens with this:
I will only get these errors if DSP is on when I am opening or closing a patch. So, the first time I open Test Audio Midi, I get nothing, but closing it, after the DSP has been switched on in the patch produces the errors. Same thing with the polysynth example in the puredata help directory.
Edit oops we’re talking over each other now, @Giedrius, ill do that right now and report back
Ok so performing the “echo performance |…” command did do something. There are no more errors from Audio Midi Test! But 1.poly.synth.pd is still producing them on opening and closing granted that dsp is on. This screenshot is just after loading and closing that patch multiple times. Always seemingly random forms of error… Every once in awhile, you can see, there is not an “Unknown error: ###” but something else like “Invalid Argument.”
I should also note that, while I could still certainly do some more testing, the only actual audio problem I have found so far, because I was curious to try this as a kind of rough benchmarking, was running this water simulator patch I found a little while ago. Now when I first run this, the sound is clearly not there (comparing with my experience and running it on the mac), only light distorted sounds. further, pd’s console is just constantly spitting out a “snd_pcm_delay failed: Device or resource busy” very quickly. As shown here:
Following the patch creator’s instructions, I went into the patch and deleted a large majority of the water abstractions until I get clean output, with the errors turning into the regular “Unknown errors” with their numbers, and then eventually it seems going away. I can then start adding back [water] objects until it starts doing its device or resource busy error again.
