Ok.
Yes it can all appear intimidating. You are also combining several different fairly involved technical skills, all of which have a considerable bearing on the final outcome.
But you have a raspberry pi ? ( It is a model 3 at least is it.?)
You have a hifiberry DAC out card that has worked with the raspberry pi and speaker test has run successfully?
So that is a good starting point.
You say you have the screen and the encoders interacting properly. Congratulations! that is a considerable part of the functionality Working and altho it doesn’t make any sound does provide a health check. Incidentally was this with the Encoder board connected? If you did say I apologize but I don’t remember if you mentioned it.
The networking side is also awash with traps. Suffice to say if the great and the good were starting the Internet from scratch there would probably be several changes that would be made and networking would probably be fairly high in that list ( If you want purest insane why did we do it that way have a look at email).
But you are past that hurdle because you are using Putty and webconf, so there’s another couple of bit that are playing correctly. Again congratulations.
It would probably be a good idea to try building it from scratch on the bench bit by bit to. It would at least allow detailed pictures of the encoder board, which works ( you can operate encoders and it shows up on the screen) but personally I’d love to see a detailed picture of that board to see how everything looks.( After all that is the component that is most ‘personalized’).
I have built many many zynthians in all kinds of forms using different audio boards, displays and encoder configs. The early efforts were frustrating in the fashion you describe but we get there, and try to roll as much back into the process to help people further on down the line.
You seem to be a little daunted by the commands you are typing. It’s certainly a horrible feeling typing weird incomprehensible bits of magic text into a terminal and very disheartening when the spell doesn’t work. Again this is all done at a distance so we are making a best guess but you actually sit at the reactor whilst we only watch the atomic explosions from a distance.
A few useful things to know.
Audio on Raspberry Pi’s is a complicated system there is.
-
Alsa The bit that handles the audio hardware. When you use speakertest or aplay or aconnect you are dealing with Alsa commands and these are good confirmations that wires aren’t crossed and things are as they should be. THere isn’t really an Alsa server that runs but obviously the Alsa code has to be correct to make it all work… Much of computer programme is indivdual chunks and they all make a lot of assumptions about what is available and if they don’t find it then tend to sulk with obscure lines about Dbus or can’t find . or some such. But you say speaker test works …but next we come to jack . . .
-
Jack An Audio server and a very good one. This is where the magic goes on it allows various Audio & MIDI devices to work together. but it is a completely different component from Alsa althou it uses Alsa to transfer good audio data out to Alsa which interfaces to the hardware. There is a Jack server and this is started at startup and it has to be running for good stuff to happen. The normal way of checking this is a tool called qjackctl which people who use remote linux machines to log on kind of just works but if you are using a windows remote machine you need a component, which I know is mentioned in another of these threads elsewhere (xming seems to be the way to get X-Windowes on windows.) That will tell you if jack is running properly and what it can see in the alsa world. BUt what started the jackd server , well it’s something called …systemd
-
Systemd the start up beast operated by its command line systemctl. This is a long list of instructions on what to do to start up the bits and pieces that are required and also check to see if some bits are already available before thinfgs start and its a great way of starting a row in the many many bars that Unix people retire to after a long day of frustration. What is does allow you to do is start and stop individual components and get the status. The zynthian has several components that run to make it all work and some them will continue to run whilst others are restarted. This is what people mean by a system so you can stop the zynthian component with systemctl stop zynthian. But you don’t need to restart it using systemd and indeed this is the way we run the system to see what kind of error messages the indvidual bits are producing because a ‘normal’ zynth doesnt produce logging because with the ssd disk on a pi this is a fine way to clutter up the disk and corrupt ssds.
I have to go out now but I hope this in some way explains a bit of the magic you are typing. Apologies for the tome, you sound very frustrated and I certainly know that feeling but, remember this is not a personallised bug set aside for you, it’s just a piece of technolgy that has something that prevents it behaving correctly and once it’s fixed it will not remember and will work blissfully. The down side of this is you wont remember the fault so when it reoccurs on your next zynthian you will have to come back here to remember how you fixed it.
Just like toothache…
Keep at it!
