Does it work with external sound cards nicely now? That’s great if so.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Feb 3, 2015, at 6:38 AM, pd-list-request@lists.iem.at wrote:
From: Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> Cc: "pd-list@lists.iem.at mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto:pd-list@lists.iem.at>, lhanneuse puredata <lhanneusepuredata@gmail.com mailto:lhanneusepuredata@gmail.com> To: Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> Date: February 3, 2015 at 6:37:51 AM GMT+1 Subject: Re: [PD] Raspberry pi 2
Oops - as Max Neupert pointed out to me, the thing I have is the Pi B+, not the Pi 2.
The Pi B+ fixed the USB 2.0 speed problem with audio. From what I gather the Pi 2 will inherit that fix.
cheers Miller
Well, the Pi B+ works fine with the USB audio devices I've tried on it, except that I'm suspicious that there is new electrical interference (ground trouble perhaps) that I hadn't heard in the earlier Pi B. But I haven't verified that carefully.
In an ideal world someone would build us an I2S expansion board for Pi with 8CH audio in and out, memory mapped straight to user space. Maybe someday someone will build that :)
Miller
On Tue, Feb 03, 2015 at 07:20:17PM +0100, Dan Wilcox wrote:
Does it work with external sound cards nicely now? That’s great if so.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Feb 3, 2015, at 6:38 AM, pd-list-request@lists.iem.at wrote:
From: Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> Cc: "pd-list@lists.iem.at mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto:pd-list@lists.iem.at>, lhanneuse puredata <lhanneusepuredata@gmail.com mailto:lhanneusepuredata@gmail.com> To: Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> Date: February 3, 2015 at 6:37:51 AM GMT+1 Subject: Re: [PD] Raspberry pi 2
Oops - as Max Neupert pointed out to me, the thing I have is the Pi B+, not the Pi 2.
The Pi B+ fixed the USB 2.0 speed problem with audio. From what I gather the Pi 2 will inherit that fix.
cheers Miller
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I’m curious now. I’ll have to pick one up / borrow one and see if it works with my UA-25.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Feb 3, 2015, at 7:30 PM, Miller Puckette msp@ucsd.edu wrote:
Well, the Pi B+ works fine with the USB audio devices I've tried on it, except that I'm suspicious that there is new electrical interference (ground trouble perhaps) that I hadn't heard in the earlier Pi B. But I haven't verified that carefully.
In an ideal world someone would build us an I2S expansion board for Pi with 8CH audio in and out, memory mapped straight to user space. Maybe someday someone will build that :)
Miller
On Tue, Feb 03, 2015 at 07:20:17PM +0100, Dan Wilcox wrote:
Does it work with external sound cards nicely now? That’s great if so.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Feb 3, 2015, at 6:38 AM, pd-list-request@lists.iem.at wrote:
From: Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> Cc: "pd-list@lists.iem.at mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto:pd-list@lists.iem.at>, lhanneuse puredata <lhanneusepuredata@gmail.com mailto:lhanneusepuredata@gmail.com> To: Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> Date: February 3, 2015 at 6:37:51 AM GMT+1 Subject: Re: [PD] Raspberry pi 2
Oops - as Max Neupert pointed out to me, the thing I have is the Pi B+, not the Pi 2.
The Pi B+ fixed the USB 2.0 speed problem with audio. From what I gather the Pi 2 will inherit that fix.
cheers Miller
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I'm personally curious about how this new Raspberry Pi 2 model compares to the also pretty new Odroid C1, which is the same price, but seems to have a slightly faster processor (1.5Ghz quad-core). Has anybody tried one of those?
On Tue, Feb 3, 2015 at 1:35 PM, Dan Wilcox danomatika@gmail.com wrote:
I’m curious now. I’ll have to pick one up / borrow one and see if it works with my UA-25.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Feb 3, 2015, at 7:30 PM, Miller Puckette msp@ucsd.edu wrote:
Well, the Pi B+ works fine with the USB audio devices I've tried on it, except that I'm suspicious that there is new electrical interference (ground trouble perhaps) that I hadn't heard in the earlier Pi B. But I haven't verified that carefully.
In an ideal world someone would build us an I2S expansion board for Pi with 8CH audio in and out, memory mapped straight to user space. Maybe someday someone will build that :)
Miller
On Tue, Feb 03, 2015 at 07:20:17PM +0100, Dan Wilcox wrote:
Does it work with external sound cards nicely now? That’s great if so.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Feb 3, 2015, at 6:38 AM, pd-list-request@lists.iem.at wrote:
From: Miller Puckette <msp@ucsd.edu <mailto:msp@ucsd.edu msp@ucsd.edu>> Cc: "pd-list@lists.iem.at <mailto:pd-list@lists.iem.at pd-list@lists.iem.at>" <pd-list@lists.iem.at < mailto:pd-list@lists.iem.at pd-list@lists.iem.at>>, lhanneuse puredata < lhanneusepuredata@gmail.com <mailto:lhanneusepuredata@gmail.com lhanneusepuredata@gmail.com>> To: Alexandre Torres Porres <porres@gmail.com <mailto:porres@gmail.com porres@gmail.com>> Date: February 3, 2015 at 6:37:51 AM GMT+1 Subject: Re: [PD] Raspberry pi 2
Oops - as Max Neupert pointed out to me, the thing I have is the Pi B+, not the Pi 2.
The Pi B+ fixed the USB 2.0 speed problem with audio. From what I gather the Pi 2 will inherit that fix.
cheers Miller
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Yeah, me too. I went to UDOO since I needed reliable audio quickly but it wasn’t cheap. Then again, things have changed alot since I first started compiling custom Linux kernels for wearable computers that cost $10k new (and $300 used on ebay). Great to be complaining about spending $130 versus $35 on embedded computers to run PD now! :D
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Feb 3, 2015, at 7:47 PM, Brian Fay ovaltinevortex@gmail.com wrote:
I'm personally curious about how this new Raspberry Pi 2 model compares to the also pretty new Odroid C1, which is the same price, but seems to have a slightly faster processor (1.5Ghz quad-core). Has anybody tried one of those?
On Tue, Feb 3, 2015 at 1:35 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: I’m curious now. I’ll have to pick one up / borrow one and see if it works with my UA-25.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Feb 3, 2015, at 7:30 PM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
Well, the Pi B+ works fine with the USB audio devices I've tried on it, except that I'm suspicious that there is new electrical interference (ground trouble perhaps) that I hadn't heard in the earlier Pi B. But I haven't verified that carefully.
In an ideal world someone would build us an I2S expansion board for Pi with 8CH audio in and out, memory mapped straight to user space. Maybe someday someone will build that :)
Miller
On Tue, Feb 03, 2015 at 07:20:17PM +0100, Dan Wilcox wrote:
Does it work with external sound cards nicely now? That’s great if so.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ <http://danomatika.com/ http://danomatika.com/> robotcowboy.com http://robotcowboy.com/ <http://robotcowboy.com/ http://robotcowboy.com/>
On Feb 3, 2015, at 6:38 AM, pd-list-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
From: Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu <mailto:msp@ucsd.edu mailto:msp@ucsd.edu>> Cc: "pd-list@lists.iem.at mailto:pd-list@lists.iem.at <mailto:pd-list@lists.iem.at mailto:pd-list@lists.iem.at>" <pd-list@lists.iem.at mailto:pd-list@lists.iem.at <mailto:pd-list@lists.iem.at mailto:pd-list@lists.iem.at>>, lhanneuse puredata <lhanneusepuredata@gmail.com mailto:lhanneusepuredata@gmail.com <mailto:lhanneusepuredata@gmail.com mailto:lhanneusepuredata@gmail.com>> To: Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com <mailto:porres@gmail.com mailto:porres@gmail.com>> Date: February 3, 2015 at 6:37:51 AM GMT+1 Subject: Re: [PD] Raspberry pi 2
Oops - as Max Neupert pointed out to me, the thing I have is the Pi B+, not the Pi 2.
The Pi B+ fixed the USB 2.0 speed problem with audio. From what I gather the Pi 2 will inherit that fix.
cheers Miller
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
On 3 Φεβ 2015, at 20:47, Brian Fay ovaltinevortex@gmail.com wrote:
I'm personally curious about how this new Raspberry Pi 2 model compares to the also pretty new Odroid C1, which is the same price, but seems to have a slightly faster processor (1.5Ghz quad-core). Has anybody tried one of those?
I'm currently working with an Odroid-U3 and a Focusrite Scarlett 2i4 with Jack, and it seems to be running fine. Everything is still under development, so there are some small surprises every now and then, but nothing worrying..
On 04/02/15 05:30, Miller Puckette wrote:
In an ideal world someone would build us an I2S expansion board for Pi with 8CH audio in and out, memory mapped straight to user space. Maybe someday someone will build that :)
the wolfson cards have some of that, and quite a bit of control internally, with lots of sync possibilities and so forth, even programmable dsp routines if you really want! The drivers supplied are for alsa and work fine with pd, and expose their internal mixing options etc in the alsa interface ... but the Pis don't expose the 8ch I2S on their pins, only 2ch ones, so though the wolfson card can take 8ch in the pi can't deliver it ... I guess the 8ch I2S interface is going to the hdmi circuitry.
The B version uses almost every available pin, including the extras in p5, but the B+ version doesn't need all the new ones.
I can put an image up on dropbox of a system for the B version with the modules, scripts etc working nicely, and an RT kernel, if that is useful, that has been well tested. The images on the wolfson site were not working for me, but I found a version that worked. I haven't got a B+ wolfson card so can't verify them.
One issue for me is that I'd like to play the audio from AV files through them, but the players I am using send audio directly out, and I am not able to send it to userspace, alsa and pd ... so can't use the wolfson audio in those cases.
It should be possible, for example, to daisy-chain several pis with wolfson cards via the wolfson SPDIF I/O ... then the clock source can be all from the first wolfson, and the SPDIF chain ending up with a digital stereo mix output from the last wolfson, all the mixing and clocking options are available via alsa. Testing that is next on my list.
Simon
Simon, have you compared the wolfson to any USB interfaces? I'm curious about how it performs by comparison, using no more than 2 input and 2 output channels. I had some success with a USB interface on a Pi using pd and alsa, and got down to somewhere around 15 milliseconds of latency.
I couldn't avoid occasional pops and clicks, and if I really pushed the number of effects I was using at once I would get some serious xruns. With the wolfson bypassing USB altogether, is it easier to achieve a low latency?
And since you mentioned an RT kernel, I'm curious - did you patch it yourself, or is there already an image available? Is it stable, or does it randomly freeze?
-Brian
On Wed, Feb 4, 2015 at 9:43 AM, Simon Wise simonzwise@gmail.com wrote:
On 04/02/15 05:30, Miller Puckette wrote:
In an ideal world someone would build us an I2S expansion board for Pi
with 8CH audio in and out, memory mapped straight to user space. Maybe someday someone will build that :)
the wolfson cards have some of that, and quite a bit of control internally, with lots of sync possibilities and so forth, even programmable dsp routines if you really want! The drivers supplied are for alsa and work fine with pd, and expose their internal mixing options etc in the alsa interface ... but the Pis don't expose the 8ch I2S on their pins, only 2ch ones, so though the wolfson card can take 8ch in the pi can't deliver it ... I guess the 8ch I2S interface is going to the hdmi circuitry.
The B version uses almost every available pin, including the extras in p5, but the B+ version doesn't need all the new ones.
I can put an image up on dropbox of a system for the B version with the modules, scripts etc working nicely, and an RT kernel, if that is useful, that has been well tested. The images on the wolfson site were not working for me, but I found a version that worked. I haven't got a B+ wolfson card so can't verify them.
One issue for me is that I'd like to play the audio from AV files through them, but the players I am using send audio directly out, and I am not able to send it to userspace, alsa and pd ... so can't use the wolfson audio in those cases.
It should be possible, for example, to daisy-chain several pis with wolfson cards via the wolfson SPDIF I/O ... then the clock source can be all from the first wolfson, and the SPDIF chain ending up with a digital stereo mix output from the last wolfson, all the mixing and clocking options are available via alsa. Testing that is next on my list.
Simon
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
On 05/02/15 02:34, Brian Fay wrote:
Simon, have you compared the wolfson to any USB interfaces? I'm curious about how it performs by comparison, using no more than 2 input and 2 output channels. I had some success with a USB interface on a Pi using pd and alsa, and got down to somewhere around 15 milliseconds of latency.
I couldn't avoid occasional pops and clicks, and if I really pushed the number of effects I was using at once I would get some serious xruns. With the wolfson bypassing USB altogether, is it easier to achieve a low latency?
I have found that you really need to minimise everything to get the Pis running smoothly, certainly no X and only what is strictly needed for control .. they are not powerful devices but the access you have to GPIOs and such, and the ability to program things at a low level means they can be made to do some tasks well, and fast. The usb is to be avoided if at all possible, I'd like to test the A model (with the single USB-OTG directly from the chip) it might be better than going via that usb/ethernet chip, the A+ looks really compact as well.
I didn't need low latency, I got the wolfsons hoping for better quality analogue I/O, their digital I/O options, the possibility of linking them clock-wise and to avoid the endless usb hassles (there are other things I need the USB for!) ... they work well for this and I will do some serious testing but the audio has been clean and sounding good so far ... and I have learnt quite a lot about the various low level interface options.
And since you mentioned an RT kernel, I'm curious - did you patch it yourself, or is there already an image available? Is it stable, or does it randomly freeze?
I didn't patch it myself, I have been using it in a dozen machines which now run consistently ... I have been chasing some issue that was causing them to crash after a while, replacing a pile of bash scripts and multiple calls to some little dbus CL programs with the same thing directly from C in a pd external has fixed the issue .. on the non-RT B+ system as well, so it probably was not kernel related.
here are some notes I've made ... including instructions and links to the kernel and files, and sources ... all on my dropbox, and the original link I used. They are running notes from a project, so there is a bit of extraneous info but download and install instructions are in there:
https://www.dropbox.com/s/1scwpdufk41k4es/04.setupWolfsonAudio.txt
Simon
Thanks for the info, my experience with USB was pretty similar - had to run Pd in headless mode (no X), and definitely needed to do a lot of tweaking before things were satisfying.
The Wolfson sounds like it could be a little bit of work to get running, but I'm glad to hear that the quality is good. I'll keep an eye on it and see if they do anything to support the new model of the Pi.
On Wed, Feb 4, 2015 at 11:58 AM, Simon Wise simonzwise@gmail.com wrote:
On 05/02/15 02:34, Brian Fay wrote:
Simon, have you compared the wolfson to any USB interfaces? I'm curious about how it performs by comparison, using no more than 2 input and 2 output channels. I had some success with a USB interface on a Pi using pd and alsa, and got down to somewhere around 15 milliseconds of latency.
I couldn't avoid occasional pops and clicks, and if I really pushed the number of effects I was using at once I would get some serious xruns. With the wolfson bypassing USB altogether, is it easier to achieve a low latency?
I have found that you really need to minimise everything to get the Pis running smoothly, certainly no X and only what is strictly needed for control .. they are not powerful devices but the access you have to GPIOs and such, and the ability to program things at a low level means they can be made to do some tasks well, and fast. The usb is to be avoided if at all possible, I'd like to test the A model (with the single USB-OTG directly from the chip) it might be better than going via that usb/ethernet chip, the A+ looks really compact as well.
I didn't need low latency, I got the wolfsons hoping for better quality analogue I/O, their digital I/O options, the possibility of linking them clock-wise and to avoid the endless usb hassles (there are other things I need the USB for!) ... they work well for this and I will do some serious testing but the audio has been clean and sounding good so far ... and I have learnt quite a lot about the various low level interface options.
And since you mentioned an RT kernel, I'm curious - did you patch it yourself, or is there already an image available? Is it stable, or does it randomly freeze?
I didn't patch it myself, I have been using it in a dozen machines which now run consistently ... I have been chasing some issue that was causing them to crash after a while, replacing a pile of bash scripts and multiple calls to some little dbus CL programs with the same thing directly from C in a pd external has fixed the issue .. on the non-RT B+ system as well, so it probably was not kernel related.
here are some notes I've made ... including instructions and links to the kernel and files, and sources ... all on my dropbox, and the original link I used. They are running notes from a project, so there is a bit of extraneous info but download and install instructions are in there:
https://www.dropbox.com/s/1scwpdufk41k4es/04.setupWolfsonAudio.txt
Simon
On 05/02/15 10:01, Brian Fay wrote:
Thanks for the info, my experience with USB was pretty similar - had to run Pd in headless mode (no X), and definitely needed to do a lot of tweaking before things were satisfying.
The Wolfson sounds like it could be a little bit of work to get running, but I'm glad to hear that the quality is good. I'll keep an eye on it and see if they do anything to support the new model of the Pi.
a new wolfson card, to fit the B+ and A+ models is available so they are certainly actively developing. I have not checked the driver situation, but they originally aimed to support it in raspbian and I imagine both the wolfson card lot and the raspberry lot have been rather focussed on the new models ... so I hope there will be progress there. The binaries I posted work fine in the B model with the raspbian with: Linux 3.10.29+ #636 PREEMPT Sun Feb 9 19:58:58 GMT 2014 armv6l
that wolson/RT kernel is: Linux rpi-1 3.12.13-rt21+ #1 PREEMPT RT Thu Mar 27 16:58:09 CET 2014 armv6l
If you are looking for something more powerful than the Pi then the Udoo is well worth considering, power to price ratio is very much in Udoo's favour, but the Pi is certainly cheaper and physically smaller ... especially the A+ ..
- the arduino chip on the Udoo gives much wider possibilities re I/O especially
if you are concerned with very low latency and jitter on those channels, I/O can go between chips or to either so you have lots of access to both chips.
- the quad-core Udoo processor would allow for a dedicated audio core if you
wanted, by reserving one of the cores for the main Pd process
the Udoo is much more open, there are much more detailed specs esp re the GPU
the Udoo is based on the same chip series widely used in the faster tablets,
they have debian and android images, and others
(I haven't checked out the newest Pi at all yet, it apparently has a very much more powerful processor so is quite a different beast)
Simon
On 05/02/15 12:51, Simon Wise wrote:
(I haven't checked out the newest Pi at all yet, it apparently has a very much more powerful processor so is quite a different beast)
Ok ... so it is a very similar chip with Quad-core ARMv7 replacing the single core ARMv6, with the rest of the chip apparently left unchanged ... so same USB and same graphics, more CPU for audio and a desktop, still less than half the price of an Udoo.
Not much docs up yet at all, but there are images for a few systems ... kind of typical.
And the move to ARMv7 takes it closer to current hardware, so for example there isn't the same need to build raspbian as a half-way house between 2 debian builds ... for now they say they are keeping the same user-space in both raspbian builds and seem to have compatibility high on their agenda.
Has anyone here actually got one yet?
Simon
Hello,
I got that new Raspberry Pi model 2b. It is indeed much faster than b or b+ in practice, but alarmingly, I can't get useful sound from Pd. Continuous dropouts, no matter if built-in output or USB sound card (iMic) is used. I've built puredata 0.46-2 from Raspbian jessie source, for sure it has real time prio (can verify when starting Pd with option -verbose). No clue what is going on here, so far.
Katja
On Thu, Feb 5, 2015 at 3:54 AM, Simon Wise simonzwise@gmail.com wrote:
On 05/02/15 12:51, Simon Wise wrote:
(I haven't checked out the newest Pi at all yet, it apparently has a very much more powerful processor so is quite a different beast)
Ok ... so it is a very similar chip with Quad-core ARMv7 replacing the single core ARMv6, with the rest of the chip apparently left unchanged ... so same USB and same graphics, more CPU for audio and a desktop, still less than half the price of an Udoo.
Not much docs up yet at all, but there are images for a few systems ... kind of typical.
And the move to ARMv7 takes it closer to current hardware, so for example there isn't the same need to build raspbian as a half-way house between 2 debian builds ... for now they say they are keeping the same user-space in both raspbian builds and seem to have compatibility high on their agenda.
Has anyone here actually got one yet?
Simon
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Wow, that's unexpected! :(
Are other audio-related things working fine?
-Brian
On Fri, Feb 6, 2015 at 3:40 PM, katja katjavetter@gmail.com wrote:
Hello,
I got that new Raspberry Pi model 2b. It is indeed much faster than b or b+ in practice, but alarmingly, I can't get useful sound from Pd. Continuous dropouts, no matter if built-in output or USB sound card (iMic) is used. I've built puredata 0.46-2 from Raspbian jessie source, for sure it has real time prio (can verify when starting Pd with option -verbose). No clue what is going on here, so far.
Katja
On Thu, Feb 5, 2015 at 3:54 AM, Simon Wise simonzwise@gmail.com wrote:
On 05/02/15 12:51, Simon Wise wrote:
(I haven't checked out the newest Pi at all yet, it apparently has a
very
much more powerful processor so is quite a different beast)
Ok ... so it is a very similar chip with Quad-core ARMv7 replacing the single core ARMv6, with the rest of the chip apparently left unchanged
...
so same USB and same graphics, more CPU for audio and a desktop, still
less
than half the price of an Udoo.
Not much docs up yet at all, but there are images for a few systems ...
kind
of typical.
And the move to ARMv7 takes it closer to current hardware, so for example there isn't the same need to build raspbian as a half-way house between 2 debian builds ... for now they say they are keeping the same user-space
in
both raspbian builds and seem to have compatibility high on their agenda.
Has anyone here actually got one yet?
Simon
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Aplay can play a .wav file without trouble, so it is not a general problem with the audio hardware or drivers on Pi 2b.
I installed command htop to see CPU load per core. It's interesting, the load switches from one core to another, and sometimes they all seem to be almost idle even with a heavy Pd patch running.
Katja
On Fri, Feb 6, 2015 at 9:46 PM, Brian Fay ovaltinevortex@gmail.com wrote:
Wow, that's unexpected! :(
Are other audio-related things working fine?
-Brian
On Fri, Feb 6, 2015 at 3:40 PM, katja katjavetter@gmail.com wrote:
Hello,
I got that new Raspberry Pi model 2b. It is indeed much faster than b or b+ in practice, but alarmingly, I can't get useful sound from Pd. Continuous dropouts, no matter if built-in output or USB sound card (iMic) is used. I've built puredata 0.46-2 from Raspbian jessie source, for sure it has real time prio (can verify when starting Pd with option -verbose). No clue what is going on here, so far.
Katja
On Thu, Feb 5, 2015 at 3:54 AM, Simon Wise simonzwise@gmail.com wrote:
On 05/02/15 12:51, Simon Wise wrote:
(I haven't checked out the newest Pi at all yet, it apparently has a very much more powerful processor so is quite a different beast)
Ok ... so it is a very similar chip with Quad-core ARMv7 replacing the single core ARMv6, with the rest of the chip apparently left unchanged ... so same USB and same graphics, more CPU for audio and a desktop, still less than half the price of an Udoo.
Not much docs up yet at all, but there are images for a few systems ... kind of typical.
And the move to ARMv7 takes it closer to current hardware, so for example there isn't the same need to build raspbian as a half-way house between 2 debian builds ... for now they say they are keeping the same user-space in both raspbian builds and seem to have compatibility high on their agenda.
Has anyone here actually got one yet?
Simon
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I've not got any version of the rpi, but maybe it's scaling down the clock frequency of unused cores, which then takes some time to spin up to full speed when a task is moved by the kernel?
I also had issues on amd64 desktop and core2duo laptop with pd -rt not being taken into account by the kernel ondemand cpu speed governor, or some other issue perhaps, whereby the cpu speed would stay at ~800MHz even though it really needed to be higher to reduce xruns etc.. pd -nrt would scale up the cpu speed correctly.
On my quad-core amd64 desktop I run this before realtime work (or nrt benchmarking) to set all cores to maximum speed (with the 'performance' governor):
for c in 0 1 2 3 ; do sudo cpufreq-set -c $c -g performance ; done
Then when I want to reduce fan noise / heat etc and I'm not doing much intensive, I reset to the default 'ondemand' governor:
for c in 0 1 2 3 ; do sudo cpufreq-set -c $c -g ondemand ; done
Might also be worth looking into setting scheduler cpu core affinity for pd, jackd, pd-gui, ... but I don't know how to do that.
Claude
On 06/02/15 21:38, katja wrote:
Aplay can play a .wav file without trouble, so it is not a general problem with the audio hardware or drivers on Pi 2b.
I installed command htop to see CPU load per core. It's interesting, the load switches from one core to another, and sometimes they all seem to be almost idle even with a heavy Pd patch running.
Claude, thanks for the hint. My /boot/config.txt shows no special settings, so I guess the CPU is at a fixed frequency. It says that '700 MHz is the default' (while model 2B should be at 900 MHz). Seems I downloaded the 'newest' Raspbian too early (the day after model 2B's release)... Will try again.
Katja
On Fri, Feb 6, 2015 at 10:50 PM, Claude Heiland-Allen claude@mathr.co.uk wrote:
I've not got any version of the rpi, but maybe it's scaling down the clock frequency of unused cores, which then takes some time to spin up to full speed when a task is moved by the kernel?
I also had issues on amd64 desktop and core2duo laptop with pd -rt not being taken into account by the kernel ondemand cpu speed governor, or some other issue perhaps, whereby the cpu speed would stay at ~800MHz even though it really needed to be higher to reduce xruns etc.. pd -nrt would scale up the cpu speed correctly.
On my quad-core amd64 desktop I run this before realtime work (or nrt benchmarking) to set all cores to maximum speed (with the 'performance' governor):
for c in 0 1 2 3 ; do sudo cpufreq-set -c $c -g performance ; done
Then when I want to reduce fan noise / heat etc and I'm not doing much intensive, I reset to the default 'ondemand' governor:
for c in 0 1 2 3 ; do sudo cpufreq-set -c $c -g ondemand ; done
Might also be worth looking into setting scheduler cpu core affinity for pd, jackd, pd-gui, ... but I don't know how to do that.
Claude
On 06/02/15 21:38, katja wrote:
Aplay can play a .wav file without trouble, so it is not a general problem with the audio hardware or drivers on Pi 2b.
I installed command htop to see CPU load per core. It's interesting, the load switches from one core to another, and sometimes they all seem to be almost idle even with a heavy Pd patch running.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Also try running "pd -nosleep", which sometimes persuades kernels to schedule the process differently :)
M
On Fri, Feb 06, 2015 at 11:30:03PM +0100, katja wrote:
Claude, thanks for the hint. My /boot/config.txt shows no special settings, so I guess the CPU is at a fixed frequency. It says that '700 MHz is the default' (while model 2B should be at 900 MHz). Seems I downloaded the 'newest' Raspbian too early (the day after model 2B's release)... Will try again.
Katja
On Fri, Feb 6, 2015 at 10:50 PM, Claude Heiland-Allen claude@mathr.co.uk wrote:
I've not got any version of the rpi, but maybe it's scaling down the clock frequency of unused cores, which then takes some time to spin up to full speed when a task is moved by the kernel?
I also had issues on amd64 desktop and core2duo laptop with pd -rt not being taken into account by the kernel ondemand cpu speed governor, or some other issue perhaps, whereby the cpu speed would stay at ~800MHz even though it really needed to be higher to reduce xruns etc.. pd -nrt would scale up the cpu speed correctly.
On my quad-core amd64 desktop I run this before realtime work (or nrt benchmarking) to set all cores to maximum speed (with the 'performance' governor):
for c in 0 1 2 3 ; do sudo cpufreq-set -c $c -g performance ; done
Then when I want to reduce fan noise / heat etc and I'm not doing much intensive, I reset to the default 'ondemand' governor:
for c in 0 1 2 3 ; do sudo cpufreq-set -c $c -g ondemand ; done
Might also be worth looking into setting scheduler cpu core affinity for pd, jackd, pd-gui, ... but I don't know how to do that.
Claude
On 06/02/15 21:38, katja wrote:
Aplay can play a .wav file without trouble, so it is not a general problem with the audio hardware or drivers on Pi 2b.
I installed command htop to see CPU load per core. It's interesting, the load switches from one core to another, and sometimes they all seem to be almost idle even with a heavy Pd patch running.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, Feb 6, 2015 at 11:56 PM, Miller Puckette msp@ucsd.edu wrote:
Also try running "pd -nosleep", which sometimes persuades kernels to schedule the process differently :)
Indeed, "pd -nosleep" does the magic. Command htop shows hat the kernel has 100% CPU time reserved on one core (fixed per session) for pd -nosleep. Pd-gui runs on one of the other cores, alternating. The audio is fine with no dropouts.
It is possible to start two instances of pd -nosleep, and get a core reserved for each. The second instance finds the alsa device busy of course, and this makes no sense in practice. Maybe the [pd~] object can profit from the multicore processor.
I've checked current draw with the setup: Raspberry Pi + USB keyboard
- USB mouse + USB audio interface (iMic) together consume ~400 mA with
only the desktop running, and ~450 mA with pd -nosleep running idle or with a CPU intensive patch. This indicates there is some frequency scaling going on after all. I'll look into that again when there's more info about the new Pi's config defaults and options.
Katja
Dear Katja,
Could you please tell us what buffer size you're using in Pd ? Can you get lower than 16 ms without dropouts with a reasonable patch with both adc and dac ?
Thanks in advance,
Pierre.
2015-02-07 10:39 GMT+01:00 katja katjavetter@gmail.com:
On Fri, Feb 6, 2015 at 11:56 PM, Miller Puckette msp@ucsd.edu wrote:
Also try running "pd -nosleep", which sometimes persuades kernels to schedule the process differently :)
Indeed, "pd -nosleep" does the magic. Command htop shows hat the kernel has 100% CPU time reserved on one core (fixed per session) for pd -nosleep. Pd-gui runs on one of the other cores, alternating. The audio is fine with no dropouts.
It is possible to start two instances of pd -nosleep, and get a core reserved for each. The second instance finds the alsa device busy of course, and this makes no sense in practice. Maybe the [pd~] object can profit from the multicore processor.
I've checked current draw with the setup: Raspberry Pi + USB keyboard
- USB mouse + USB audio interface (iMic) together consume ~400 mA with
only the desktop running, and ~450 mA with pd -nosleep running idle or with a CPU intensive patch. This indicates there is some frequency scaling going on after all. I'll look into that again when there's more info about the new Pi's config defaults and options.
Katja
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
10 ms buffer in audio settings was tested OK for this setup:
Raspberry Pi model 2B Raspbian wheezy, latest image from raspberrypi.org LXDE desktop running iMic USB audio interface, 2 in 2 out puredata 0.46-2 built from Raspbian jessie source on RPi model 2B pd started with option -nosleep, and running 'PicoJockey'
PicoJockey is a live sampling tool with effects. I've been using it as a Raspberry Pi test since the first 256 MB model B, for which it was too difficult, considering the USB troubles at the time. PicoJockey can be found here compiled on single core Raspi but the build works for model 2B too: http://www.katjaas.nl/slicejockey/slicejockey.html (page bottom). On model B+ I used to run PicoJockey at half the default sample rate to save CPU time, but with model 2B it can run at default sample rate while leaving some CPU headroom. PicoJockey's GUI controls are pretty CPU intensive but that's where the extra cores are useful.
Results are quite promising and there may be options for optimization, like compiling Pd with NEON instructions enabled (if gcc can do that).
Katja
On Sat, Feb 7, 2015 at 1:45 PM, Pierre Massat pimassat@gmail.com wrote:
Dear Katja,
Could you please tell us what buffer size you're using in Pd ? Can you get lower than 16 ms without dropouts with a reasonable patch with both adc and dac ?
Thanks in advance,
Pierre.
2015-02-07 10:39 GMT+01:00 katja katjavetter@gmail.com:
On Fri, Feb 6, 2015 at 11:56 PM, Miller Puckette msp@ucsd.edu wrote:
Also try running "pd -nosleep", which sometimes persuades kernels to schedule the process differently :)
Indeed, "pd -nosleep" does the magic. Command htop shows hat the kernel has 100% CPU time reserved on one core (fixed per session) for pd -nosleep. Pd-gui runs on one of the other cores, alternating. The audio is fine with no dropouts.
It is possible to start two instances of pd -nosleep, and get a core reserved for each. The second instance finds the alsa device busy of course, and this makes no sense in practice. Maybe the [pd~] object can profit from the multicore processor.
I've checked current draw with the setup: Raspberry Pi + USB keyboard
- USB mouse + USB audio interface (iMic) together consume ~400 mA with
only the desktop running, and ~450 mA with pd -nosleep running idle or with a CPU intensive patch. This indicates there is some frequency scaling going on after all. I'll look into that again when there's more info about the new Pi's config defaults and options.
Katja
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Wow. This is getting interesting again ! Thank you Katja for purchasing and testing the new version so quickly.
Pierre.
2015-02-07 15:22 GMT+01:00 katja katjavetter@gmail.com:
10 ms buffer in audio settings was tested OK for this setup:
Raspberry Pi model 2B Raspbian wheezy, latest image from raspberrypi.org LXDE desktop running iMic USB audio interface, 2 in 2 out puredata 0.46-2 built from Raspbian jessie source on RPi model 2B pd started with option -nosleep, and running 'PicoJockey'
PicoJockey is a live sampling tool with effects. I've been using it as a Raspberry Pi test since the first 256 MB model B, for which it was too difficult, considering the USB troubles at the time. PicoJockey can be found here compiled on single core Raspi but the build works for model 2B too: http://www.katjaas.nl/slicejockey/slicejockey.html (page bottom). On model B+ I used to run PicoJockey at half the default sample rate to save CPU time, but with model 2B it can run at default sample rate while leaving some CPU headroom. PicoJockey's GUI controls are pretty CPU intensive but that's where the extra cores are useful.
Results are quite promising and there may be options for optimization, like compiling Pd with NEON instructions enabled (if gcc can do that).
Katja
On Sat, Feb 7, 2015 at 1:45 PM, Pierre Massat pimassat@gmail.com wrote:
Dear Katja,
Could you please tell us what buffer size you're using in Pd ? Can you
get
lower than 16 ms without dropouts with a reasonable patch with both adc
and
dac ?
Thanks in advance,
Pierre.
2015-02-07 10:39 GMT+01:00 katja katjavetter@gmail.com:
On Fri, Feb 6, 2015 at 11:56 PM, Miller Puckette msp@ucsd.edu wrote:
Also try running "pd -nosleep", which sometimes persuades kernels to schedule the process differently :)
Indeed, "pd -nosleep" does the magic. Command htop shows hat the kernel has 100% CPU time reserved on one core (fixed per session) for pd -nosleep. Pd-gui runs on one of the other cores, alternating. The audio is fine with no dropouts.
It is possible to start two instances of pd -nosleep, and get a core reserved for each. The second instance finds the alsa device busy of course, and this makes no sense in practice. Maybe the [pd~] object can profit from the multicore processor.
I've checked current draw with the setup: Raspberry Pi + USB keyboard
- USB mouse + USB audio interface (iMic) together consume ~400 mA with
only the desktop running, and ~450 mA with pd -nosleep running idle or with a CPU intensive patch. This indicates there is some frequency scaling going on after all. I'll look into that again when there's more info about the new Pi's config defaults and options.
Katja
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
As an alternative to "pd -nosleep", "taskset 0x00000001 pd" (as per Simon Wise's suggestion) is another way to run puredata properly on Raspberry Pi model 2B. This sets 'CPU affinity' for pd to core 1 (you could set another core in hex format). Apparently the switching between cores is detrimental to pd's dsp process. Core affinity is a side effect of pd's -nosleep option, that is probably why both approaches work. The advantage of the taskset approach is that command top or htop still show realistic CPU load for the process (with "pd -nosleep" it shows as 100% all the time).
Here is a way to make pd start in taskset consistently in LXDE: 1 - create a new textfile ~/.local/share/applications/puredata.desktop 2 - copy the text from /usr/share/applications/puredata.desktop into this new file 3 - replace the string after "Exec=" with "taskset 0x00000001 pd %F" 4- logout and login for the new setting to take effect
Now you can start pd with 'CPU affinity' from the menu or by double clicking a patch. Not sure if this is the definitive solution, but at least it makes pd work without audio errors.
Katja
On Sat, Feb 7, 2015 at 10:39 AM, katja katjavetter@gmail.com wrote:
On Fri, Feb 6, 2015 at 11:56 PM, Miller Puckette msp@ucsd.edu wrote:
Also try running "pd -nosleep", which sometimes persuades kernels to schedule the process differently :)
Indeed, "pd -nosleep" does the magic. Command htop shows hat the kernel has 100% CPU time reserved on one core (fixed per session) for pd -nosleep. Pd-gui runs on one of the other cores, alternating. The audio is fine with no dropouts.
It is possible to start two instances of pd -nosleep, and get a core reserved for each. The second instance finds the alsa device busy of course, and this makes no sense in practice. Maybe the [pd~] object can profit from the multicore processor.
I've checked current draw with the setup: Raspberry Pi + USB keyboard
- USB mouse + USB audio interface (iMic) together consume ~400 mA with
only the desktop running, and ~450 mA with pd -nosleep running idle or with a CPU intensive patch. This indicates there is some frequency scaling going on after all. I'll look into that again when there's more info about the new Pi's config defaults and options.
Katja
On 08/02/15 02:52, katja wrote:
As an alternative to "pd -nosleep", "taskset 0x00000001 pd" (as per Simon Wise's suggestion) is another way to run puredata properly on Raspberry Pi model 2B. This sets 'CPU affinity' for pd to core 1 (you could set another core in hex format). Apparently the switching between cores is detrimental to pd's dsp process. Core affinity is a side effect of pd's -nosleep option, that is probably why both approaches work. The advantage of the taskset approach is that command top or htop still show realistic CPU load for the process (with "pd -nosleep" it shows as 100% all the time).
the nosleep option is perhaps a little better, if you have the other cores not fully utilised anyway, since it presumably replaces sleeps with busy waiting, so keeps one core busy with the audio process and avoids the slight delay that interrupts might cause, but really those are probably not significant in the time-scale of the audio latencies we are getting anyway.
Taskset certainly confirms that the problem was switching cores, and that is quite possibly a problem with losing the cache after a core switch.
Here is a way to make pd start in taskset consistently in LXDE: 1 - create a new textfile ~/.local/share/applications/puredata.desktop 2 - copy the text from /usr/share/applications/puredata.desktop into this new file 3 - replace the string after "Exec=" with "taskset 0x00000001 pd %F" 4- logout and login for the new setting to take effect
Now you can start pd with 'CPU affinity' from the menu or by double clicking a patch. Not sure if this is the definitive solution, but at least it makes pd work without audio errors.
the problem here would seem to be that ALL the pd processes now use that same core, and only that core ... so the gui processes and main pd processes will all be running on core 1 only .... want is wanted is that the main pd process uses that core while the gui processes uses the other cores. This launcher would be fine if running -nogui, but otherwise ...
taskset can set the affinity of a running process by its PID, so a script could do that for the audio process (after it was launched)
or an option could be added to pd which would call sched_setaffinity() when DSP is turned on, to set the affinity for the main pd process only.
or a cpuset could be defined and that PID allocated to it, which seems a simple process of defining a particular file in /proc then writing the PID to it, this has the advantage that that core can be reserved exclusively for the pd audio process.
I must investigate this further, as I do have some small multicore machines, and I would also like to be able to keep the audio and interfacing running smoothly and responsively on some bigger machines, while still being able to have plently of visualisation going on which might sometimes get choppy or slow if overloaded but that is isolated from the audio and critical interfacing.
Simon
The ARM multicore CPUs tend to bounce processes between cores to avoid thermal issues (an idle core is a cool core). If you really want to do -nosleep for a long period, think about adding a heatsink to the chip. I have had A9s lock up or shutdown pretty quickly from heat. On the plus side, I have lower latency on ARM than my new Macbook Air or any other desktop I run Pd on...
On Sat, Feb 7, 2015 at 10:52 AM, katja katjavetter@gmail.com wrote:
As an alternative to "pd -nosleep", "taskset 0x00000001 pd" (as per Simon Wise's suggestion) is another way to run puredata properly on Raspberry Pi model 2B. This sets 'CPU affinity' for pd to core 1 (you could set another core in hex format). Apparently the switching between cores is detrimental to pd's dsp process. Core affinity is a side effect of pd's -nosleep option, that is probably why both approaches work. The advantage of the taskset approach is that command top or htop still show realistic CPU load for the process (with "pd -nosleep" it shows as 100% all the time).
Here is a way to make pd start in taskset consistently in LXDE: 1 - create a new textfile ~/.local/share/applications/puredata.desktop 2 - copy the text from /usr/share/applications/puredata.desktop into this new file 3 - replace the string after "Exec=" with "taskset 0x00000001 pd %F" 4- logout and login for the new setting to take effect
Now you can start pd with 'CPU affinity' from the menu or by double clicking a patch. Not sure if this is the definitive solution, but at least it makes pd work without audio errors.
Katja
On Sat, Feb 7, 2015 at 10:39 AM, katja katjavetter@gmail.com wrote:
On Fri, Feb 6, 2015 at 11:56 PM, Miller Puckette msp@ucsd.edu wrote:
Also try running "pd -nosleep", which sometimes persuades kernels to schedule the process differently :)
Indeed, "pd -nosleep" does the magic. Command htop shows hat the kernel has 100% CPU time reserved on one core (fixed per session) for pd -nosleep. Pd-gui runs on one of the other cores, alternating. The audio is fine with no dropouts.
It is possible to start two instances of pd -nosleep, and get a core reserved for each. The second instance finds the alsa device busy of course, and this makes no sense in practice. Maybe the [pd~] object can profit from the multicore processor.
I've checked current draw with the setup: Raspberry Pi + USB keyboard
- USB mouse + USB audio interface (iMic) together consume ~400 mA with
only the desktop running, and ~450 mA with pd -nosleep running idle or with a CPU intensive patch. This indicates there is some frequency scaling going on after all. I'll look into that again when there's more info about the new Pi's config defaults and options.
Katja
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Interesting. Of course, it _should_ be thermally permitted to run all cores at speed - and the Pi folk are taking heat dissipation very seriously in their thinking. So my leaning would be to risk $35 on a week-long stress test using -nosleep. Hmm, time to order a machine...
cheers Miller
On Mon, Feb 09, 2015 at 01:13:40PM -0500, Chris Clepper wrote:
The ARM multicore CPUs tend to bounce processes between cores to avoid thermal issues (an idle core is a cool core). If you really want to do -nosleep for a long period, think about adding a heatsink to the chip. I have had A9s lock up or shutdown pretty quickly from heat. On the plus side, I have lower latency on ARM than my new Macbook Air or any other desktop I run Pd on...
On Sat, Feb 7, 2015 at 10:52 AM, katja katjavetter@gmail.com wrote:
As an alternative to "pd -nosleep", "taskset 0x00000001 pd" (as per Simon Wise's suggestion) is another way to run puredata properly on Raspberry Pi model 2B. This sets 'CPU affinity' for pd to core 1 (you could set another core in hex format). Apparently the switching between cores is detrimental to pd's dsp process. Core affinity is a side effect of pd's -nosleep option, that is probably why both approaches work. The advantage of the taskset approach is that command top or htop still show realistic CPU load for the process (with "pd -nosleep" it shows as 100% all the time).
Here is a way to make pd start in taskset consistently in LXDE: 1 - create a new textfile ~/.local/share/applications/puredata.desktop 2 - copy the text from /usr/share/applications/puredata.desktop into this new file 3 - replace the string after "Exec=" with "taskset 0x00000001 pd %F" 4- logout and login for the new setting to take effect
Now you can start pd with 'CPU affinity' from the menu or by double clicking a patch. Not sure if this is the definitive solution, but at least it makes pd work without audio errors.
Katja
On Sat, Feb 7, 2015 at 10:39 AM, katja katjavetter@gmail.com wrote:
On Fri, Feb 6, 2015 at 11:56 PM, Miller Puckette msp@ucsd.edu wrote:
Also try running "pd -nosleep", which sometimes persuades kernels to schedule the process differently :)
Indeed, "pd -nosleep" does the magic. Command htop shows hat the kernel has 100% CPU time reserved on one core (fixed per session) for pd -nosleep. Pd-gui runs on one of the other cores, alternating. The audio is fine with no dropouts.
It is possible to start two instances of pd -nosleep, and get a core reserved for each. The second instance finds the alsa device busy of course, and this makes no sense in practice. Maybe the [pd~] object can profit from the multicore processor.
I've checked current draw with the setup: Raspberry Pi + USB keyboard
- USB mouse + USB audio interface (iMic) together consume ~400 mA with
only the desktop running, and ~450 mA with pd -nosleep running idle or with a CPU intensive patch. This indicates there is some frequency scaling going on after all. I'll look into that again when there's more info about the new Pi's config defaults and options.
Katja
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
In general, the ARM will do all sorts of things to keep energy usage to the bare minimum: Video decoding runs on dedicated DSP/GPU rather than the main cores, parts of the cores are shutdown, RAM is put to sleep and so on.
Using -nosleep on a root process at elevated could defeat enough of the low power safeguards as that is something an Android phone/tablet would never do. All of those devices have heatsinks just due to space constraints, and Apple ran afoul of customers due to excessive heat on a dual A8 based iPad.
Without any heat treatment on top of the CPU most of the heat flows through the PCB. So in some cases the issue wouldn't be with the ARM but some other part reaching its thermal limit (like a power regulator or RAM that have to be physically close to the CPU). The UDOO board's WiFi chip gets hotter than the ARM heatsink for example. Freescale recommend heat spreaders and sinks for all of their iMX.6 parts although not all of the low eval boards have them.
The Pi 2 doesn't have much thermal cooling on the chip and the RAM is directly UNDER the CPU so the heat from both will largely go into the same place PCB. Maybe there is enough copper in the PCB to dissipate the heat, but the thermal docs I have from Freescale say it's not possible to do for a 5W+ quad A9.
On Mon, Feb 9, 2015 at 1:53 PM, Miller Puckette msp@ucsd.edu wrote:
Interesting. Of course, it _should_ be thermally permitted to run all cores at speed - and the Pi folk are taking heat dissipation very seriously in their thinking. So my leaning would be to risk $35 on a week-long stress test using -nosleep. Hmm, time to order a machine...
cheers Miller
On Mon, Feb 09, 2015 at 01:13:40PM -0500, Chris Clepper wrote:
The ARM multicore CPUs tend to bounce processes between cores to avoid thermal issues (an idle core is a cool core). If you really want to do -nosleep for a long period, think about adding a heatsink to the chip. I have had A9s lock up or shutdown pretty quickly from heat. On the plus side, I have lower latency on ARM than my new Macbook Air or any other desktop I run Pd on...
On Sat, Feb 7, 2015 at 10:52 AM, katja katjavetter@gmail.com wrote:
As an alternative to "pd -nosleep", "taskset 0x00000001 pd" (as per Simon Wise's suggestion) is another way to run puredata properly on Raspberry Pi model 2B. This sets 'CPU affinity' for pd to core 1 (you could set another core in hex format). Apparently the switching between cores is detrimental to pd's dsp process. Core affinity is a side effect of pd's -nosleep option, that is probably why both approaches work. The advantage of the taskset approach is that command top or htop still show realistic CPU load for the process (with "pd -nosleep" it shows as 100% all the time).
Here is a way to make pd start in taskset consistently in LXDE: 1 - create a new textfile ~/.local/share/applications/puredata.desktop 2 - copy the text from /usr/share/applications/puredata.desktop into this new file 3 - replace the string after "Exec=" with "taskset 0x00000001 pd %F" 4- logout and login for the new setting to take effect
Now you can start pd with 'CPU affinity' from the menu or by double clicking a patch. Not sure if this is the definitive solution, but at least it makes pd work without audio errors.
Katja
On Sat, Feb 7, 2015 at 10:39 AM, katja katjavetter@gmail.com wrote:
On Fri, Feb 6, 2015 at 11:56 PM, Miller Puckette msp@ucsd.edu
wrote:
Also try running "pd -nosleep", which sometimes persuades kernels to schedule the process differently :)
Indeed, "pd -nosleep" does the magic. Command htop shows hat the kernel has 100% CPU time reserved on one core (fixed per session) for pd -nosleep. Pd-gui runs on one of the other cores, alternating. The audio is fine with no dropouts.
It is possible to start two instances of pd -nosleep, and get a core reserved for each. The second instance finds the alsa device busy of course, and this makes no sense in practice. Maybe the [pd~] object can profit from the multicore processor.
I've checked current draw with the setup: Raspberry Pi + USB keyboard
- USB mouse + USB audio interface (iMic) together consume ~400 mA
with
only the desktop running, and ~450 mA with pd -nosleep running idle
or
with a CPU intensive patch. This indicates there is some frequency scaling going on after all. I'll look into that again when there's more info about the new Pi's config defaults and options.
Katja
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Using the following command to check cpu frequency on RPi model 2B:
sudo watch -n 1 cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
I found that RPi model 2B does frequency scaling by default (nothing modified in /boot/config.txt). It switches between 600 and 900 MHz. This doesn't really give substantial power saving so I wanted to replace 'ondemand' governor with 'performance' by setting 'force_turbo=1' in config.txt. But this caused all sorts of instabilities, at least in combination with Pd, and I had to disable turbo.
So there's two things going on which Pd doesn't like: frequency scaling and core switching. Both happen on my core2duo laptop as well, where Pd doesn't have a problem. Anyway, pd's '-nosleep' option saves the day.
Now for the good news: performance gain. I compared model B+ with 2B by running instances of Martin Brinkmann's chaosmonster1.pd (http://www.martin-brinkmann.de/pd-patches.html) at default samplerate and with 10 ms buffer. Model B+ can run one chaosmonster without xruns, but not two. Model 2B can run five instances of chaosmonster1.pd without xruns, while the GUI remains fully responsive. This is not poor Pi as we know it, it's a different beast. I must say that puredata 0.46-2 was compiled from Raspbian jessie source on the Pi itself in both cases. This process uses GNU autotools which may have set platform specific optimizations. In any case, performance gain is much more substantial than I would expect. Hopefully I'm not dreaming.
Katja
This is so exciting. Unfortunately they're out of stock now !
2015-02-10 0:05 GMT+01:00 katja katjavetter@gmail.com:
Using the following command to check cpu frequency on RPi model 2B:
sudo watch -n 1 cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
I found that RPi model 2B does frequency scaling by default (nothing modified in /boot/config.txt). It switches between 600 and 900 MHz. This doesn't really give substantial power saving so I wanted to replace 'ondemand' governor with 'performance' by setting 'force_turbo=1' in config.txt. But this caused all sorts of instabilities, at least in combination with Pd, and I had to disable turbo.
So there's two things going on which Pd doesn't like: frequency scaling and core switching. Both happen on my core2duo laptop as well, where Pd doesn't have a problem. Anyway, pd's '-nosleep' option saves the day.
Now for the good news: performance gain. I compared model B+ with 2B by running instances of Martin Brinkmann's chaosmonster1.pd (http://www.martin-brinkmann.de/pd-patches.html) at default samplerate and with 10 ms buffer. Model B+ can run one chaosmonster without xruns, but not two. Model 2B can run five instances of chaosmonster1.pd without xruns, while the GUI remains fully responsive. This is not poor Pi as we know it, it's a different beast. I must say that puredata 0.46-2 was compiled from Raspbian jessie source on the Pi itself in both cases. This process uses GNU autotools which may have set platform specific optimizations. In any case, performance gain is much more substantial than I would expect. Hopefully I'm not dreaming.
Katja
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 10/02/15 06:49, Chris Clepper wrote:
In general, the ARM will do all sorts of things to keep energy usage to the bare minimum: Video decoding runs on dedicated DSP/GPU rather than the main cores, parts of the cores are shutdown, RAM is put to sleep and so on.
Using -nosleep on a root process at elevated could defeat enough of the low power safeguards as that is something an Android phone/tablet would never do. All of those devices have heatsinks just due to space constraints, and Apple ran afoul of customers due to excessive heat on a dual A8 based iPad.
Without any heat treatment on top of the CPU most of the heat flows through the PCB. So in some cases the issue wouldn't be with the ARM but some other part reaching its thermal limit (like a power regulator or RAM that have to be physically close to the CPU). The UDOO board's WiFi chip gets hotter than the ARM heatsink for example. Freescale recommend heat spreaders and sinks for all of their iMX.6 parts although not all of the low eval boards have them.
the Udoo I have has a very substantial heatsink, much much bigger than the older models, I guess this could be the reason.
Simon
The Pi 2 doesn't have much thermal cooling on the chip and the RAM is directly UNDER the CPU so the heat from both will largely go into the same place PCB. Maybe there is enough copper in the PCB to dissipate the heat, but the thermal docs I have from Freescale say it's not possible to do for a 5W+ quad A9.
On Mon, Feb 9, 2015 at 1:53 PM, Miller Puckettemsp@ucsd.edu wrote:
Interesting. Of course, it _should_ be thermally permitted to run all cores at speed - and the Pi folk are taking heat dissipation very seriously in their thinking. So my leaning would be to risk $35 on a week-long stress test using -nosleep. Hmm, time to order a machine...
Le 07/02/2015 10:39, katja a écrit :
On Fri, Feb 6, 2015 at 11:56 PM, Miller Puckette msp@ucsd.edu wrote:
Also try running "pd -nosleep", which sometimes persuades kernels to schedule the process differently :)
Indeed, "pd -nosleep" does the magic. Command htop shows hat the kernel has 100% CPU time reserved on one core (fixed per session) for pd -nosleep. Pd-gui runs on one of the other cores, alternating. The audio is fine with no dropouts.
It is possible to start two instances of pd -nosleep, and get a core reserved for each. The second instance finds the alsa device busy of course, and this makes no sense in practice. Maybe the [pd~] object can profit from the multicore processor.
I've checked current draw with the setup: Raspberry Pi + USB keyboard
- USB mouse + USB audio interface (iMic) together consume ~400 mA with
only the desktop running, and ~450 mA with pd -nosleep running idle or with a CPU intensive patch. This indicates there is some frequency scaling going on after all.
all instructions have different current draw signature. it's normal to have the current to change depending on CPU utilization, even at fixed clock frequency.
cheers Cyrille
I'll look into that again when there's
more info about the new Pi's config defaults and options.
Katja
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 07/02/15 08:38, katja wrote:
Aplay can play a .wav file without trouble, so it is not a general problem with the audio hardware or drivers on Pi 2b.
I installed command htop to see CPU load per core. It's interesting, the load switches from one core to another, and sometimes they all seem to be almost idle even with a heavy Pd patch running.
are you using a pd compiled for the old, ARMv6 raspberry? or the one that comes with raspbian, which I certainly hope is from debian ARMv7 repositories if you use a raspberry 2. They say they have not changed userspace in raspbian ... hope that does not mean raspbian is still built for ARMv6 with floating point even if you are on a new raspberry!
Try one of the other images ... the new ones are there because they run on ARMv7, and if they have puredata in their repositories then it will be built for ARMv7 also.
Maybe you will need to build pd yourself, but in any case downloading one of the binaries, built for the old raspberries, is asking for trouble.
Simon
On 07/02/15 12:22, Simon Wise wrote:
Try one of the other images ... the new ones are there because they run on ARMv7, and if they have puredata in their repositories then it will be built for ARMv7 also.
Maybe you will need to build pd yourself, but in any case downloading one of the binaries, built for the old raspberries, is asking for trouble.
sorry ... from previous mail you said you built it yourself, so that isn't the problem.
Simon
if it is the changing of cores that is causing the problems, perhaps try setting the pd process to a particular core ...
taskset is the program to set a process to use only a particular core, see its manpage.
simon
On 07/02/15 16:08, Simon Wise wrote:
if it is the changing of cores that is causing the problems, perhaps try setting the pd process to a particular core ...
taskset is the program to set a process to use only a particular core, see its manpage.
you can also get more specific and reserve one of the cores exclusively for the main pd process using cpusets
https://raw.githubusercontent.com/torvalds/linux/master/Documentation/cgroup...
or: man cpuset
this mechanism can also allocate memory and such, the manpage gives a lot of detail, it does not seem difficult to use in a basic way, and could be very useful in the Udoo with its 4 big and 4 little cores, say reserving one for the main pd process, and one of the little cores for a simple interface that you want to be as low latency as possible ... say responding to specific GPIO events.
simon
On 07/02/15 16:54, Simon Wise wrote:
On 07/02/15 16:08, Simon Wise wrote:
if it is the changing of cores that is causing the problems, perhaps try setting the pd process to a particular core ...
taskset is the program to set a process to use only a particular core, see its manpage.
you can also get more specific and reserve one of the cores exclusively for the main pd process using cpusets
https://raw.githubusercontent.com/torvalds/linux/master/Documentation/cgroup...
or: man cpuset
this mechanism can also allocate memory and such, the manpage gives a lot of detail, it does not seem difficult to use in a basic way, and could be very useful in the Udoo with its 4 big and 4 little cores, say reserving one for the main pd process, and one of the little cores for a simple interface that you want to be as low latency as possible ... say responding to specific GPIO events.
the big advantage for this would be that when the core is swapped the cache is invalidated ... this may well be quite significant when doing certain audio tasks, but I am not sure in detail.
Simon
-
Alexandros Drymonitis -
Brian Fay -
Chris Clepper -
Claude Heiland-Allen -
Cyrille Henry -
Dan Wilcox -
katja -
Miller Puckette -
Pierre Massat -
Simon Wise