[Csnd] Best Linux audio setup for real-time Csound

The Csound Mailinglist
1

Hi everyone,

I’m experimenting with using a Raspberry Pi for a Csound project. I’ve only ever done coding on macOS, so this is my first time working in Linux. Currently I’m using a RPi 3 lent to me by a friend, but I’ll order a RPi 4 soon.

Can you share your suggestions for the best audio setup on Linux for doing real-time Csound work? I’ll be curious which Linux distributions, audio backends, and other tooling you recommend. I’ve been reading about all this online. It’s complicated and the information is fractured all over the place. This guide is the most complete one I’ve found for the Raspberry Pi.

Here’s my current approach:

  • The project uses Csound as the audio engine, Python and PyQT for the GUI, and Eduardo’s csoundengine to control Csound within Python.
  • I’m currently running Raspberry Pi OS Lite (terminal only, Debian-based). Open to other distribution suggestions. I’m using the terminal-only version to keep the OS lightweight. I’ll do the actual development on my Mac by SSHing into the RPi, so a desktop environment isn’t necessary. When it comes time to run the GUI on the RPi I believe there are solutions for that from within a terminal-only OS (e.g. kiosk mode on the RPi).
  • I’m planning to use Jack as the backend but am open to suggestions.
  • Apparently I’ve got to install a real-time kernel? Any preference for PREEMPT_RT vs Xenomai?
    Thanks for your help! This will be a big learning curve, so I appreciate your guidance.

Jason

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

2

Hi Jason,

I’ve been running Csound on RPi for a few years now, first on Pi3, now on Pi4. These days, this is my preferred platform for running Csound unless I’m rendering something more complex that is not realtime. Depending on the CPU demands of your Csound code, Pi3 may be enough but Pi4 might be better. I use the normal Raspbian distro. I’m not using a realtime kernel. I use SSH as well and run the Pi headless. My approach to GUI is to run Open Stage Control on the same system as Csound, and access the UI via a browser (usually on a tablet). I have used Csound within Python before, which is fine, but just be careful that the Python code isn’t too heavy. I pretty much always run at 48kHz.

Here’s an example of code I run on the Pi: https://github.com/DaveSeidel/music-src/tree/master/implication-organ

  • Dave
3

Hi Jason,
I haven't run Csound on a Raspberry Pi, so take this with a grain of
salt. But I do use Csound on a Linux machine running in the terminal
only.
Sep 23 2023, Jason Hallen has written:
...

  - I'm currently running Raspberry Pi OS Lite (terminal only,
  Debian-based). Open to other distribution suggestions. I'm using the
  terminal-only version to keep the OS lightweight.

That sounds fine. I personally prefer ArchLinux these days, it is a
little more up-to-date, but may require more hand crafting. So Debian
based distros are easier to manage.
...

  - I'm planning to use Jack as the backend but am open to suggestions.

JACK is fine. If you don't need any further connections to other soft
synths or recording software, pure ALSA may work. It is one less layer
between you and the sound hardware. Csound has access to ALSA audio and
both kinds of ALSA MIDI, the raw devices and ALSA sequencer. ALSA
sequencer will allow you to connect to other MIDI software and it will
allow several pieces of software connect to the same hardware port
without any intermediary device.

  - Apparently I've got to install a real-time kernel? Any preference
  for PREEMPT_RT vs Xenomai?

On all systemes I have seen, PREEMPT_RT is greatly favoured for audio. I
used it. Though depending on your tasks a normal kernel may work just as
well.
...

Best wishes,

Jeanette

4

Thanks, Jeanette. I should have mentioned that I use ALSA. JACK looks very nice, but I haven’t needed its capabilities yet.

  • Dave
5

Everything Dave Seidel says here is spot-on wisdom.

-A

6

My set up similar. Linux openSuSE, no special kernel, ALSA and csound from the command line. Actually I run the development csound although I have csound6 (and earlier versions)) available.

I have tried Jack but it does not seem to offer much. at least for what I do

I have tried on a rPi 4b but for what I do it did not offer any advantage.
The reasons for using a pi include price, and portability for live performing. I seem to remember that there is a possibility of running out of horse power if one tries too much spectral opcodes and other heavy weights, but looking at Dave Seidel's code it clearly can do a lot.
Mind yo I was impressed on what the very early models could do running headless.

==John ff

7

Thank you everyone for chiming in! This was very helpful. I will first stick with ALSA and the main kernel to see if those meet my needs. For now I’ll stick with the Python/PyQt/csoundengine framework for the GUI, but we’ll see if I hit performance issues. The Open Stage Control is a great suggestion that I’ll keep in mind. The reason I’m exploring the Raspberry Pi is that I’d like to build a special instrument for live performance and the small form factor of the Pi is perfect for it.

Here’s a follow up question. I’ve installed Csound on the RPi3 and run the very simple .csd below. It performs successfully and closes, but the audio stutters and distorts. Although the amplitude should be 0.1 it sounds much louder than that. Csound also prints “WARNING: Buffer underrun in real-time audio output” about 70 times.

--odac -B1024 -b512 -+rtaudio=alsa sr = 44100 nchnls = 1 ksmps = 256 0dbfs = 1

instr 1
asig oscil 0.1, 1000
out asig
endin

i 1 0 5

Surely the RPi3 should be able to handle this performance, right? I’m guessing I need to iron out some audio configuration. Can anyone give me guidance here?

aplay -l in the terminal produces this output:
**** List of PLAYBACK Hardware Devices ****
card 0: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 1: vc4hdmi [vc4-hdmi], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0

aplay -L produces this output:
null
Discard all samples (playback) or generate zero samples (capture)
hw:CARD=Headphones,DEV=0
bcm2835 Headphones, bcm2835 Headphones
Direct hardware device without any conversions
plughw:CARD=Headphones,DEV=0
bcm2835 Headphones, bcm2835 Headphones
Hardware device with all software conversions
default:CARD=Headphones
bcm2835 Headphones, bcm2835 Headphones
Default Audio Device
sysdefault:CARD=Headphones
bcm2835 Headphones, bcm2835 Headphones
Default Audio Device
dmix:CARD=Headphones,DEV=0
bcm2835 Headphones, bcm2835 Headphones
Direct sample mixing device
hw:CARD=vc4hdmi,DEV=0
vc4-hdmi, MAI PCM i2s-hifi-0
Direct hardware device without any conversions
plughw:CARD=vc4hdmi,DEV=0
vc4-hdmi, MAI PCM i2s-hifi-0
Hardware device with all software conversions
default:CARD=vc4hdmi
vc4-hdmi, MAI PCM i2s-hifi-0
Default Audio Device
sysdefault:CARD=vc4hdmi
vc4-hdmi, MAI PCM i2s-hifi-0
Default Audio Device
hdmi:CARD=vc4hdmi,DEV=0
vc4-hdmi, MAI PCM i2s-hifi-0
HDMI Audio Output
dmix:CARD=vc4hdmi,DEV=0
vc4-hdmi, MAI PCM i2s-hifi-0
Direct sample mixing device

Thanks!
Jason

8

Hi!

Yes, this csd should run definitely fine. Your kspms and buffer sizes seem big enough.

To find out if it has something to do with the audio system of the RPi, dry different audio modules:
-odac -+=rtuaduio=null ; exclude any actual audio

-odac ; let it choose the default
-odac:1 ; try the HDMi output

or similar try to connect an external USB sound card if you have one to grab.

Does your system have pulseaudio installed? That might be on the way. In that case I would use jack then that gracefully silences pulseaudio.
Pipewire could be also a good option but I have not tried it on RPi.

Hope it helps!
tarmo

Kontakt Jason Hallen (<hallenj@gmail.com>) kirjutas kuupäeval P, 24. september 2023 kell 05:25:

Thank you everyone for chiming in! This was very helpful. I will first stick with ALSA and the main kernel to see if those meet my needs. For now I’ll stick with the Python/PyQt/csoundengine framework for the GUI, but we’ll see if I hit performance issues. The Open Stage Control is a great suggestion that I’ll keep in mind. The reason I’m exploring the Raspberry Pi is that I’d like to build a special instrument for live performance and the small form factor of the Pi is perfect for it.

Here’s a follow up question. I’ve installed Csound on the RPi3 and run the very simple .csd below. It performs successfully and closes, but the audio stutters and distorts. Although the amplitude should be 0.1 it sounds much louder than that. Csound also prints “WARNING: Buffer underrun in real-time audio output” about 70 times.

--odac -B1024 -b512 -+rtaudio=alsa sr = 44100 nchnls = 1 ksmps = 256 0dbfs = 1

instr 1
asig oscil 0.1, 1000
out asig
endin

i 1 0 5

Surely the RPi3 should be able to handle this performance, right? I’m guessing I need to iron out some audio configuration. Can anyone give me guidance here?

aplay -l in the terminal produces this output:
**** List of PLAYBACK Hardware Devices ****
card 0: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 1: vc4hdmi [vc4-hdmi], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0

aplay -L produces this output:
null
Discard all samples (playback) or generate zero samples (capture)
hw:CARD=Headphones,DEV=0
bcm2835 Headphones, bcm2835 Headphones
Direct hardware device without any conversions
plughw:CARD=Headphones,DEV=0
bcm2835 Headphones, bcm2835 Headphones
Hardware device with all software conversions
default:CARD=Headphones
bcm2835 Headphones, bcm2835 Headphones
Default Audio Device
sysdefault:CARD=Headphones
bcm2835 Headphones, bcm2835 Headphones
Default Audio Device
dmix:CARD=Headphones,DEV=0
bcm2835 Headphones, bcm2835 Headphones
Direct sample mixing device
hw:CARD=vc4hdmi,DEV=0
vc4-hdmi, MAI PCM i2s-hifi-0
Direct hardware device without any conversions
plughw:CARD=vc4hdmi,DEV=0
vc4-hdmi, MAI PCM i2s-hifi-0
Hardware device with all software conversions
default:CARD=vc4hdmi
vc4-hdmi, MAI PCM i2s-hifi-0
Default Audio Device
sysdefault:CARD=vc4hdmi
vc4-hdmi, MAI PCM i2s-hifi-0
Default Audio Device
hdmi:CARD=vc4hdmi,DEV=0
vc4-hdmi, MAI PCM i2s-hifi-0
HDMI Audio Output
dmix:CARD=vc4hdmi,DEV=0
vc4-hdmi, MAI PCM i2s-hifi-0
Direct sample mixing device

Thanks!
Jason

My set up similar. Linux openSuSE, no special kernel, ALSA and csound
from the command line. Actually I run the development csound although I
have csound6 (and earlier versions)) available.

I have tried Jack but it does not seem to offer much. at least for what I
do

I have tried on a rPi 4b but for what I do it did not offer any advantage.
The reasons for using a pi include price, and portability for
live performing. I seem to remember that there is a possibility of running
out of horse power if one tries too much spectral opcodes and other heavy
weights, but looking at Dave Seidel’s code it clearly can do a lot.
Mind yo I was impressed on what the very early models could do running
headless.

==John ff

Hi Jason,
I haven’t run Csound on a Raspberry Pi, so take this with a grain of
salt. But I do use Csound on a Linux machine running in the terminal
only.
Sep 23 2023, Jason Hallen has written:
…

  • I’m currently running Raspberry Pi OS Lite (terminal only,
    Debian-based). Open to other distribution suggestions. I’m using the
    terminal-only version to keep the OS lightweight.
    That sounds fine. I personally prefer ArchLinux these days, it is a
    little more up-to-date, but may require more hand crafting. So Debian
    based distros are easier to manage.
    …
  • I’m planning to use Jack as the backend but am open to suggestions.
    JACK is fine. If you don’t need any further connections to other soft
    synths or recording software, pure ALSA may work. It is one less layer
    between you and the sound hardware. Csound has access to ALSA audio and
    both kinds of ALSA MIDI, the raw devices and ALSA sequencer. ALSA
    sequencer will allow you to connect to other MIDI software and it will
    allow several pieces of software connect to the same hardware port
    without any intermediary device.
  • Apparently I’ve got to install a real-time kernel? Any preference
    for PREEMPT_RT vs Xenomai?
    On all systemes I have seen, PREEMPT_RT is greatly favoured for audio. I
    used it. Though depending on your tasks a normal kernel may work just as
    well.
    …

Best wishes,

Jeanette

–

Baby, take the time to realize
I’m not the kind to sacrifice <3
(Britney Spears)

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

9

And one more idea to add for the setup:

for a remote control over UDP of the headless Pi (or any other computer running Csound with --port=)

I wrote once app CsoundRemote that has helped me in different situations:

https://github.com/tarmoj/CsoundRemote

The good thing is that you can export your (simpler) UI from CsoundQt - not all widgets are supported - load it in CsoundRemote, set the UDP port and and IP address in CsoundRemote and off you go. Or you can write you own custom beautiful UI in QML.

Here is a demo: https://www.youtube.com/watch?v=HzsS4s2d2NA&ab_channel=TarmoJohannes

Best!
tarmo

Kontakt Tarmo Johannes (<trmjhnns@gmail.com>) kirjutas kuupäeval P, 24. september 2023 kell 11:09:

Hi!

Yes, this csd should run definitely fine. Your kspms and buffer sizes seem big enough.

To find out if it has something to do with the audio system of the RPi, dry different audio modules:
-odac -+=rtuaduio=null ; exclude any actual audio

-odac ; let it choose the default
-odac:1 ; try the HDMi output

or similar try to connect an external USB sound card if you have one to grab.

Does your system have pulseaudio installed? That might be on the way. In that case I would use jack then that gracefully silences pulseaudio.
Pipewire could be also a good option but I have not tried it on RPi.

Hope it helps!
tarmo

Kontakt Jason Hallen (<hallenj@gmail.com>) kirjutas kuupäeval P, 24. september 2023 kell 05:25:

Thank you everyone for chiming in! This was very helpful. I will first stick with ALSA and the main kernel to see if those meet my needs. For now I’ll stick with the Python/PyQt/csoundengine framework for the GUI, but we’ll see if I hit performance issues. The Open Stage Control is a great suggestion that I’ll keep in mind. The reason I’m exploring the Raspberry Pi is that I’d like to build a special instrument for live performance and the small form factor of the Pi is perfect for it.

Here’s a follow up question. I’ve installed Csound on the RPi3 and run the very simple .csd below. It performs successfully and closes, but the audio stutters and distorts. Although the amplitude should be 0.1 it sounds much louder than that. Csound also prints “WARNING: Buffer underrun in real-time audio output” about 70 times.

--odac -B1024 -b512 -+rtaudio=alsa sr = 44100 nchnls = 1 ksmps = 256 0dbfs = 1

instr 1
asig oscil 0.1, 1000
out asig
endin

i 1 0 5

Surely the RPi3 should be able to handle this performance, right? I’m guessing I need to iron out some audio configuration. Can anyone give me guidance here?

aplay -l in the terminal produces this output:
**** List of PLAYBACK Hardware Devices ****
card 0: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 1: vc4hdmi [vc4-hdmi], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0

aplay -L produces this output:
null
Discard all samples (playback) or generate zero samples (capture)
hw:CARD=Headphones,DEV=0
bcm2835 Headphones, bcm2835 Headphones
Direct hardware device without any conversions
plughw:CARD=Headphones,DEV=0
bcm2835 Headphones, bcm2835 Headphones
Hardware device with all software conversions
default:CARD=Headphones
bcm2835 Headphones, bcm2835 Headphones
Default Audio Device
sysdefault:CARD=Headphones
bcm2835 Headphones, bcm2835 Headphones
Default Audio Device
dmix:CARD=Headphones,DEV=0
bcm2835 Headphones, bcm2835 Headphones
Direct sample mixing device
hw:CARD=vc4hdmi,DEV=0
vc4-hdmi, MAI PCM i2s-hifi-0
Direct hardware device without any conversions
plughw:CARD=vc4hdmi,DEV=0
vc4-hdmi, MAI PCM i2s-hifi-0
Hardware device with all software conversions
default:CARD=vc4hdmi
vc4-hdmi, MAI PCM i2s-hifi-0
Default Audio Device
sysdefault:CARD=vc4hdmi
vc4-hdmi, MAI PCM i2s-hifi-0
Default Audio Device
hdmi:CARD=vc4hdmi,DEV=0
vc4-hdmi, MAI PCM i2s-hifi-0
HDMI Audio Output
dmix:CARD=vc4hdmi,DEV=0
vc4-hdmi, MAI PCM i2s-hifi-0
Direct sample mixing device

Thanks!
Jason

My set up similar. Linux openSuSE, no special kernel, ALSA and csound
from the command line. Actually I run the development csound although I
have csound6 (and earlier versions)) available.

I have tried Jack but it does not seem to offer much. at least for what I
do

I have tried on a rPi 4b but for what I do it did not offer any advantage.
The reasons for using a pi include price, and portability for
live performing. I seem to remember that there is a possibility of running
out of horse power if one tries too much spectral opcodes and other heavy
weights, but looking at Dave Seidel’s code it clearly can do a lot.
Mind yo I was impressed on what the very early models could do running
headless.

==John ff

Hi Jason,
I haven’t run Csound on a Raspberry Pi, so take this with a grain of
salt. But I do use Csound on a Linux machine running in the terminal
only.
Sep 23 2023, Jason Hallen has written:
…

  • I’m currently running Raspberry Pi OS Lite (terminal only,
    Debian-based). Open to other distribution suggestions. I’m using the
    terminal-only version to keep the OS lightweight.
    That sounds fine. I personally prefer ArchLinux these days, it is a
    little more up-to-date, but may require more hand crafting. So Debian
    based distros are easier to manage.
    …
  • I’m planning to use Jack as the backend but am open to suggestions.
    JACK is fine. If you don’t need any further connections to other soft
    synths or recording software, pure ALSA may work. It is one less layer
    between you and the sound hardware. Csound has access to ALSA audio and
    both kinds of ALSA MIDI, the raw devices and ALSA sequencer. ALSA
    sequencer will allow you to connect to other MIDI software and it will
    allow several pieces of software connect to the same hardware port
    without any intermediary device.
  • Apparently I’ve got to install a real-time kernel? Any preference
    for PREEMPT_RT vs Xenomai?
    On all systemes I have seen, PREEMPT_RT is greatly favoured for audio. I
    used it. Though depending on your tasks a normal kernel may work just as
    well.
    …

Best wishes,

Jeanette

–

Baby, take the time to realize
I’m not the kind to sacrifice <3
(Britney Spears)

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

10

Thanks for the tips, Tarmo. Here’s what I was able to do.

  • -odac -+=rtuaduio=null

  • This played successfully without any warnings.- -odac (default)

  • This was stuttering and had all the “WARNING: Buffer underrun” messages.- -odac:1

  • This did not play. It gave this error:
    ASLA lib pcm.c:2660(snd_pcm_open_noupdate) Unknown PCM 1
    *** Cannot open device ‘1’ for audio output: No such file or directoryFailed to initialise real time audio output

  • When I set it as “-odac:hw:0,0” it played out of the headphone device but stuttered and had buffer underruns like usual.

  • When I set it as “-odac:how:1,0” (which is supposed to be ALSA’s designation for the HDMI device) I got this error:
    *** Unable to set requested sample format on soundcard
    Failed to intialise real time audio output- Following some forums online, I changed the system’s default device this way:

  • sudo nano /usr/share/alsa/alsa.conf

  • changed defaults.pcm.card from 0 (headphones) to 1(HDMI) and saved the change

  • set the odac flag back to plain “-odac”

  • This successfully ran without warnings.

  • I then plugged in my USB audio interface and set the default device to 2. This also successfully ran without errors and sounded good on my speakers.
    The good news is that the .csd eventually ran alright. Does anyone know how to fix the *** Unable to set requested sample format on soundcard issue? It would be much more convenient to set the output device with “-odac” rather than changing the default device in the ALSA config file every time.

I just tried playing a .csd that uses the mincer opcode in a pretty simple way. I used the USB audio interface output. There were a fair amount of buffer underruns, but they weren’t very audible. It doesn’t inspire confidence though that the RPi will be able to handle my project which will be running several instances of mincer at the same time.

Thanks,
Jason

11

This is from memory so please just take it as pointing in a hopefully useful direction…

So, the (hardware encoding the audio for the) HDMI output might not allow so many different sampling frequencies as e.g. a usb sound card might do. Also, different sound devices allow different data formats, such as S16_LE, S24_LE etc.

By default (nowadays at least) alsa creates “virtual” sound devices that allow for format and frequency conversion. Typically, if hw:0,0 is the actual sound device, the corresponding converting device is called plughw:0.0
Choosing plughw instead of hw in your csound output should avoid the error but might cause stuttering since the conversion is done in software, I.e. using the cpu.

if you type the command (in a terminal):
aplay -l
(that is a lower case L) you will see a list of available alsa devices, and if you type
aplay -L you will see a list of all available “virtual” devices.

There is a lot that is possible to define in the asound.conf file apart from just the default device, but that might be a bit much to cover in one list posting…

Regards,
Anders

12

The conversions done by “plug” devices in Alsa are quite efficient.

Regards,
Mike

13

Yeah, I suppose, and the documentation says this, if you don’t need to pipe audio between apps, alsa is more efficient than jack? Although jack is pretty solid and doesn’t introduce much overhead at all.

I also highly advise against using a GUI at all on the RPi unless you absolutely have to. And if you do, doing it in a separate thread.

My usual mode with Csound is headless, b/c that is what Csound shines at. If I needed a GUI, I’d use PD or Vsvrack…(depending on the task). I like physicality of interface, so having something like a knobs controller is my goto for parameter interfacing.

14

Actually, there is a way also to pipe audio between apps, if you use alsa loopback devices. A nice description can be found here:

[

Playing with ALSA loopback devices | Playing with Systems
sysplay.in

favicon.ico

](Playing with ALSA loopback devices | Playing with Systems)

I do agree that jack is way easier for that though…

Regards,
Anders

15

Thanks for your additional responses.

Anders, I appreciate you explaining the distinction between hw and plughw. I’ll be doing a deep dive into ALSA and the world of Linux audio because clearly I’ve got to understand all this better. I’m coming from macOS which had its challenges running Csound, but I hadn’t run into anything this complex when working with audio devices. I don’t have plans right now to pass audio between apps, but we’ll see how the project evolves. Good to know that ALSA can do that, too.

Aaron, the GUI is an integral part of the project, so if the RPi can’t handle it I’ll have to bail on the RPi. I’m open to simplifying the GUI or switching to a faster GUI framework to get better performance though. Currently the GUI and Csound are kept in separate threads, and the communication between them is managed by PyQt signals/slots. It all works well on my MacBook Pro, but we’ll see whether the RPi can handle it. I’m not holding my breath. The complexity of this project is such that I’d like to build it programmatically with Csound and Python rather than with more visual systems like PD or VCV Rack.

Thanks!
Jason

favicon.png
favicon.png1024×1024 137 KB

16

Jason,

Consider Dave Seidel’s suggestion of a lightweight browser serving HTTP widgets from an app that can also response to an AJAX request with a forwarded OSC message to Csound. Depending on the setup, that can be lighter on resources for the RPi (or any machine) than using a heavy GUI toolkit.

Per usual, don’t take mine or anyone’s word for it; do some performance testing and CPU/RAM measurements under system load and get empirical evidence.

17

Also, Jason – I think you may have mentioned, but I want to underscore: audio on the RPi is next to useless unless you get an audio card like the Pisound, or similar. The built-in audio card is total garbage, and is built onto the USB bus in such a way that you’ll be fighting a huge uphill battle wrestling for low-latency performance.

18

Thanks for the tips, Aaron! I’ve already ordered an RPi 4 and a Raspberry Pi DAC Pro and they shipped out today. I had heard similar criticisms of the RPi’s on-board audio card.

I’ll definitely keep the browser-based GUI with OSC or UDP communication in mind if (and probably when) PyQt proves to be too heavy. In the past couple years I burned out on doing browser-based GUIs for Csound projects and found Python GUIs much more enjoyable to build. However, if this project calls for the web stack for performance reasons I’ll switch over.

As always, I appreciate your input. I’m grateful to be drawing on the experience of those who built these kinds of things before.

Thanks,
Jason

19

And a day after my Raspberry Pi 4 arrives, the RPi Foundation today announces the Raspberry Pi 5. Funny timing for me, but good news for Csounders that there’s now an even more powerful RPi to make use of.

Jason

20

I use manjaro linux on a tiny $100 mini celeron but since its the latest generation celeron it can handle realtime.
Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here