| 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
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
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.
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.
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
Actually, there is a way also to pipe audio between apps, if you use alsa loopback devices. A nice description can be found here:
I do agree that jack is way easier for that though…
Regards, Anders 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. The conversions done by "plug" devices in Alsa are quite efficient.
Regards, Mike
----------------------------------------------------- Michael Gogins Irreducible Productions http://michaelgogins.tumblr.comMichael dot Gogins at gmail dot com
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 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 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=<something>)
I wrote once app CsoundRemote that has helped me in different situations:
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.
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.
<CsoundSynthesizer>
<CsOptions>
--odac -B1024 -b512 -+rtaudio=alsa
</CsOptions>
<CsInstruments>
sr = 44100
nchnls = 1
ksmps = 256
0dbfs = 1
instr 1
asig oscil 0.1, 1000
out asig
endin
</CsInstruments>
<CsScore>
i 1 0 5
</CsScore>
</CsoundSynthesizer>
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
On Sat, 23 Sep 2023, Jeanette C. wrote:
> 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
>
> --
> * Website: http://juliencoder.de - for summer is a state of sound
> * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g
> * Audiobombs: https://www.audiobombs.com/users/jeanette_c
> * GitHub: https://github.com/jeanette-c
>
> 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
|