So close! Usb interface help please?

Hello fellow Zynthisists!,

I am crafting a mighty beast for my partner’s birthday. He’s a genius on the keys and plays in an actively touring band. I played with many sound engines until finally finding zynthian. This is a crazy powerful system, and almost suspiciously simple compared to the xfm2 and teensy synths I’m working on.

Here’s my question. What are the drawbacks of using a usb audio interface? I’ve got a buggy old umc204hd that worked so smoothly with zynthian, unfortunately a few of its components are burnt and a bit of it’s I/O doesn’t work. Not bad for experimenting, but far from the pro instrument I need to gift my love in just a week and a half!

So I’ve got a tascam us 2x2 that just got here today, and a umc404hd and a steinberg ur22mkII that should arrive soon (oh god I hope).

If I don’t use those options, then I’ll go with my behringer uca202 for audio, and rig up a board for midi. So again, is there a con to running audio ins, and outs, as well as midi from a usb interface? Or would it provide a benefit to rig up an mpc23017 expander to handle the buttons and midi?

Also, my umc204hd isn’t doing midi. I honestly don’t know if that’s because of a surge that made the interface a bit buggy, or if I’m missing something in setting the wiring in webconf. Does one need to do anything special in settings to enable zynthian to use a usb interface’s midi in and out?

I’m trying to test the Tascam now, but some unrelated issue put zynthian in a bootloop, and I’m burning a new image. Bonus points if anyone can help me understand how the box was making beautiful noise this morning, and then seemingly unprovoked got stuck in a boot loop by the time I returned from work. Really don’t want that to happen to my partner. This needs to be more than a neat music toy, but a beautiful box of consistent beats and boops.

Any other advice for making this thing as stable as theoretically possible, would be extremely appreciated. Thank you so much!

You don’t mention the Pi you are using,but personally, I would recommend a Pi4 for it’s increased USB performance.
I’ve not experienced any conflicts in using audio & MIDI on separate USB ports. it just works.
Do make sure the usb audio interface is plugged in when you start the pi otherwise it will fail/loop if a USB audio device is configured on webconf. It’s always a good idea of having some way of opening a browser to view webconf if you can and make a note of ip addresses. windows and android tablets don’t like using names like zynthian.local

Hi @Maravelous77! I hope you and your partner will become regular members of our wonderful community. It sounds a wonderful thing you are doing.

As @wyleu says, USB audio on a Raspbery Pi 4 should be fine as long as the USB audio interface is supported, properly configured and not too rubbish! (Some very cheap devices don’t have good performance.)

One thing to ensure is that the audio device is named in the Zynthian configuration rather than just referenced by index. This will ensure it is always identified as the core audio device used for audio clock timing, etc. Index numbers are enumerated on boot and may change between boots.

In theory the most stable implementation of Zynthian is the Stable release. This may be less feature rich and have some minor bugs unresolved but is the least likely to change (and break) regularly. Major bugs fixes are applied to the stable build as required so installing and updating stable is recommended.

You describe a wide array of hardware and configurations. You should chose a hardware configuration, set Zynthian via webconf and test. If you have an issue then post your webconf configuration here with a description of the issue and we can try to help. You often get quite prompt response and the more info you can give the better.

Thank you!

@wyleu You called it! The boot loop was because I’d switched the usb interface without configuring it in webconf.

I’m using a pi 4. You mention running midi and audio off separate usb ports. Can zynthian utilize the midi ports on one of these usb audio interfaces (umc204HD, Tascam us 2x2, umc404HD, or steiberg ur22mkII) or would it need two interfaces need to be used?(one for audio and one for midi)

@riban Yeah, I’m experimenting to find a great combo that I can fit into one of the plethora of cigar boxes I’ve inherited for work.

You mention the interface needing to be listed in the configuration. By that do you mean it needs to be one of the interfaces listed in webconf? Or is this one of the places I’d need to get deep in the code of it all? I saw someone mentioning that they use the Tascam us 2x2, but it isn’t supported by default

Thank you both again for your help :grinning:

You can use any and all of the USB MIDI interfaces connected (and supported) including the ones that are part of the audio interface. So you could plug in a combined audio and MIDI interface and use both the audio and MIDI of that device. You could plug in extra MIDI interfaces and use them. You cannot (easily or efficiently) use more than one audio interface. You cannot hot swap audio interfaces. It has to be connected at boot and configured correctly in webconf.

If you have a USB audio interface that is not listed in webconf then you can choose Generic USB Devce which works with most “Class Compliant” USB Audio devices. (Class Compliant means the interface uses a standard audio over USB standard. Some devices may use proprietary interface requiring drivers which may not be available for Linux.) USB MIDI tends to work. Again class compliant devices should just work. They don’t need any configuration although there is the ability to configure some filtering in webconf - but that is generally for more complex workflows.

The Tascam may work - there are mixed reports. One such report said it started to work after a while of being plugged in. If this happens then it may prove unreliable because Zynthian depends on the soundcard being available from early in the boot process. Please try it and let us know of your success. The other cards you mention should work but again, let us know your success.

Good luck!

[Edit] Steinberg is in the list on webconf. If it is in the list then someone has tested it and given us configuration so it should work.

1 Like

Well the normal way of expressing gratitude round here is :face_with_monocle:

Press on the monocle’d icon to see what this means if it’s unclear.

1 Like

I have a Tascam US 4x4 - the four channel version, and it works well including MIDI.
To enter the configuration you have to use the “Generic USB device” Soundcard, click on “Advanced view” and put the following into the JackD Options field (yours will probably listed as US2x2):
-P 70 -t 2000 -s -d alsa -d hw:US4x4 -r 48000 -p 256 -n 3 -X raw


stuff that config in a bug and we’ll make you’re own menu item for you and your fame will last forever!

1 Like

This community is excellent :grinning: :face_with_monocle:

I’ll be uploading some progress media soon! It’s been months of research, and a wildly exceeded prototyping budget :sweat_smile: , but this baby eldritch beast is expected to born, and presented to its new master sometime this week! Can’t express enough gratitude for the zynthian community and developers for having such a beautiful vision and following it through. Music to the masses!!!

P.s. woof, chips are getting scarce and pricey

Hello Friends,

I’ve got my circuits planned for the 4 rotary encoders, and 4 push switches. And they should be all soldered together tonight and tomorrow. I’ve got all the pi 4’s GPIO pins avaailable; as the screen’s display is thru hdmi and it’s touch, audio output and input, and midi are all running off usb.

Is it fairly straightforward in webconf to assign the 4 encoders, and 4 momentary switches(the ones attached to zynscreen in the current Official Kit) to gpio ports? I saw that support wass added in webconf to set up extra switches, and I’m hoping that the same area can set up these not extra switches and encoders.

Also, is there a functional limit to how many things can share a ground on a circuit? Someone in a thread I can’t find here mentioned they connected some encoders they got off amazon to separate ground pins on the pi. But it that entirely necessary? As I understand it the ground pins on the pin are a single ground circuit.

Thank you again for the help! :face_with_monocle: Home stretch!

1 Like

Lol, I’ve been so hyperfocused on this project, I only just noticed what you meant by the monocle face @wyleu :sweat_smile:. I just read your reply, but popped back to ordering a few last cosmetic bits. I thought one uses it to express gratitude. You were saying I should post some media :sweat_smile:. No worries much media is coming :relaxed:


Stuck at work, but the research continues! Gonna drop the resources I’m finding here. Both so I can find them when I’m off, and for anyone else who stumbles on this post searching for truth.

Wired up some encoders but got stumped when I saw the pin values in webconf. Then I stumbled on more wonderful work by @wyleu. Believe this is the answer to what pin numberings to use when setting up encoders and buttons in webconf:

What does one do to discover what jackd options would correspond to a usb audio interface? I’ve gotten the system up and running on a behringer umc204hd by using the preset for the umc404hd in webocnf, but can’t get midi on that interface to come in(haven’t tested out yet). The used steinberg ur22 mkII I found isn’t being recognized with the ur22 mkII preset in webconf. @catherder how did you grock the settings you’re using for the tascam us4x4? Unfortunately they aren’t working for me on the us 2x2 (even with changing the name in jackd options to match the different model)

If I know where to look for such identifying info on an interface, I’m hoping I can unlock midi on the 204HD, or get it all working on the 2x2 or ur22. If I can’t get those working I might have to cobble together a midi board and use one of the two behringers that are making noise.

Thank you again for any help you can provide

Somewhat an offtopic and probably not worth it for this project, but one non-obvious benefit of using Pipewire (Pipewire (built from source, not from RPi repo)) is that it discovers all devices itself, so no need to bother with jackd command line (nor try to fix the boot loop if the USB interface is disconnected).

Pipewire does look interesting. Unfortunately I’m working to get this thing up and running in a few days. It’s for my partner’s birthday gift, just before they’ll be moving away for a few months. If it weren’t for concern over lead times, I’d have just ordered an official kit. So many people have reported success that I know there’s got to be a way to get everything running on one of these usb audio interfaces with midi that I have now. Anyone have any tips on how I can find what information needs to be in jackd? Zynth boot loops on the tascam us2x2, and steinberg ur22MKII, with the default and suggested webconf settings. It’s boots great on the umc204hd and uca202(using umc404hd and uca222 webconf defaults). But uca202 does not have midi, and I can’t seem to get anything in or out(finally tried out) of the midi ports on the UMC404hd.

Sorry this may be a very noob question. I’ve got an alright handle on the circuitry, but the code side of things is still fresh for me and essentially a foreign language. Thanks again for any elucidation that can be offered

Using a Behringer 1820 the Midi just functioned. It’s not related to the audio settings, bu I suggest a look in the Webconf MIDI settings, just to see what the zynth believes is visible.
aconnect - l


on the zynth command line will reveal what devices are available in the Midi alsa world and by extention what is available to jack.

and pressing the plus symbol (+)

The audio settings are derived from
aplay - l
in a similar way. The command line values are parameters for jackd and are defined in Jack’s not particularly helpful documentation. The most important thing to realise is that the default behaviour selects devices by number and these can change on startup or devices present or sometimes just the colour of the last car that past, so it’s really the name you need for webconf as this sets the link emphatically. The rest are rate settings or similar.

Pipewire is certainly of interest, because it looks like a component that will break throu the one audio device limit that are imposed at the moment. I posted a thread with one of my normally evasive experiments using a USB 1/4" jack to USB and a hifiberry card but the two clocks drifted and clicks occurred, so that’s as far as it directly went, but we’ve certainly discussed it informally.

So I suggest you use the command line to ensure the MIDI port is detected because without that you might have a broken midi port, and if that’s not the case make sure it’s seen by alsa and then progress with patchage and Jack commands to see what you can and can’t see.

Hope this helps.

1 Like

Thank you @wyleu! I got no where with my efforts last night, but this sounds like the info I need. Gonna give it a try now :grin:

Hello friends!

Fresh new hell :sweat_smile:. If y’all help me fix it, I’ll upload some sick audio :blush:. I’m seeing info all over the place, but it’s not terribly organized. Has anything changed about what pin numbering the wiring in webconf uses?

The link I put above on connecting encoders directly to the gpio, seems to answer the question. Yet I’m getting no response from the zynthian system. I see people have gone round and round explaining the encoder breakout boards you can get on amazon and aliexpress. I opted to use unboarded encoders. To the best of my knowledge the use the standard encoder pinout.

If they don’t use some uncommon pinout then looking at the bottom of the encoder, with three prongs on right and two on left, going clockwise starting at roughly 1’oclock on a clock face, they would be: pin A, cnt grnd, pin b, switch ground, and switch.

But using wpi pin numbers in webconf is giving me nothing. I haven’t tried to make a debouncing circuit, just hooking them directly to gpio. I’ve tried putting them wherever feels convenient, and I’ve tried putting them where I can see others have put them in their webconf screenshots. But I’m getting nothing. That’s what makes me wonder if maybe the pin numbering convention was changed in a release between the forum posts I’m seeing(mostly late last year) and now.

Or is it possible I’ve got a whole set of 10 bad encoders? It was amazon, and no one can really speak for their merchants quality control. I saw some where that you can only daisy chain about 4 encoders to a ground. Is that a thing? I haven’t actually hooked all 4 encoders up at the same time(experimenting with different connection types left me with less socket to plug jumpers). Have some good wire and a terminal breakout arriving today that will let me rig them all up at once, waaaaaayyyyyy easier than I was doing it.

Do all the encoders need to be connected simultaneously for any of them to work? That could be another reason that mine isn’t working. Do to having only 6 socket to plug jumpers I could only try one at a time on breadboard. When I did this I used x,none,none,none in the pin a, pin b, and switch fields, where x is the wpi pin number that I’ve connected the encoder pin to. tried running switch gnd thru center gnd, and running it to it’s own ground pin, with no luck. As I understand, the gpio pins supply 3v so there’s no need to hook the encoder to a 3v3 or 5v powerline(heard 5v can fry the pi) So if for some reason the encoders only function in zynthian when all 4 are connected, then that would explain why I can’t get anything to come up for the encoders I’m programming. Wouldn’t make sense to me, but most things don’t until they do.

Also, for any future zynthisists out there: Webconf does not ask to reboot when new wiring is saved, it just reboots. Don’t hit save again in webconf, before it reboots. Expecting the prompt to reboot, I hit save again thinking webconf didn’t hear my mouse click. If zynthian is rebooting and you hit save on wiring in webconf, it will corrupt the zynthian image and you’ll need to flash a new sd card.

Any help with this wiring nightmare would be greatly appreciated. It seems preposterous, but not impossible that all 10 encoders I ordered are bonk, and I tried so many ways of hooking them up(breadboarded, fully soldered, soldered encoder to breadboard to pi). So unless all the various solder joints and breadboard connections are failing, it seems like there has to have been a change in how the zynthian wiring in webconf works between now and the last slurry of this question being answered.

You’re all bad asses, and I really appreciate your work. I know it’s got to be frustrating to reteach every new generation, and that’s probably where some of the “your answer is somewhere on the forum, go look for it” responses come from. But a lot of the people finding answers sort of drop off posting once they figure it out, leaving weird info gaps all over the place. If any of you actually geniuses could provide clarity, or clarifying links, then maybe we can compile these fixes here, and then maybe transfer them to official documentation. Plus, again, I will reward you with some tasty bass riffs my fingers and zynth keep coming up with :blush::face_with_monocle:

Thank you again


I don’t think anything has changed.

The three pins are the encoder with common in the centre. The two pins are switch which can be wired either way.

There is sometimes a capacitor on encoder PCBs to act as a filter but this is not necessarily required and generally reduces risk of false triggers, i.e. is not required to get the thing working (or at least partially working).

Pretty unlikely. I have never had any completely broken encoders and I have bought a lot of cheap units.

That is more of someone’s rule of thumb. It depends on the wires used, the quality of the ground, the routing of the wires, etc. At these currents and these speeds I would expect you to be able to use a single common ground pin for all connections.

No, they do not but you do need to configure them all in webconf.

I think this is most likely your issue. Assign valid and free GPI for all four switches and all four encoders. I seem to remember (not checked the code today) that there is a constraint that partial configuration is not acceptable.

Indeed! The encoders and switches act as switches between the GPI pin and ground reference. The GPI is held high by internal resistors and when the switch closes it pulls the GPI low which is detected by code running on the Raspberry Pi. (Encoders are just two switches that open and close in a particular pattern.)

Please report this as an issue.

This is more of hacker info. The official kit should just work and should be properly documented in the official documentation. The forum is a good place to ask, answer and search for info on non-standard builds like this. It can be a haystack with you not knowing if that precious needle of info is in there so it is good if questions and answers are clear, unambiguous, fully descriptive and ideally, edited for accuracy.

I would suggest you configure the hardware in webconf for all the GPIs for the 4 switches and encoders then try just one switch first, e.g. BACK switch. This should allow you to see that the simplest action is working. If not you can diagnose that simple issue. If it is then you can start to add more switches and encoders, diagnosing issues as they arise without trying to boil the ocean!

Good luck.

Thank you. I think that confirms what I was wondering. That if the encoders aren’t set in webconf it could cause a problem. Several of the attempts were done with the wiring from others screenshots, and pre-existing wiring profiles in webconf( emulator I think was the only one that starts out with values all under 100). By which I mean I left the other wpi pin numbers in webconf, and just edited the 1st one in each field to match the gpio pins the encoder was connected to. So, in theory, my switches or encoder turns should have worked on one of those tests. But still nothing. I’ll be trying again this afternoon tho, so fingers crossed.

Thank you again