I am trying to set up Zynthian emulator (i do not have any hardware parts) to work under Raspberry Pi 3b.
I want to use Zynthian emulator in a “poor man’s build” via VNC in the end , replacing TFT screen and knobs with my tablet over wifi, as unfortunately I do not have spare money, but i have spare 6.5’’ tablet instead and a USB CM108 audiocard, which had a fine (latency too) for me when I tried SamplerBox under Raspbian.
Probably I will be able to switch to HiFiBerry later, if sound quality/latency issues will be the last thing left.
What I have done:
I had started with Gorgona image flashed.
1)I had replaced /dev/fb1 with /dev/fb0 everywhere where I found it to be mentioned (in zynthian scripts and Xorg config), commented out TFT screen driver line in /boot/config.txt to replace unexisting TFT screen with HDMI display.
1)I had commented out hifiberry driver line in /boot/config.txt, and was able to force Zynthian to work with my usb CM108 audiocard by setting a proper device (hw:device,0) in jackd2 service file and zynthian_emu.sh script
I had installed python3-PyQt4 package from the default repository (zynthian emu gui requires it to start, but it was not initially included), replaced zynthian.sh with zynthian_emu.sh in systemd service file.
created a file with “PROTOTYPE-EMU’” text in /zynthian/zynthian_hw_version.txt, and replaced prototype variable with PROTOTYPE-EMU in zynthian_gui_config.py
added max_usb_current=1 in a /boot/config.txt to ensure that keyboard, usb audio, mouse, and a USB MIDI keyboard will not jump out of the power consumption limit.
Result
Good news:
Zynthian GUI (A window where presets can be choosen) appears, and seems to respond correctly to mouse clicks
Zynthian Emulator (that window with knobs and buttons) appears around/under GUI too and looks fine.
After choosing a preset sound starts playing with a latency fine for me.
Bad news:
Any manupulations with Zynthian Emulator knobs or buttons lead to disappearing of Zynthian GUI window.
zynthian_gui.sh dissappears from ps -axu list too.(If started manualy instead of service, from the xterm in the window manager environment, Zynthian Emulator console starts complaining that no process pid exist. Also, emulator has a separate window in the window manager env, so i was able to check that GUI is not just “sent to back”)
Sound does not disappear when GUI dies.
Sound disappears after about couple of minutes (3m12second according to last measurement) of playing, regardless of GUI issue , increasing jackd -p parameter up to 1024 does not have any effect. No glitches typical for latency problems are heard before or in the moment of disappearing sound.
Questions
Does anyone have any up-to-date instructions for such case?
For setting up zynthian emulator correctly (and sharing it via vnc, if possible, but the vnc part seems to be exotic offtopic, so I think I will have to deal with it on my own )
Existing manuals that I could find seem to be outdated and lack details.
How can I get any zynthian extended logs to read and think about? Looks like I am completely out of ideas at his point and no new information to debug and move forward.
What can I possibly do with Zynthian Emu killing Zynthian GUI?
Any ideas regarding disappearing sound?
P.S. I’ve tried to make the same starting with bare Raspbian Jessie image (the one with desktop environment), and runned into the same GUI dying issue after installation and ± the same tuning.
Would like to notice, that this kind of setup fails on the compilation stage due to running out of memory (regardless of swtching to init 3 and disabling xserver), so i had to add 300mb of swap and disable swap tuning in setup script to give it a chance to finish the job,
Your scheme is interesting. You are not the first one to try something similar with Zynthian.
The Zynthian Emulator is not intended for playing and certainly is not for “plain users”. It’s mainly used for Zynthian development on a desktop computer. Probably you will have problems when running the emulator on a remote display. Embbeding the UI window inside the emulator frame is quite tricky, so perhaps you have to revise this part.
Good luck … and give details and feedback of your advances!
I have a funny feeling that I’ve wrote so many details that the questions got buried under the tons of my text
I totally understand that I am going to use it in a way that it is not designed for, so I will not complain a lot when it will go banana when it will come to remote screen.
But at the point where I’ve stuck now, remote display is not involved yet. I just get GUI dying every time when touch anything in the Emulator on the locally connected HDMI screen. Therefore I guess that I am not so far from the main scope yet.
(Please correct me if I am wrong, but I am under impression that emulator is supposed to work on RBPi itself too - at least there is a separate script for installing emulator on the desktop, and the separate for the RBPi)
I would appreciate any clue why can GUI stop just after catching a signal from Emulator
I’ll try to look into this possibility, for some reason (i do not truly recall why) i had tought that this web interface is not a full replacment for the main gui and knobs, but now I will doublecheck.
Okay, ive found the piece of code that sends SIGRTMIN in the zynthian_emuface.py, injected some logging and found that it sends signals to the PID of the zynthian_gui.py
The thing is, that zynthian_gui.py terminates as well if i, for example, manually send the signal, like kill -34 $PID_of_zynthian_gui.py
I’ve read zynthian_gui py file several times, but was too blind to find where SIGRTMIN signal is handled.
I am starting to suspect, that signal handling does not work because raspberry actually HAS gpio.
In a blog @jofemodo had mentioned that emulation layer starts to work when Zynthian cannot detect GPIO, so I will try to mock it and disable all gpio kernel modules, or delete /dev/gpio maybe it will start working.
Also there are following lines of code in zyncoder.c:
Looks like signal handling is in wiringPiEmu.c and emulation support is actually enabled or disabled on the compilation stage, so probably I will have to hardcode using of wiringPiEmu and recompile zyncoder.
Okay, that was quite a pain, but I’ve finally managed to make emulator to work on my raspbian.
Maybe someone will find this useful and will not spend whole night to figure this out as me.
My last guess was close - there was no handling of the incoming POSIX signals in the default built zyncoder in the Gorgona image (and unhandled signal just terminates the process by default, lol) , because it is binded to a real GPIO during compilation, and it should be rebuilt with swtiching to emulation to make it work. ( emulation and real gpio exclude each other, because real gpio library is just replaced with emulation library at the bottom)
Signal handling is made in wiringPiEmu.c
So, the steps that leaded to working emu for me:
in the quote from zyncoder.c that i’ve shared in the previous post ive removed everything except include of wiringPiEmu.h
in zyncoder/CMakeLists.txt ive removed from the part below everything except the bold part
Okay, looks like disappearing sound mystery is related to usb.
At least, this happens in the same time when dmesg reports that my usb mouse (?!?!?!?!?!) reconnects. maybe it has something to do with powers supply (serioulsy, 2.1 amper is not enough? wow.), and it is not really clear how it is related to sound, but looks like I can skip this part and go ahead with vnc setup, because I will be able to disconnect that mouse (and keyboard) after that, reducing the power usage. Probably this will let me to get rid of this issue.
UPD: nope. it did not help. issue is still there. Realvnc seems to be unsuitable for controlling emu too, because android client emulates mouse in a trackball style, and that is totally inconvinient for this case.
I have commited to the repositories some changes that should ease the emulator setup in a RBPi with remote display. These are the steps to follow:
Download and burn Gorgona image in a SD
Boot your RBPi with the new SD and login
Install PyQt4 package, that is missing in the Gorgona SD image:
apt-get install python3-pyqt4
Update zynthian software, getting the last changes from the repositories:
cd /zynthian/zynthian-sys/scripts
./update_zynthian.sh
Recompile the zyncoder library for wiringPi emulation:
export ZYNTHIAN_FORCE_WIRINGPI_EMU=1
cd /zynthian/zyncoder/build
rm -rf *
cmake …
make
Reconfigure the zythian UI
cd /zynthian/zynthian-ui
sed -i – “s/PROTOTYPE-4/PROTOTYPE-EMU/” ./zynthian_gui_config.py
sed -i – “s/width=None/width=320/” ./zynthian_gui_config.py
sed -i – “s/height=None/height=240/” ./zynthian_gui_config.py
Run zynthian with the emulator GUI:
export DISPLAY=aaa.bbb.ccc.ddd:0
cd /zynthian/zynthian-ui
./zynthian_emu.sh
Where aaa.bbb.ccc.ddd is the IP of your remote display device. The remote display device must have a running X11 server, of course
From here, there are many improvements to do:
autoscale the emulator frame to allow greater window sizes
I’ll give it a try with a remote Xserver, as i am not happy with realvnc solution on android.
I am not sure about software behaviour in case if I will try to use raspberry as a wifi access point- in that case it means that zynthian will try to launch before Xserver will be available.
P.S. Some kind of webinterface could be a nice addition to use anything with a browser on board as a remote control.
I was/am having this same issue–can’t wait to try your steps here in a bit.
I too started from Gorgona image.
Is original poster openbox or some other window manager? My best results happen when I launch Zynthian.sh from the UI folder. I also had to kind of hack the jack2 server so it has better output on the onboard bcm sound card. I was OK with a lengthy latency (about 500ms) because I’m just trying to hear samples.
I plan to buy and build eventually but for now I just want to hear samples!!
Once I buy/build, I’m going to make a video of just basic use of the UI/walk through and show what the sounds are like. I’ve heard good things about the sound of these synths but I’m picky about samples.
I will say I’m surprised that your GUI was responding to mouse clicks–my Emuface UI responds just fine. The main Zynthian UI responds to mouse clicks and like up and down keys, but… not in a normal way that I can/could describe. I’m not complaining cause I’m using USB keys/mouse, and not the rotary controls…
I’m so very happy to report that after doing the steps @jofemodo lists above, I am able to use the emulator and have the zynthian UI appear properly in its desired place in the box surrounded by the “software faders”. Awesome work, and thank you!
Attached is my working version on a Raspberry Pi, with no additional hardware except a USB <-> MIDI cable and a USB keyboard.
I actually didn’t really need the fader buttons once I did the above changes because I was able to click and manipulate the UI directly. So instead of
$ ./zynthian_emu.sh
I was able to do
$ ./zynthian_gui.py
Very very cool project guys. I hope I don’t get banned for being overly active on this forum, but I’m really looking forward to getting ahold of some hardware!
Not too much people have succeed in getting a working development Zynthian environment. Good work!
All the engines are working correctly? Can you give more details about the setup?
HDMI Cable out of the Pi, going to an old Panasonic TV I have
Typical power cable
Ralink USB Wifi Driver
Wireless keyboard/mouse (not Bluetooth; one of those older 2.4Ghz or something)
USB <–> MIDI cable I mentioned previously (you can buy them for $7 on Amazon)
Again; downloaded the Gorgona image.
Hmm, “all the engines” is a bit unclear to me, to be honest. Some things seem like plugins and others are obviously plugin hosts, and then there are Synth engines and then there are MIDI samplers and etc. I do remember seeing more things, I thought, than the start up for my Zynthian:
In case the above doesn’t load right for you, see the following engines:
ZynAddSubFX
LinuxSampler
FluidSynth
setBFree
MOD-UI
I think I remember reading about others in the forum and in docs, so maybe the answer to this is no? They aren’t all loading? For example, the Github readme for the Emuface says it supports “Carla”… I’ve not seen Carla anywhere on the system… however, I have seen the MOD-UI.
The MOD-UI is not quite working how I’d like. I think it may have to do with some of the steps you mentioned above @jofemodo – that is, I think I need to enable the monitor and host in jack2 and not just any old place. It works in that I can load it in the browser and mess with pedals all day, but I can’t get it to produce any sound even while the other engines are producing sound just fine.
I was thinking I would create some topics in the “development” category about various parts of this process, since it might help others.
OK! It’s correct. 4 is the number of “standalone” engines. The rest of “synth engines” must be executed inside MOD-UI, as plugins. Carla has been replaced by MOD-UI. It has no sense to maintain both, and Carla engine wasn’t too stable anyway