Does anyone know if it is reasonably easy to get an RT kernel running on thePi?
I'm using devuan beowulf to get a small footprint install *without* either systemd or pulseaudio.with
Actually, this is already better than the official OS when running purely
ALSA.
On 2021-01-07, Folderol <general@musically.me.uk> wrote:
Does anyone know if it is reasonably easy to get an RT kernel running on the Pi?
I'm using devuan beowulf to get a small footprint install *without* either >> systemd or pulseaudio.
Actually, this is already better than the official OS when running purely with
ALSA.
Just curious - have you found the standard kernel insufficient for your >needs? and what are those needs?
My, admittedly limited, experience if this area has never pushed me to
an RT kernel. And when I did research the move to RT (many years ago)
I'm not sure it'd have been much better. Maybe things have got better.
On Thu, 7 Jan 2021 19:55:15 -0000 (UTC)on
Jim Jackson <jj@franjam.org.uk> wrote:
On 2021-01-07, Folderol <general@musically.me.uk> wrote:
Does anyone know if it is reasonably easy to get an RT kernel running on the Pi?
I'm using devuan beowulf to get a small footprint install *without* either >>> systemd or pulseaudio.
Actually, this is already better than the official OS when running purely with
ALSA.
Just curious - have you found the standard kernel insufficient for your >>needs? and what are those needs?
My, admittedly limited, experience if this area has never pushed me to
an RT kernel. And when I did research the move to RT (many years ago)
I'm not sure it'd have been much better. Maybe things have got better.
I don't know that it will make a difference on the Pi, but it certainly does
Intel and AMD processors. Typically I can go from 8mS latency down to 2mS on complex Yoshimi 10-12 Channel performances.
Does anyone know if it is reasonably easy to get an RT kernel running on
the Pi?
On Thu, 07 Jan 2021 17:26:20 +0000, Folderol wrote:
Does anyone know if it is reasonably easy to get an RT kernel running onHave you talked to Microware? http://www.microware.com/
the Pi?
They are in the process of porting OS/9 to the RaspberryPi and Beaglebone.
OS-9 was originally implemented on a 6809 and was designed from the
ground up as a real-time OS rather than a general purpose, multi user
one, which was how I used it. I ran the 68000 port for several years as
my main computer. This was on a 68020 system, where it did everything I >needed for several years (until the hardware collapsed) and I was
pleasantly surprised by its performance and the lack of bugs in both OS
and compilers/utilities.
The only thing that moved me off it and onto Linux was the death of its >hardware.
On Thu, 7 Jan 2021 21:56:05 -0000 (UTC)
Martin Gregorie <martin@mydomain.invalid> wrote:
On Thu, 07 Jan 2021 17:26:20 +0000, Folderol wrote:
Does anyone know if it is reasonably easy to get an RT kernel runningHave you talked to Microware? http://www.microware.com/
on the Pi?
They are in the process of porting OS/9 to the RaspberryPi and
Beaglebone.
OS-9 was originally implemented on a 6809 and was designed from the
ground up as a real-time OS rather than a general purpose, multi user
one, which was how I used it. I ran the 68000 port for several years as
my main computer. This was on a 68020 system, where it did everything I >>needed for several years (until the hardware collapsed) and I was >>pleasantly surprised by its performance and the lack of bugs in both OS
and compilers/utilities.
The only thing that moved me off it and onto Linux was the death of its >>hardware.
I had looked at it when I heard about it, but it would require a *total* rewrite of Yoshimi, and would no longer be free - so not going to happen
on my watch!
On 2021-01-07, Folderol <general@musically.me.uk> wrote:
On Thu, 7 Jan 2021 19:55:15 -0000 (UTC)
Jim Jackson <jj@franjam.org.uk> wrote:
I don't know that it will make a difference on the Pi, but it certainly does on
Intel and AMD processors. Typically I can go from 8mS latency down to 2mS on
complex Yoshimi 10-12 Channel performances.
Ok that's certainly worth it. Sorry I can't help re. RT linux kernel and RPI. >Maybe try the advanced section of the RPI forum? Though I do find that it's not often "advanced".
Linux, RT or not, is not a real time system.
It is a multi-tasker.
I usually design some extra hardware if things need to run fast and continuously. hardware that includes buffers.
example:
http://panteltje.com/panteltje/raspberry_pi_dvb-s_transmitter/
Much these days can perhaps be done with an FPGA hat (have not tried
that). Else you will need to do some electronic design, soldering, etc.
In any case you also need to write the software to interface to that,
You need to specify your requirements.
Sometimes a simple PIC micro-controller is all you need to add to get past the task switch interrupt.. But it will need to be programmed too.
I know a guy from the mailing lists (Gene Hasket) that is operating some
CNC and was complaining about lack of RT in linux. He is using some
patched kernel from somewhere - I do not recall the details, but it is
really a problem that Linux is not applicable to time sensitive
applications.
On Thu, 07 Jan 2021 22:25:31 +0000, Folderol wrote:
On Thu, 7 Jan 2021 21:56:05 -0000 (UTC)
Martin Gregorie <martin@mydomain.invalid> wrote:
On Thu, 07 Jan 2021 17:26:20 +0000, Folderol wrote:
Does anyone know if it is reasonably easy to get an RT kernel runningHave you talked to Microware? http://www.microware.com/
on the Pi?
They are in the process of porting OS/9 to the RaspberryPi and >>>Beaglebone.
OS-9 was originally implemented on a 6809 and was designed from the >>>ground up as a real-time OS rather than a general purpose, multi user >>>one, which was how I used it. I ran the 68000 port for several years as >>>my main computer. This was on a 68020 system, where it did everything I >>>needed for several years (until the hardware collapsed) and I was >>>pleasantly surprised by its performance and the lack of bugs in both OS >>>and compilers/utilities.
The only thing that moved me off it and onto Linux was the death of its >>>hardware.
I had looked at it when I heard about it, but it would require a *total*
rewrite of Yoshimi, and would no longer be free - so not going to happen
on my watch!
Does this mean that OS/9 doesn't have C++ yet?
Pity, because its process scheduler beats the crap out of Linux.
On Fri, 08 Jan 2021 09:56:13 +0100
Deloptes <deloptes@gmail.com> wrote:
I know a guy from the mailing lists (Gene Hasket) that is operating some
CNC and was complaining about lack of RT in linux. He is using some
patched kernel from somewhere - I do not recall the details, but it is
really a problem that Linux is not applicable to time sensitive
applications.
Problem ? It's a fact and always will be that multi-tasking
operating systems and real time processing don't go together unless the
real time demands are very long relative to the processing speed (eg. >payroll).
Time was we used MS-DOS for burning CDs rather than unix because
it only took one late write to make a coaster, buffering and faster >processors means that we can now burn blu-ray discs from a multi-tasking OS >and almost never make a coaster. That doesn't make unix a real time OS it >just means that the timescales have shrunk.
On Thu, 7 Jan 2021 23:37:36 -0000 (UTC)
Martin Gregorie <martin@mydomain.invalid> wrote:
On Thu, 07 Jan 2021 22:25:31 +0000, Folderol wrote:It's not that, it's more a matter of all the linux based dependencies,
On Thu, 7 Jan 2021 21:56:05 -0000 (UTC)
Martin Gregorie <martin@mydomain.invalid> wrote:
On Thu, 07 Jan 2021 17:26:20 +0000, Folderol wrote:
Does anyone know if it is reasonably easy to get an RT kernelHave you talked to Microware? http://www.microware.com/
running on the Pi?
They are in the process of porting OS/9 to the RaspberryPi and >>>>Beaglebone.
OS-9 was originally implemented on a 6809 and was designed from the >>>>ground up as a real-time OS rather than a general purpose, multi user >>>>one, which was how I used it. I ran the 68000 port for several years
as my main computer. This was on a 68020 system, where it did >>>>everything I needed for several years (until the hardware collapsed) >>>>and I was pleasantly surprised by its performance and the lack of bugs >>>>in both OS and compilers/utilities.
The only thing that moved me off it and onto Linux was the death of
its hardware.
I had looked at it when I heard about it, but it would require a
*total*
rewrite of Yoshimi, and would no longer be free - so not going to
happen on my watch!
Does this mean that OS/9 doesn't have C++ yet?
Pity, because its process scheduler beats the crap out of Linux.
the GUI and the drivers for the Pi GPU. Then there's the theading.
Yoshimi uses 4 separate threads. Highest priority for the audio, lowest
for the CLI and GUI.
Even on an old eeePC900 by adjusting the priorities I can see the audio
and interface threads are running on different cores, so with modern high count CPU cores, and GPUs the distinction is becoming moot. I don't know
how to do it myself, but a *lot* of audio processing is very simple
parallel operations - the thing that GPUs excel at!
Folderol wrote:
Even on an old eeePC900 by adjusting the priorities I can see the audio
and interface threads are running on different cores, so with modern high
count CPU cores, and GPUs the distinction is becoming moot. I don't know
how to do it myself, but a *lot* of audio processing is very simple
parallel operations - the thing that GPUs excel at!
do you mean that it were be better using the GPU for time sensitive operations?
I know a guy from the mailing lists (Gene Hasket) that is operating someCNC
and was complaining about lack of RT in linux. He is using some patched kernel from somewhere - I do not recall the details, but it is really a problem that Linux is not applicable to time sensitive applications.
Actually I am not sure how that would sit in parallel cores - I suppose
you would do partial results. The problem is of course that you need to >access the same delay line in memory for all cores, and its actually
those accesses that take the cycles. Assuming you have a fast floating
point multiplym anyway.
On Fri, 08 Jan 2021 09:56:13 +0100
Deloptes <deloptes@gmail.com> wrote:
I know a guy from the mailing lists (Gene Hasket) that is operating
some CNC and was complaining about lack of RT in linux. He is using
some patched kernel from somewhere - I do not recall the details, but
it is really a problem that Linux is not applicable to time sensitive
applications.
Problem ? It's a fact and always will be that multi-tasking
operating systems and real time processing don't go together unless
the real time demands are very long relative to the processing speed
(eg. payroll).
Time was we used MS-DOS for burning CDs rather than unix because
it only took one late write to make a coaster, buffering and faster processors means that we can now burn blu-ray discs from a multi-tasking OS and almost never make a coaster. That doesn't make unix a real time OS it just means that the timescales have shrunk.
.... snip ....
kernel from somewhere - I do not recall the details, but it is really a problem that Linux is not applicable to time sensitive applications.
Linux, RT or not, is not a real time system.
It is a multi-tasker.
I usually design some extra hardware if things need to run fast and
continuously. hardware that includes buffers.
example:
http://panteltje.com/panteltje/raspberry_pi_dvb-s_transmitter/
Much these days can perhaps be done with an FPGA hat (have not tried
that). Else you will need to do some electronic design, soldering, etc.
In any case you also need to write the software to interface to that,
You need to specify your requirements.
Sometimes a simple PIC micro-controller is all you need to add to get past >> the task switch interrupt.. But it will need to be programmed too.
I know a guy from the mailing lists (Gene Hasket) that is operating some CNC >and was complaining about lack of RT in linux. He is using some patched >kernel from somewhere - I do not recall the details, but it is really a >problem that Linux is not applicable to time sensitive applications.
3D printers pretty much always have some sort of microcontroller running
them directly...anything from an 8-bit AVR on up to ARM-compatible devices like the LPC176x or STM32Fx families. Any of these are sufficient for accurately firing stepper motors, monitoring endstops and thermistors,
etc. in a Cartesian or CoreXY printer configuration; more advanced
kinematics (such as Delta or SCARA) sees more benefits from a 32-bit controller.
To the extent that a Raspberry Pi is involved in 3D printing, it's usually just streaming gcode to the printer's microcontroller. Even if you're running something like Klipper (which shifts more of the motion-control
work to the Raspberry Pi), you're still streaming some sort of simplified command sequence to a microcontroller that provides the necessary realtime control.
Does anyone know if it is reasonably easy to get an RT kernel running on thePi?
I'm using devuan beowulf to get a small footprint install *without* either systemd or pulseaudio.
3D printers pretty much always have some sort of microcontroller running
them directly...anything from an 8-bit AVR on up to ARM-compatible devices like the LPC176x or STM32Fx families. Any of these are sufficient for accurately firing stepper motors, monitoring endstops and thermistors, etc. in a Cartesian or CoreXY printer configuration; more advanced kinematics (such as Delta or SCARA) sees more benefits from a 32-bit controller.
To the extent that a Raspberry Pi is involved in 3D printing, it's usually just streaming gcode to the printer's microcontroller. Even if you're running something like Klipper (which shifts more of the motion-control work to the Raspberry Pi), you're still streaming some sort of simplified command sequence to a microcontroller that provides the necessary realtime control.
Does anyone know if it is reasonably easy to get an RT kernel running on thePi?
I'm using devuan beowulf to get a small footprint install *without* either systemd or pulseaudio.with
Actually, this is already better than the official OS when running purely
ALSA.
Does anyone know if it is reasonably easy to get an RT kernel running on the Pi?
I'm using devuan beowulf to get a small footprint install *without* either >systemd or pulseaudio.
On 07/01/2021 17:26, Folderol wrote:
Does anyone know if it is reasonably easy to get an RT kernel running on the Pi?
I'm using devuan beowulf to get a small footprint install *without* either >> systemd or pulseaudio.
This was the second link in a google search for "Raspberry Pi real time >extensions"
https://lemariva.com/blog/2019/09/raspberry-pi-4b-preempt-rt-kernel-419y-perfo rmance-test
---druck
Folderol <general@musically.me.uk> wrote:
Does anyone know if it is reasonably easy to get an RT kernel running on the Pi?
I'm using devuan beowulf to get a small footprint install *without* either >> systemd or pulseaudio.
Actually, this is already better than the official OS when running purely with
ALSA.
You don't say what you're actually doing. I gather that it's some
software audio synth, and I don't know anything about that
application. I'm guessing it's probably existing Linux software
though, so suggestions such as building for bare-metal or another
OS are presumably not worthwhile.
There's a lot of info here, though not Pi-specific. Setting CPU
frequency scaling to "performance" was important for my application
(I also needed to disable video output on HDMI/Composite): >https://wiki.linuxaudio.org/wiki/system_configuration
Real-Time patches for the Linux Kernel:
PREEMPT_RT: https://wiki.linuxfoundation.org/realtime/start
Xenomai
RTAI
There is a PREEMPT_RT patched Linux distro for the Pi (this one
worked alright for me on a Pi Zero and seems to be fairly actively
developed, there might be others that I've forgotten about): >https://guysoft.wordpress.com/2017/10/09/realtimepi/
Thanks for all this further information.
It is indeed a software synthesiser, but a very unusual one. Whereas most of >these either work on sound samples, or previously generated wavetables, Yoshimi
creates everything on-the-fly from mathematical formulae. These can make >dynamic changes within individual cycles, resulting in incredibly rich sounds.
well.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 371 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 174:53:23 |
| Calls: | 7,915 |
| Files: | 12,983 |
| Messages: | 5,797,723 |