ALSA output error (snd\_pcm\_open) Device or resource busy
Sorry to necro this thread, but I finally found out how to run PureData under Pulseaudio (which otherwise results with "ALSA output error (snd_pcm_open): Device or resource busy").
First of all, run:
pd -alsa -listdev
PD will start, and in the message window you'll see:
audio input devices: 1. HDA Intel PCH (hardware) 2. HDA Intel PCH (plug-in) audio output devices: 1. HDA Intel PCH (hardware) 2. HDA Intel PCH (plug-in) API number 1 no midi input devices found no midi output devices found
... or something similar.
Now, let's add the
pulse ALSA device, and run
pd -alsa -alsaadd pulse -listdev
The output is now:
audio input devices: 1. HDA Intel PCH (hardware) 2. HDA Intel PCH (plug-in) 3. pulse audio output devices: 1. HDA Intel PCH (hardware) 2. HDA Intel PCH (plug-in) 3. pulse API number 1 no midi input devices found no midi output devices found
Notice, how from the original two ALSA devices, now we got three - where the third one is
Now, the only thing we want to do, is that at startup (so, via the command line), we set
pd to run in ALSA mode, we add the
pulse ALSA device, and then we choose the third (3) device (which is to say,
pulse) as the audio output device - and the command line argument for that in
pd -alsa -alsaadd pulse -audiooutdev 3 ~/Desktop/mypatch.pd
Yup, now when you enable DSP, the patch
mypatch.pd should play through Pulseaudio, which means it will play (and mix) with other applications that may be playing sound at the time! You can confirm that the correct output device has been selected from the command line, if you open Media/Audio Settings... once
As the screenshot shows, now "Output device 1" is set to "pulse", which is what we needed.
Hope this helps someone!
EDIT: I had also done changes to
/etc/pulse/default.pa as per https://wiki.archlinux.org/index.php/PulseAudio#ALSA.2Fdmix_without_grabbing_hardware_device beforehand, not sure whether that makes a difference or not (in any case, trying to add
dmix as a PD device and playing through it, doesn't work on my Ubuntu 14.04)
curious: [clone] in sequence instead of sum
No sound from raspberry
I had the same difficulty. No sound cards were available according to
I found somewhere (I forget where) the suggestion to add to
and from then everything went swimmingly. I set up some (possibly pretty dangerous) values in
### realtime permission for audio @audio – rtprio 99 @audio – memlock unlimited @audio – nice -10 @audio - priority 8 # End of file
The audio priority of 8 seems to be necessary to stop annoying messages in the puredata console when it's started. I'm not an expert on these values, they might not be wise, safe or ideal but they worked for me.
And I made sure that my user is in the audio group:
usermod -a -G audio david
And I've had glitch free performance since out of the mini jack.
install pdl2ork on manjaro: fails to get flite installed..
Hi there, i also posted to the manjaro forum but i guess here i can find more expertise on that topic: i want to install pd-l2ork on manjaro (arch-based) linux and I get this error building flite:
Insert Co> Found flite1.patch ==> Validating source files with md5sums... flite-1.4-release.tar.bz2 ... Passed flite1.patch ... Passed ==> Extracting sources... -> Extracting flite-1.4-release.tar.bz2 with bsdtar ==> Starting prepare()... patching file config/common_make_rules ==> Starting build()... checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for ranlib... ranlib checking for a BSD-compatible install... /usr/bin/install -c checking for ar... ar checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking whether byte ordering is bigendian... no checking for mmap... yes checking sys/soundcard.h usability... yes checking sys/soundcard.h presence... yes checking for sys/soundcard.h... yes checking machine/soundcard.h usability... no checking machine/soundcard.h presence... no checking for machine/soundcard.h... no checking sys/audioio.h usability... no checking sys/audioio.h presence... no checking for sys/audioio.h... no checking mmsystem.h usability... no checking mmsystem.h presence... no checking for mmsystem.h... no configure: creating ./config.status config.status: creating config/config config.status: creating config/system.mak making in ... making in include ... making in src ... making in src/audio ... gcc -fPIC -D_FORTIFY_SOURCE=2 -I. -DCST_AUDIO_LINUX -I../../include -O3 -Wall -c auclient.c -o /tmp/yaourt-tmp-kalimerox/aur-flite1/obj/src/audio/auclient.os gcc -fPIC -D_FORTIFY_SOURCE=2 -I. -DCST_AUDIO_LINUX -I../../include -O3 -Wall -c auserver.c -o /tmp/yaourt-tmp-kalimerox/aur-flite1/obj/src/audio/auserver.os gcc -fPIC -D_FORTIFY_SOURCE=2 -I. -DCST_AUDIO_LINUX -I../../include -O3 -Wall -c audio.c -o /tmp/yaourt-tmp-kalimerox/aur-flite1/obj/src/audio/audio.os gcc -fPIC -D_FORTIFY_SOURCE=2 -I. -DCST_AUDIO_LINUX -I../../include -O3 -Wall -c au_streaming.c -o /tmp/yaourt-tmp-kalimerox/aur-flite1/obj/src/audio/au_streaming.os au_streaming.c: In function ‘audio_stream_chunk’: au_streaming.c:77:9: warning: variable ‘n’ set but not used [-Wunused-but-set-variable] int n; ^ gcc -fPIC -D_FORTIFY_SOURCE=2 -I. -DCST_AUDIO_LINUX -I../../include -O3 -Wall -c au_oss.c -o /tmp/yaourt-tmp-kalimerox/aur-flite1/obj/src/audio/au_oss.os au_oss.c: In function ‘audio_open_oss’: au_oss.c:86:25: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ad->platform_data = (void *)afd; ^ au_oss.c: In function ‘audio_close_oss’: au_oss.c:181:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] ioctl((int)ad->platform_data, SNDCTL_DSP_SYNC, NULL); ^ au_oss.c:182:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] rv = close((int)ad->platform_data); ^ au_oss.c: In function ‘audio_write_oss’: au_oss.c:189:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return write((int)ad->platform_data,samples,num_bytes); ^ au_oss.c: In function ‘audio_flush_oss’: au_oss.c:194:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return ioctl((int)ad->platform_data, SNDCTL_DSP_SYNC, NULL); ^ au_oss.c: In function ‘audio_drain_oss’: au_oss.c:199:18: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return ioctl((int)ad->platform_data, SNDCTL_DSP_RESET, NULL); ^ ar: ../../..//tmp/yaourt-tmp-kalimerox/aur-flite1/lib/libflite.shared.a: No such file or directory make: *** [../../config/common_make_rules:116: /tmp/yaourt-tmp-kalimerox/aur-flite1/obj/src/audio/.build_so] Error 1 make: *** [../config/common_make_rules:133: /tmp/yaourt-tmp-kalimerox/aur-flite1/obj/src/.make_build_dirs] Error 2 make: *** [config/common_make_rules:133: /tmp/yaourt-tmp-kalimerox/aur-flite1/obj//.make_build_dirs] Error 2 ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build flite1. de
anyone having the same issues or an advice=? ?
Multiple patches sending to the same Arduino / change block size?
I'm working on a project involving Pure Data and Arduino. The idea is to play an audio file while controlling a pump that breathes air into an aquarium, based on the envelope of the audio, so that the bubbles correspond to the voice that you hear in headphones.
My problem is, while it works perfectly with one aquarium (playing the audio file + controlling the pump), it's less precise, and sometimes completely off, when I'm adding the others.
The logic of one aquarium is inside an abstraction, [aquarium], with the file, threshold, audio output and Arduino pin as creation arguments. Every instance of the abstraction is playing its own file into a given audio output, and sending messages to the Arduino ("turn on pump X" or "turn off pump X"). It works quite well for most of the aquariums, so I guess (hope) the fix must be simple.
I tried different ideas to limit the message flow but didn't quite succeed (hence the mess below the [dac~] object, this stuff is not used anymore).
I only recently thought about increasing block size, thinking that would reduce the number of messages sent to the Arduino. However using the audio settings, it didn't seem to change anything, and I'm not sure how to use the [block~] object. Do I have to send the audio output through an [outlet~] object? I guess that would mean each of my 9 [aquarium…] blocks would need to have 9 outlets going into a [dac~] object in my main patch, and that would be a big spaghetti plate
I'd be curious to know if any of you has ever encountered this kind of issue, or has an idea to fix it, either with block size, pure data magic or anything else…
Pd doesn´t run when connecting an external audio interface.
I have been using Pd for a while, and now I am working on some patches with an external audio interface to get audio input from a guitar. However, I am experiencing a problem with one of my audio interfaces.
I have the Alesis io4 audio card. I can connect it to my computer and use it with other software without any problems. However, when I try to launch Pd with this interface connected, Pd suddenly crashes without reporting any error. I have tried to use another interface (Scarlet 2i2) and Pd opens succesfully.
I would like to know if someone have experienced this problem with an external audio device, and if so, if you have any idea about how to solve it. Maybe is there any configuration i should do before the software can recognize the device?
Thanks for your attention,
Cubie pd pedal
I've been working on that for nearly two years and now it is done I find it soooo 2014 that the previous intentions to make a full wiki page seem now silly. Anyway this could give ideas to other people so here is an abstract.
This is basically a lame-electronics simple-aggregate-of-common-parts version of a guitar pedal that hosts pd extended patches as effects. It's based on a cubieboard 2, connected to an el-cheapo (this was intended as a proof of concept hardware) soundcard through usb, internally. It boots a rt-patched version of debian from microSD card (never managed to flash sdram) in ... 50seconds , with autologin so no keyboard is needed. After this time it behaves like a floor pedal, pd runs the stored patches responding to its hardware interface. Anyway a keyboard, a mouse and a display can be plugged in and it behaves like a linux desktop, it's easy to edit patches on the fly.
The interface consists of three footswitches, three leds, a button switch, a clickable rotary encoder, four clickable potentiometers and a 4x20 lcd display. The pots and the display communicate with the gpio pins (all of them digital) through i2c, the pots being read by a quadruple i2c adc.
I called it a pd pedal, but I have to confess it cannot be directly connected to a guitar amp, as the IO are two preamplified instrument inputs, two line in, two line out and a headphone stereo jack. This can be solved when you have a digital pedal in your pedalboard that have line inputs. Of course I knew it from the beginning, and could never work it around later as it would have taken more space and would have been tedious to implement for a beginner electronics fan like me .
I also wanted from the beginning to make a relatively small footprint on my pedalboard so it is rather tall (aluminium box is 160x125x76). What a challenge to stack these components in such a box it has been, especially when it came with holes positioning, elements fixture, internal aluminium rounded edges to mill and file down...
The 1 ghz dual-core with 1 gb ram allows for decent dsp patches.
The pedal automatically runs a predefined patch but interface allows for patch selection. (statically coded so far)
I initially wrote several externals that allow for interface i/o, but never got rid of audio artifacts when the interface was trigged. As a workaround I now make the readings from outside pd, with a well-choosen rt priority and send values to pd using pdsend. The workaround is only half of what it should be, as for outputting data (writing things on the display) I still rely on a homebrew pd external (too much work for me to take it out of pd). The result is uncorrupted audio only when lcd display is not used, which is unreasonable (every pot controls a patch parameter and I love to see the values updated on the lcd). But when the pedal is left untouched the audio is clean.
Here are two pics, one of the inside before the audio card is stacked and the other one showing it outside look.
Noise filter for microphone (Live Audio)
Well, the forum crash seems to have eaten my last post.
I have made a noise filter to clean up audio signals live.
Other noise removal filters need to have a noise sample selected and try to remove that noise from the complete track - they only work offline.
This patch works online. It removes any stationary noise from the signal and doesn't need any user adjustment except that it does need to be told how much to reduce the noise.
"Stationary noise" is a signal whose frequency content and amplitude stay (more or less) constant for over 1 second. Fan hum is a good example, as well as the more or less "white" noise from the wind from the fan. Car motor sounds from a car travelling at constant speed is also a good example.
It will also kill feedback squeal cold, even at the lowest settings.
The patch is built in layers, and the lower layers can be used independently or combined and used to build different filters.
The attached zip file includes all the components from the lowest level up to a complete demonstation that takes in audio from a microphone and puts out filtered audio on line out. It also includes a set of help files that describe the function and use of the various modules.
NoiseLevelDetector.pd - estimates the amplitude of the stationary noise
NoiseFilter.pd - attenuates the signal based on the amplitude from
NoiseLevelDetector.pd Since it is more effective at high frequencies, it is best to feed it limited bandwidth signals and use multiple filters to cover the desired audio range.
BandLimitedNoiseFilter.pd - a Noisefilter that only works on the specified frequency range.
MultibandNoiseFilter.pd - a complete filter that covers the range from 40Hz upto 22000 hz to filter the complete audio spectrum.
Test.pd - demo program that demonstrates the use of MultibandNoiseFilter.pd
It works best for speaking voices. Singing tends to be more stationary. It could be adapted to singing voices by changing a single value in one of the lower level blocks.
The original idea was to create filter for removing car noises from microphone audio for two-way radios. When used to cover just the range from 300Hz to 3000Hz, it does a very good job.
The biggest disadvantage is that it will start making "musical noise" if there is a lot of noise and the attenuation is set high. It also adds a slight echoing quality to the filtered audio.
The project is hosted on GitHub: PureData NoiseFilter project.
PD sending to two devices?
You can assign discreet inputs and outputs but not multiple outputs across different audio devices. Sound software has to access sound hardware through it's drivers and it can't handle 2 sets of calls to two different drivers (if someone has the proper tech jargon, please step in).
There are ways of cheating but they all stink in some way:
On windows: VAC/audio repeater combo
You can use 'Virtual Audio cables' to create virtual devices that you can use for input and output between software. You can piggy-back that audio to different hardware devices by using the audiorepeater utility. So you can set up VAC to make 2 cables (VAC1 and VAC2). PD will use VAC1 and VAC2 as outputs. (Since VAC1 or VAC2 aren't hooked up to real hardware, you don't hear anything.) Then you run 2 instances of audiorepeater. One instance routes VAC1 to 'Onboard speaker out' and the other instance will route VAC2 to 'USB audio device out'.
Downside: Latency, Latency, Latency
The sound is delayed through each step in the chain, and the audio repeater latency can only go but so low before you get scratchy static and dropouts.
On Linux: ALSA virtual device
You can make a virtual soundcard using ALSA that can combine the outputs of two audio cards into one
'virtual' one and then set JACK to output to that device (the setup of which is too complex to explain here).
Each soundcard has it's own timing, and there's no way to keep them in synch, so you can control the latency and you'll have clicks, pops, dropouts, and tons of underruns.
On Mac OSX:
I haven't tried it, but I believe you can also make an aggregate device
There is also a VAC/audiorepeater type program you can use called Soundflower, but like VAC it's really only for routing sound between apps, not between hardware.
Long story short, between the latency introduced by the software and the clock timing differences between soundcards, you can really get anything usable.
0mms delay time in pd is it a dream?
0ms will be impossible I suspect just due to the way that digital audio works.
Start by assuming that everything is dealing with 64 sample blocks of audio. This is a big assumption as I'm not sure how audio hardware is going to do what it does but it should be fine for some rough calculations.
We'll also just be dealing with one channel here.
Audio hardware needs to capture that 64 samples of data from one channel. It won't send that data down the USB/Firewire/PCI bus until it has the full 64 samples which means that there is already delay there, the first sample won't be sent until the last is captured.
(1 second / 44100 samples) * 64 = 0.00145 or about 1 and a half milliseconds
Even with the best audio hardware this limitation is still there.
On top of this you need to add on the time to process the audio, there will probably be some time wasted scheduling everything etc etc. ultimately you're always going to have a couple of milliseconds latency between audio coming into the computer and then going back out.
that said, how much of an issue would 5ms latency be? generally people can't notice anything less than 20ms of latency and I understand that Yamaha engineers aim for about 4 or 5 ms of latency with all their electronic midi controllers/instruments as that's the point that it sounds instantaneous to people.
Someone with more experience here please feel free to correct me if I'm wrong though