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.

Michael.

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-m...@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@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
> 
> _______________________________________________
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list



--
noise chasers: http://blauwurf.at 
http://soundcloud.com/noiseconformist




_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Reply via email to