[PD] Pd Vanilla on Raspberry Pi

Michael Zacherl sdiy-mz01 at blauwurf.info
Mon Aug 13 13:40:10 CEST 2012

On 12.8.2012, at 23:19 , Stephen Lucas wrote:

> I've gotten my Rpi to run pd-vanilla using the regular apt-get install on RPi Wheezy 7/15/2012.
> I'm using the 3.5mm out jack because that's simpler for me to pipe into my monitoring system.
> I wasn't very systematic about documenting the process but I'll try to recount the steps I took to get it running.

besides the output selection issue it's pretty straight forward!

> I did have to do some monkeying with the config.txt to get it to stop defaulting to HDMI.
> http://elinux.org/RPi_config.txt 
> I also did some of these steps which seemed to turn off auto default output
> http://raspberrypi.stackexchange.com/questions/44/why-is-my-audio-sound-output-not-working 

Thanks for that! I was just about to look that up.
I didn't run into that until recently when I finally connected the RPi to a proper HDMI screen (which I don't have myself)

> I have the audio output set to ALSA (hardware) with 2channels.

AFAIK that's the only way it works.  JACK is not available yet.

> The 3.5mm audio output is a bit dirty sounding. This it really obvious with pure tones but not too terrible with more complex sounds. I've heard that the HDMI audio output doesn't have this problem as much. I did have to turn the output delay up to 500-1000ms and the audio vector to 512.

the 'quality' of the sound from the audio socket is a real pain. 
And it stays like that regardless the settings I have in Pd's audio settings.
At some point I'll investigate the options to connect USB-audio but I'm afraid at the current state of the software it will be full of glitches as well.

> I got the phase vocoder running and it sounds fine. However, any additional CPU work interrupts PD and causes some very nasty full output crackles. This includes (what I believe are) CPU rendered mouse cursor movements, meaning that touching the mouse usually interrupts audio. This is not always predictable as I'm sure there are some background processes that are also interfering a little.

It was even worse with the original Debian image the RPi-team released (with no fpu enabled).
It also happens when accessing the SD-card and do other operation (via the shell w/ no GUI) or network traffic (I use ssh).
Compared to earlier versions now it's almost ok-ish but I think there's still a lot of room for improvement.
There's some comment on this:  http://www.raspberrypi.org/phpBB3//viewtopic.php?f=38&t=10538
Try loading a patch while audio is on.

So far I absolutely wouldn't consider the RPi as a performance platform rather than for installation stuff and the like 
which are more likely to be in a dedicated, sort of optimised headless operation.

> I haven't tested any of my really large/intense audio patches to get an idea of where the thresholds are.

I got Pd-extended running and I get about 40-50% cpu load with the fiddle~ help-file plus some extra messaging and no GUI!
With GUI it goes to over 90% - again, room for improvement, but then ... see above.
My large patches need quite some attention (it's the first time I run Pd on Linux BTW :-\  ) but from the experience so far I doubt they will be ok.
It's just too much. 
I tried Sakonda's old pitch shifter which I ported from Max to Pd some time ago and this is working nicely.
But anything fpu-related will be a challenge.

> My main goal is to get Gem going so I'll send an update when I have more progress on that.

I'm curious about that! So far I found out that Gem needs GLX which isn't provided by the RPi.
Didn't do any further reading on this and I don't have any HDMI hardware at home so I just used X11 on my Mac,
where Gem is ok.

In fact we are early adopters doing all this, and it's good to see what's possible for the money.
Then again I think it's important to draw a clear line where the application of the RPi makes sense and where not.
It has quite some potential but also can turn quickly into a time-munching critter.


PS: I just noticed $0 delivers the same value in every instance. I suspect that's caused by using X11.
Could you PLS verify if it's any different using a local HDMI screen?  thx!

> On Sat, Aug 11, 2012 at 1:36 PM, Michael Zacherl <sdiy-mz01 at blauwurf.info> wrote:
> On 11.8.2012, at 19:58 , Michael Zacherl wrote:
> > it is!
> > Looking at the http://raspberry.org site the list of interesting or just funny
> sorry, of course this should have been http://raspberrypi.org !
> --
> feed your perception: http://blauwurf.at
> http://soundcloud.com/noiseconformist
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

noise chasers: http://blauwurf.at 

More information about the Pd-list mailing list