Dear List,
I'm happy to inform you (some of you may already know this) that PD vanilla works out of the box on my new raspberry pi running the standard Raspbian OS. A simple apt=get install worked like a charm, no need to tweek anything, I got the sound working right away. The method proposed by TedbOt recently doesn't seem to be necessary anymore. I'll try pd=extended sometime soon.
Cheers,
Pierre. Sent from my Raspberry Pi, hahaha !
Thanks to whoever made this happen -- I think some of the credit goes to Guenter Geiger who packaged Pd for Debian. I'm curious - what version of Pd cane up? And can you run the phase vocoder (audio example (doc/3.audio.examples/I07.phase.vocoder.pd) ? That took $30,000 worth of hardware when I first got the equivalent patch running around 1994.
cheers Miller
On Thu, Aug 09, 2012 at 09:25:38PM +0000, Pierre Massat wrote:
Dear List,
I'm happy to inform you (some of you may already know this) that PD vanilla works out of the box on my new raspberry pi running the standard Raspbian OS. A simple apt=get install worked like a charm, no need to tweek anything, I got the sound working right away. The method proposed by TedbOt recently doesn't seem to be necessary anymore. I'll try pd=extended sometime soon.
Cheers,
Pierre. Sent from my Raspberry Pi, hahaha !
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
This is really excellent news! I haven't tried Raspbian yet. I will as soon as I have some time. Has anyone tried accessing the GPIO with Pd yet?
cheers
On Fri, Aug 10, 2012 at 7:40 AM, Miller Puckette msp@ucsd.edu wrote:
Thanks to whoever made this happen -- I think some of the credit goes to Guenter Geiger who packaged Pd for Debian. I'm curious - what version of Pd cane up? And can you run the phase vocoder (audio example (doc/3.audio.examples/I07.phase.vocoder.pd) ? That took $30,000 worth of hardware when I first got the equivalent patch running around 1994.
cheers Miller
On Thu, Aug 09, 2012 at 09:25:38PM +0000, Pierre Massat wrote:
Dear List,
I'm happy to inform you (some of you may already know this) that PD
vanilla
works out of the box on my new raspberry pi running the standard Raspbian OS. A simple apt=get install worked like a charm, no need to tweek anything, I got the sound working right away. The method proposed by
TedbOt
recently doesn't seem to be necessary anymore. I'll try pd=extended sometime soon.
Cheers,
Pierre. Sent from my Raspberry Pi, hahaha !
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
Hi,
@ Miller : I think it's Pd 43 something (I use 42 on my latptop and it look slightly different). Unfortunately the phase vocoder example doesn't work, I do get some sound out of it but only in small distant chunks. Even the pitchshifter example doesn't work. The reverb example does work though. Please note that I tried all of these with the ethernet cable plugged in, I think it was using a substantial share of the CPU.
@ Richie : I haven't tried the GPIO yet. I find it a bit frustrating when they say that audio input can be added easily through the GPIO. I don't think it's true. It would take a lot of hardware around a good ADC, plus I guess a custom driver. There aren't any DIY audio ADCs on the web that I know of, except a project by a German guy who builds ADCs and DACs frm scratch.
One thing I would like to know is how difficult it would be to run Pd on this machine at a very low level, with a very minimal OS (I know nothing about this kind of things). 700MHz is a lot I believe, considering that a lot of digital audio gear was available before this chips were affordable. I'm pretty sure that a standard digital multi-effects for instance doesn't need 700MHz at all. I've been dreaming of building this "Pd box" people have been talking about for many months now, and I can imagine what a revolution it would be if it was open source.
Cheers,
Pierre.
2012/8/10 Richie Cyngler glitchpop@gmail.com
This is really excellent news! I haven't tried Raspbian yet. I will as soon as I have some time. Has anyone tried accessing the GPIO with Pd yet?
cheers
On Fri, Aug 10, 2012 at 7:40 AM, Miller Puckette msp@ucsd.edu wrote:
Thanks to whoever made this happen -- I think some of the credit goes to Guenter Geiger who packaged Pd for Debian. I'm curious - what version of Pd cane up? And can you run the phase vocoder (audio example (doc/3.audio.examples/I07.phase.vocoder.pd) ? That took $30,000 worth of hardware when I first got the equivalent patch running around 1994.
cheers Miller
On Thu, Aug 09, 2012 at 09:25:38PM +0000, Pierre Massat wrote:
Dear List,
I'm happy to inform you (some of you may already know this) that PD
vanilla
works out of the box on my new raspberry pi running the standard
Raspbian
OS. A simple apt=get install worked like a charm, no need to tweek anything, I got the sound working right away. The method proposed by
TedbOt
recently doesn't seem to be necessary anymore. I'll try pd=extended sometime soon.
Cheers,
Pierre. Sent from my Raspberry Pi, hahaha !
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
-- Richie
www.glitchpop.com
Hi again,
On 10.8.2012, at 09:10 , Pierre Massat wrote:
@ Richie : I haven't tried the GPIO yet. I find it a bit frustrating when they say that audio input can be added easily through the GPIO. I don't think it's true. It would take a lot of hardware around a good ADC, plus I guess a custom driver. There aren't any DIY audio ADCs on the web that I know of, except a project by a German guy who builds ADCs and DACs frm scratch.
I'm not sure if Richie meant audio in when he talked about GPIO. But, @Richie, since Python is the tool of choice on the RPi world it shouldn't be too hard to get some decent control of external hardware via Pd. However, Pierre, I share your thought about GPIO and audio and I'm not sure if that's the route to go. There would be a lot of effort to get this done and I rather prefer to get something like Jack running smoothly (which currently isn't due to driver issues, IIRC). I'd rather get a small, cheapish USB audio interface running which I also could strip and mount into the same box with the RPi. If this works, I don't see a reason why some serious hardware like an RME Fireface UCX shouldn't run as well in Class Compliant Mode. (which would be rather funny, but why not if somebody got it at hands?)
One thing I would like to know is how difficult it would be to run Pd on this machine at a very low level, with a very minimal OS (I know nothing about this kind of things). 700MHz is a lot I believe, considering that a lot of digital audio gear was available before this chips were affordable. I'm pretty sure that a standard digital multi-effects for instance doesn't need 700MHz at all.
Ethernet is done via USB on the RPi, that's one reason they didn't go for gigabit ethernet, just wouldn't make sense. So I sense (lack of knowledge though) some potential to strip down the OS to free ressources. Also a RT-kernel is planned, but there I don't know much else, didn't use a RT-system so far. At some point I'll go through the points listed here and see what it can do: http://puredata.info/community/pdwiki/Optimize/
I've been dreaming of building this "Pd box" people have been talking about for many months now, and I can imagine what a revolution it would be if it was open source.
oh yes, and the RPi can run from four AA batteries ... ;-)
m.
-- noise chasers: http://blauwurf.at http://soundcloud.com/noiseconformist
Am 10.08.2012 um 15:54 schrieb Michael Zacherl:
If this works, I don't see a reason why some serious hardware like an RME Fireface UCX shouldn't run as well in Class Compliant Mode. (which would be rather funny, but why not if somebody got it at hands?)
The RME FF 400 UCX is actually specifically advertized for that usage. It's probably the only commercial interface available providing an 8 channel class compliant mode. gr~~~
-- Thomas Grill http://grrrr.org
On 13.8.2012, at 09:59 , Thomas Grill wrote:
Am 10.08.2012 um 15:54 schrieb Michael Zacherl:
If this works, I don't see a reason why some serious hardware like an RME Fireface UCX shouldn't run as well in Class Compliant Mode. (which would be rather funny, but why not if somebody got it at hands?)
The RME FF 400 UCX is actually specifically advertized for that usage. It's probably the only commercial interface available providing an 8 channel class compliant mode.
That's correct, I missed to make my point that the product of course needs to support Class Compliant Mode. RME aims specifically at the tablet-market, so maybe others will follow. m.
-- keep your ears open: http://blauwurf.at http://soundcloud.com/noiseconformist
Hi,
Pierre Massat wrote:
One thing I would like to know is how difficult it would be to run Pd on this machine at a very low level, with a very minimal OS (I know nothing about this kind of things). 700MHz is a lot I believe, considering that a lot of digital audio gear was available before this chips were affordable. I'm pretty sure that a standard digital multi-effects for instance doesn't need 700MHz at all.
There's a big difference between a dedicated chip or a microcontroller with a single-task firmware, and a general purpose multitasking OS. A 2USD chip with a few lines of code can do nanosecond accurate timings, where you need a real-time flavor and a lot of pain to achieve the same with Linux on a PC. There's just two different kind of beasts.
I feel there's a lot of deception coming about the Rasberry Pi's capabilities. But well, it's pretty good for the price.
Cheers,
On 11.8.2012, at 14:15 , Charles Goyard wrote:
Hi,
Pierre Massat wrote:
One thing I would like to know is how difficult it would be to run Pd on this machine at a very low level, with a very minimal OS (I know nothing about this kind of things). 700MHz is a lot I believe, considering that a lot of digital audio gear was available before this chips were affordable. I'm pretty sure that a standard digital multi-effects for instance doesn't need 700MHz at all.
There's a big difference between a dedicated chip or a microcontroller with a single-task firmware, and a general purpose multitasking OS. A 2USD chip with a few lines of code can do nanosecond accurate timings, where you need a real-time flavor and a lot of pain to achieve the same with Linux on a PC. There's just two different kind of beasts.
I feel there's a lot of deception coming about the Rasberry Pi's capabilities. But well, it's pretty good for the price.
it is! Looking at the http://raspberry.org site the list of interesting or just funny but nevertheless nice projects grows constantly. You're absolutely right regarding timing and OS issues. I never (never say never again ;-) would use a thing like the RPi for building just a controller which is much easier and more efficiently implemented with an AVR or PIC in their respective environments. The ARM's floating point power is so-so, but there is some potential to use this tiny thing in an installation to combine for instance sound and hardware control within one kit. And it can be run from batteries (I personally didn't test that so far, but that's on my long to-do list.) At the moment Pd is the only environment of this kind of software which is within reach to be usable for serious applications. Supercollider could be next, but this still needs Jack Audio which isn't running on the RPi so far. And since Python is the programming language of choice to access the I/O hardware on the RPI it looks pretty good to get being very usable within Pd.
m.
-- noise chasers: http://blauwurf.at http://soundcloud.com/noiseconformist
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
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.
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-outp...
I have the audio output set to ALSA (hardware) with 2channels.
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.
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.
I haven't tested any of my really large/intense audio patches to get an idea of where the thresholds are.
My main goal is to get Gem going so I'll send an update when I have more progress on that.
-Stephen Lucas
On Sat, Aug 11, 2012 at 1:36 PM, Michael Zacherl sdiy-mz01@blauwurf.infowrote:
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
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-outp...
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-mz01@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
Hi all,
I don't know whether this was mentioned here, but the audio output throught the built in jack is bad because it uses PWM followed by a filter, no real dedicated dac. You can tweek the settings of Pd for years but you'll never get an good quality sound out of it.
Pierre.
2012/8/13 Michael Zacherl sdiy-mz01@blauwurf.info
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-outp...
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-mz01@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
Huh, really? How did you find this out?
—tedb0t
On Aug 13, 2012, at 8:43 AM, Pierre Massat wrote:
Hi all,
I don't know whether this was mentioned here, but the audio output throught the built in jack is bad because it uses PWM followed by a filter, no real dedicated dac. You can tweek the settings of Pd for years but you'll never get an good quality sound out of it.
Pierre.
Hi all,I am looking for a simple way to play midifiles from pd and being able to set alter their base tempo. It seems Mr.Peach [midifile] doesn't offer that possibility so, what would you suggest me to do?Thanks in advanceJosep M
On 2012-08-13 10:34, Jeppi Jeppi wrote:
Hi all, I am looking for a simple way to play midifiles from pd and being able to set alter their base tempo. It seems Mr.Peach [midifile] doesn't offer that possibility so, what would you suggest me to do?
The bangs you send to [midifile] set the tempo. [midifile] actually ignores the tempo of the midi file and you can play it at whatever speed you like by changing the [metro]. For example [metro 1.5] plays twice as fast as [metro 3]. Each bang advances the tick count of the midi file by one. There is a field in each midi file that specifies how many ticks per quarter note, so you can make playback tempo-accurate by reading that value and setting the metro accordingly, at least if you know which notes are quarter notes ;) The right outlet of [midifile] outputs status from the file including ticks_per_quarternote and microsec_per_quarternote.
Martin
Thanks in advance Josep M
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hey folks - just commenting on USB class compliant devices - the Tascam US-800 interface (about $100US) is another class compliant device. it's been shown to work reliably with 8 track recording on iPad. just wanted folks to know there was a cheaper interface option out there, though i'd certainly love to own a Fireface USB interface myself. The US-800 has 6 Neutrik inputs with phantom, 2 SPDIF (Stereo In and Out) and 4 unbalanced outs. it's very light, though, and it may be possible (with modification) to stick the R-Pi inside its case.
hope this might help somebody...
scott
On Mon, Aug 13, 2012 at 6:54 AM, Tedb0t lists@liminastudio.com wrote:
Huh, really? How did you find this out?
—tedb0t
On Aug 13, 2012, at 8:43 AM, Pierre Massat wrote:
Hi all,
I don't know whether this was mentioned here, but the audio output
throught the built in jack is bad because it uses PWM followed by a filter, no real dedicated dac. You can tweek the settings of Pd for years but you'll never get an good quality sound out of it.
Pierre.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
This is good news about the TASCAM devices (I see there's a whole series of them and they're cheap.) I've also heard that Presonous's interfaces are class compliant, but I've now forgotten who told me that.
I read some months ago on the Raspberry Pi site that it should perform "about like a 300 mHz Pentium II" - and the fact that it runs the phase vocoder patch without running out of CPU cycles roughly confirms that.
For those of you who are getting skips in the sound, I'm curious if Pd is printing the usual messages like:
priority 96 scheduling enabled. priority 98 scheduling enabled.
on standard error when it starts up -- if not, it would be worth trying to figure out how to get Pd to be able to get real-time priority which might fix some of the problems.
cheers Miller
On Mon, Aug 13, 2012 at 08:35:25AM -0700, Scott R. Looney wrote:
hey folks - just commenting on USB class compliant devices - the Tascam US-800 interface (about $100US) is another class compliant device. it's been shown to work reliably with 8 track recording on iPad. just wanted folks to know there was a cheaper interface option out there, though i'd certainly love to own a Fireface USB interface myself. The US-800 has 6 Neutrik inputs with phantom, 2 SPDIF (Stereo In and Out) and 4 unbalanced outs. it's very light, though, and it may be possible (with modification) to stick the R-Pi inside its case.
hope this might help somebody...
scott
On Mon, Aug 13, 2012 at 6:54 AM, Tedb0t lists@liminastudio.com wrote:
Huh, really? How did you find this out?
—tedb0t
On Aug 13, 2012, at 8:43 AM, Pierre Massat wrote:
Hi all,
I don't know whether this was mentioned here, but the audio output
throught the built in jack is bad because it uses PWM followed by a filter, no real dedicated dac. You can tweek the settings of Pd for years but you'll never get an good quality sound out of it.
Pierre.
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
On 13.8.2012, at 20:29 , Miller Puckette wrote:
This is good news about the TASCAM devices (I see there's a whole series of them and they're cheap.) I've also heard that Presonous's interfaces are class compliant, but I've now forgotten who told me that.
I read some months ago on the Raspberry Pi site that it should perform "about like a 300 mHz Pentium II" - and the fact that it runs the phase vocoder patch without running out of CPU cycles roughly confirms that.
I just checked the Phase Vocoder (compile of Pd-extended on Raspbian) via X11 redirect:
Pd eats about 68% CPU load running a 2k window.
A 4k window causes about 75% CPU load where occasional glitching occurs.
To avoid additional system load I tried to run it with -nogui (after preparing the patch) via ssh but the system claims the sound device is busy. Didn't find out why so far, a simple test-patch runs fine though. No idea what's going on.
For those of you who are getting skips in the sound, I'm curious if Pd is printing the usual messages like:
priority 96 scheduling enabled. priority 98 scheduling enabled.
on standard error when it starts up --
no, no such messages at start up.
if not, it would be worth trying to figure out how to get Pd to be able to get real-time priority which might fix some of the problems.
BTW, is it possible to quit Pd via the patch? Just in case Pd has such high priority that the system becomes inaccessible.
thanks, Michael.
On Mon, Aug 13, 2012 at 08:35:25AM -0700, Scott R. Looney wrote:
hey folks - just commenting on USB class compliant devices - the Tascam US-800 interface (about $100US) is another class compliant device. it's been shown to work reliably with 8 track recording on iPad. just wanted folks to know there was a cheaper interface option out there, though i'd certainly love to own a Fireface USB interface myself. The US-800 has 6 Neutrik inputs with phantom, 2 SPDIF (Stereo In and Out) and 4 unbalanced outs. it's very light, though, and it may be possible (with modification) to stick the R-Pi inside its case.
hope this might help somebody...
scott
On Mon, Aug 13, 2012 at 6:54 AM, Tedb0t lists@liminastudio.com wrote:
Huh, really? How did you find this out?
—tedb0t
On Aug 13, 2012, at 8:43 AM, Pierre Massat wrote:
Hi all,
I don't know whether this was mentioned here, but the audio output
throught the built in jack is bad because it uses PWM followed by a filter, no real dedicated dac. You can tweek the settings of Pd for years but you'll never get an good quality sound out of it.
Pierre.
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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- feed your perception: http://blauwurf.at http://soundcloud.com/noiseconformist
Thanks for the info... some quick ideas:
To avoid additional system load I tried to run it with -nogui (after preparing the patch) via ssh but the system claims the sound device is busy. Didn't find out why so far, a simple test-patch runs fine though. No idea what's going on.
This could be permission thing. When someone logs into the X windows system it gives that user read/write accesss to audio, which is denied for anyone else for security reasons (someone could ssh in and eavsdrop on you :) To see if that's the issue you could try running Pd via ssh with and without separately logging into X windows. The fix I found (besides just running as root which will nuke any permissions problem) was to add my username to group 'audio'. On Fedora I did this be editing the file /etc/gshadow (which had permission 0 which I had to change and restore). Not sure if it's the same in Debian land where RPi lives.
As to real-time permission, again on Fedora the trick is to add lines like
- rtprio 99
- memlock 1000000000
to the file, /etc/security/limits.conf ... this is permissive; you can be more restrictive if you want to tune it more carefully.
BTW, is it possible to quit Pd via the patch? Just in case Pd has such high priority that the system becomes inaccessible.
Yep: the message is "; pd quit"
cheers Miller
thanks, Michael.
On 14.8.2012, at 01:47 , Miller Puckette wrote:
Thanks for the info... some quick ideas:
good to know but that didn't help.
I can't tell what it is but apparently it's a timing or order of execution issue at startup in batch-mode: Delaying the ; pd dsp 1 message by 200ms helps avoiding the "device busy" error. Same patch loaded in the gui, no problem. :-\
According to 'top' the cpu load drops from 75% to about 70% with -nogui for a 4k-window. Just about enough to avoid glitching. But any system activity brings the sound to a halt for a short moment.
So that was just an ssh-session and Pd running in batch-mode.
At some point I'll go through this and see what can be done: http://puredata.info/community/pdwiki/Optimize/
BTW, is it possible to quit Pd via the patch? Just in case Pd has such high priority that the system becomes inaccessible.
Yep: the message is "; pd quit"
ah, of course!
thanks, Michael.
-- feed your perception: http://blauwurf.at http://soundcloud.com/noiseconformist
Hi everyone,
I got this info about the anolog audio output being cheap PWM with filtering from this thread : http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=8684 I'm assuming these guys know what they're talking about (I think the first reply metioning this is by a member of the Raspberry Pi team.
Cheers,
Pierre
2012/8/14 Michael Zacherl sdiy-mz01@blauwurf.info
On 14.8.2012, at 01:47 , Miller Puckette wrote:
Thanks for the info... some quick ideas:
good to know but that didn't help.
I can't tell what it is but apparently it's a timing or order of execution issue at startup in batch-mode: Delaying the ; pd dsp 1 message by 200ms helps avoiding the "device busy" error. Same patch loaded in the gui, no problem. :-\
According to 'top' the cpu load drops from 75% to about 70% with -nogui for a 4k-window. Just about enough to avoid glitching. But any system activity brings the sound to a halt for a short moment.
So that was just an ssh-session and Pd running in batch-mode.
At some point I'll go through this and see what can be done: http://puredata.info/community/pdwiki/Optimize/
BTW, is it possible to quit Pd via the patch? Just in case Pd has such high priority that the system becomes
inaccessible.
Yep: the message is "; pd quit"
ah, of course!
thanks, Michael.
-- 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
OK... this business of having to delay "pd dsp 1" is probably the same problem some others have been having with pd -nogui - I need to investigate that one. Meanwhile there's still the problem of Pd not getting real-time scheduling turned on, which must be some kind of configuration thing. Getting that fixed would probably help a lot.
cheers Miller
On Tue, Aug 14, 2012 at 05:14:48AM +0200, Michael Zacherl wrote:
On 14.8.2012, at 01:47 , Miller Puckette wrote:
Thanks for the info... some quick ideas:
good to know but that didn't help.
I can't tell what it is but apparently it's a timing or order of execution issue at startup in batch-mode: Delaying the ; pd dsp 1 message by 200ms helps avoiding the "device busy" error. Same patch loaded in the gui, no problem. :-\
According to 'top' the cpu load drops from 75% to about 70% with -nogui for a 4k-window. Just about enough to avoid glitching. But any system activity brings the sound to a halt for a short moment.
So that was just an ssh-session and Pd running in batch-mode.
At some point I'll go through this and see what can be done: http://puredata.info/community/pdwiki/Optimize/
BTW, is it possible to quit Pd via the patch? Just in case Pd has such high priority that the system becomes inaccessible.
Yep: the message is "; pd quit"
ah, of course!
thanks, Michael.
-- 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
On 9.8.2012, at 23:25 , Pierre Massat wrote:
Dear List,
I'm happy to inform you (some of you may already know this) that PD vanilla works out of the box on my new raspberry pi running the standard Raspbian OS. A simple apt=get install worked like a charm, no need to tweek anything, I got the sound working right away. The method proposed by TedbOt recently doesn't seem to be necessary anymore. I'll try pd=extended sometime soon.
Hey, did you get audio via the audio connector or via HDMI? I compiled pd-extended from a daily snapshot on Raspbian and it works nicely via HDMI but the audio from the dedicated socket has glitches. Performance is so-so, a modified bpq2 example works nicely (added noise and a LFO to modulate the filter's frequency), but freeverb for instance nailed the cpu at 100% and left only smallest chunks of sound for the ear. GEM only works with an external xserver (like the X11 I have on my Mac) since RPi doesn't come with GLX. I could upload my package (where?) if you want, BTW - compile takes some hours and clogs the entire machine. Michael.
-- feed your perception: http://blauwurf.at http://soundcloud.com/noiseconformist
Hi Michael, I got the audio through the HDMI. I have tried the audio output yet.
Pierre.
2012/8/10 Michael Zacherl sdiy-mz01@blauwurf.info
On 9.8.2012, at 23:25 , Pierre Massat wrote:
Dear List,
I'm happy to inform you (some of you may already know this) that PD
vanilla works out of the box on my new raspberry pi running the standard Raspbian OS. A simple apt=get install worked like a charm, no need to tweek anything, I got the sound working right away. The method proposed by TedbOt recently doesn't seem to be necessary anymore. I'll try pd=extended sometime soon.
Hey, did you get audio via the audio connector or via HDMI? I compiled pd-extended from a daily snapshot on Raspbian and it works nicely via HDMI but the audio from the dedicated socket has glitches. Performance is so-so, a modified bpq2 example works nicely (added noise and a LFO to modulate the filter's frequency), but freeverb for instance nailed the cpu at 100% and left only smallest chunks of sound for the ear. GEM only works with an external xserver (like the X11 I have on my Mac) since RPi doesn't come with GLX. I could upload my package (where?) if you want, BTW - compile takes some hours and clogs the entire machine. Michael.
-- 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
-
Charles Goyard -
Jeppi Jeppi -
Martin Peach -
Michael Zacherl -
Miller Puckette -
Pierre Massat -
Richie Cyngler -
Scott R. Looney -
Stephen Lucas -
Tedb0t -
Thomas Grill