My name is João Pedro. I recently purchased the Zynthian main board with the goal of building a portable AutoSampler device. My intention is to create a small standalone sampler that I can take to different places, using only a simple 2x16 character display and the Zynthian audio and MIDI interfaces.
I realized that getting the main board to work outside the full Zynthian kit is much more complex than I expected. From my experiments, it seems that the main board works properly only within the full Zynthian OS environment, and without the rest of the official hardware stack (control board, UI hardware, etc.), Zynthian OS does not fully recognize or initialize the board.
My goal is not to run the full Zynthian software stack, but rather to use the main board as a standalone audio and MIDI interface so I can run my own AutoSampler script on top of a minimal Raspberry Pi OS or Debian system.
I wanted to ask:
Is there a way to configure the system (for example via config.txt or device tree overlays) so that the main board works as a standard ALSA audio and MIDI device, without launching the full Zynthian environment?
Are there specific kernel patches, device tree files, or drivers that I should extract or port from Zynthian OS to make the audio input/output and MIDI I/O functional?
Or is the main board fundamentally tied to the full Zynthian hardware and software stack in a way that makes this approach impractical?
Any guidance, documentation, or pointers to the relevant parts of the Zynthian kernel/device tree configuration would be extremely helpful.
Thank you very much for your work on Zynthian and for your time.
Zynthian will run with virtually nothing connected. It just presents connected tech to a jack environment with some assumptions about there being an audio device connected. IT will complain if it can’t satisfy that simple demand, but if you select Dummy in webconf then you can convince it that there isn’t any audio and you can build up devices from there.
So set pretty much everything to Dummies and it ‘should’ start from there. Then add the components ( Display, Wiring etc) back in from there.
IT’s best to keep out of device trees and the vagueries of overlays.
We flatter ourselves we handle all that for zynthian users, so best left well alone, unless you know better, in which case we will joyfully accept a pull request.
The mainboard has nothing special and can run perfectly fine with vanilla RaspberryPiOS. Indeed the ZynthianOS is vanilla RaspberryPiOS with some extra software packages and configuration.
You only need to configure the hardware in the config.txt file, like this:
# For more options and information see
# http://rptl.io/configtxt
# Some settings may impact device functionality. See link above for details
# Additional overlays and parameters are documented
# /boot/firmware/overlays/README
# Automatically load overlays for detected DSI displays
display_auto_detect=1
# Automatically load initramfs files, if found
auto_initramfs=1
# Don't have the firmware create an initial video= setting in cmdline.txt.
# Use the kernel's default instead.
disable_fw_kms_setup=1
# Run in 64-bit mode
arm_64bit=1
# Run as fast as firmware / board allows
arm_boost=1
[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1
[all]
# Disable compensation for displays with overscan
disable_overscan=1
# Force HDMI output
hdmi_force_hotplug=1
# uncomment to increase signal to HDMI, if you have interference,
# blanking, or no display
#config_hdmi_boost=4
# Disable Splash Screen
disable_splash=1
# Boot at full CPU freq
initial_turbo=30
# Allow maximum current in USB ports (Pi5 => 1.6A, Pi4 => 1.2A)
usb_max_current_enable=1
[pi5]
# Is this needed on Pi5?
# Fix core freq for avoiding fluctuation on SPI freq (RGB LEDs)
#core_freq=500
#core_freq_min=500
[pi4]
# Fix core freq for avoiding fluctuation on SPI freq (RGB LEDs)
core_freq=500
core_freq_min=500
[all]
# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=on
dtparam=i2s=on
dtparam=spi=on
# Uncomment to change I2C clock. Default is 100000.
#dtparam=i2c_arm_baudrate=400000
# Enable MMAP support (Jackd, etc.)
dtoverlay=i2s-mmap
# Enable UART for MIDI
enable_uart=1
[pi5]
# Enable tty0 on RPi5
dtoverlay=uart0-pi5
# Enable OTG
dtoverlay=dwc2
[pi4]
# Swap back the ttyAMA0 to GPIO
dtoverlay=miniuart-bt
# Enable OTG
dtoverlay=dwc2
[pi3]
# Swap back the ttyAMA0 to GPIO
dtoverlay=miniuart-bt
[all]
# Adjust UART clock for MIDI Baudrate (31250)
dtoverlay=midi-uart0
# Enable RBPi Onboard Audio (Headphones) => loads snd_bcm2835
dtparam=audio=on
audio_pwm_mode=2
# Soundcard Config
dtoverlay=hifiberry-dacplusadcpro
force_eeprom_read=0
# Display Config
#display_lcd_rotate=2
dtparam=rtc=off
dtoverlay=i2c-rtc,rv3028
Regarding the MIDI ports, you have to understand that they work as normal UART and you need to use ttymidi. For zynthian we use the modtty2midi, that is a specific version for jack audio:
Thanks for your explanation and for sharing the config.txt.
I’m trying to use the Zynthian mainboard MIDI DIN ports with Raspberry Pi OS and ttymidi, but I’m running into an issue with the UART MIDI baud rate (31250).
Here is what I observed:
1. UART mapping seems correct:
`/dev/serial0 → ttyAMA0` (PL011, not miniUART)
2. Setting the MIDI baud rate fails:
`stty -F /dev/ttyAMA0 31250`
→ `stty: invalid argument ‘31250’`
3. ttymidi also fails with:
`Baud rate 31250 is not supported.`
4. Kernel config shows ALSA MIDI and USB MIDI enabled, but no serial custom baud / MIDI UART support (no CONFIG_SERIAL_8250_MIDI or custom divisor options).
So it looks like the Raspberry Pi OS kernel I’m using does not support UART MIDI baud (31250), even with the midi-uart0 overlay.
Questions:
* Does the Zynthian mainboard require a patched kernel for UART MIDI on Raspberry Pi 4?
* Are you testing this on CM4 or on standard Raspberry Pi 4?
* Which kernel configuration or patch enables MIDI UART baudrate support in your setup?
* Is there a recommended kernel or patch reference to make MIDI DIN work on vanilla Raspberry Pi OS?
I don’t know the details, but I do know that the midi support changes the definition of another baud rate like 38,000-Something to come out as 31,250, and they change the clock of the uart in order to make that happen. I’m sorry to make it sound vague and mysterious, but that’s my level of understanding.
I think if you search this forum with some of those search terms you can find the details. And reading the hardware schematics.
edit: here’s the link to the config.txt change needed - it’s a long post, but points to some doc;
And the relevant section is:
Adjust Serial Port Clock to allow MIDI baudrate 31250
[pi2]
init_uart_clock=2441000
init_uart_baud=38400
dtparam=uart0_clkrate=3000000
[pi3]
init_uart_clock=39062500
init_uart_baud=38400
dtparam=uart0_clkrate=48000000
[all]
I enabled UART and tried to force MIDI baudrate (31250) on /dev/serial0, but on Raspberry Pi OS (Debian Trixie / newer kernel) stty does not support 31250 anymore:
soumello@raspberrypi:~/ttymidi $ ls -l /dev/serial*
soumello@raspberrypi:~/ttymidi $ sudo stty -F /dev/serial0 31250 raw -echo
ttymidi -s /dev/serial0 -b 31250
stty: invalid argument ‘31250’
Try ‘stty --help’ for more information.
Baud rate 31250 is not supported.
I also compiled and tested ttymidi manually. It can request 31250 internally, but the underlying UART driver seems to reject custom baud divisors in this kernel, so the device does not appear in aconnect -l.
I researched this further (including ChatGPT and kernel docs), and it seems newer Raspberry Pi kernels no longer expose custom MIDI baud via termios, especially with miniUART / RP1 changes. The recommended way now is using the midi-uart0 device tree overlay or a dedicated MIDI MCU.
So the baudrate setting in config.txt doesn’t directly set MIDI baud; it only stabilizes the UART clock (core_freq), while the kernel or overlay must handle the divisor.
Please, don’t try to set 31250. 31250 is not supported! This baud rate never has been supported! You must set 38400 and configure the config.txt like it’s been explained above.
The 38400 baud rate really works — thank you so much for the tip! I was able to run a small program and send MIDI signals through the 5-pin DIN output.
Now I have a question about the “printer port” USB: my goal is to connect the hardware to my computer using a printer USB cable and have the program recognize it as a MIDI device, so I could also send MIDI signals through this port.
Is this possible, or is it only supported via the 5-pin DIN output?
Just so you know, with the 5-pin DIN I can already develop what I want, but not being limited to that output would be great, since today the printer USB MIDI cable is much more common.