As the work’s focus is to provide an affordable product also chose the Raspberry Pi 3, but a generic audio interface - instead of HiFiBerry.
I’m having issues regarding latency, xrun’s and sometimes crashes. I am not sure, for example, the choice of this interface can hinder the implementation (or as HiFiBerry benefit).
Some things already do, how to use a kernel real-time.
Could you guide me a bit about how you got around such problems? As example, you disable swap, tutorials however suggests the increase.
My sincere thanks. I hope I’m developing may be contributing to the open source community.
First I must say, that all my experience is more or less a rule of thumb, got with trial and error
My experiences with USB-audio (with Linux, but also Windows) showing the same problems like your current one: massive latency and drop-outs. I have several USB-audio devices - the most are really cheap. Only with my Roland UA-25EX I get really good latency and no xruns - but only with Windows and the special USB2 driver from Roland.
The standard USB1.x audio stack seems to be very poor for realtime audio usage. It seems to be designed for chatting/phoning or only playback audio. For more expensive equipment only specialized USB drivers seem to help. But those are normaly not available for Linux
The Hifiberry-DAC+ has a big advantage: It uses Raspberries I2S audio interface, which seems to be fast enough and has not such a big and overloaded stack than USB. But is has only audio-outputs and Hifiberry told us, that they currently not developing cards with audio inputs. So maybe a Cirrus-Logic or a Wolfsen card are the sollution - they have audio inputs (no idea if they sound as good as the Hifiberry-DAC+).
IMHO the only sollution for your project is to use high quality/high speed audio hardware without USB.
Why do we disable swapping? For the Raspi swapping means to write to a swap partition or file on SD card. This is a problem for maximum performance. Using the SD card while playing can result in xruns due to the driver and very slow speeds when writing.
We currently are not using a speciallized RT-Kernel. Until now it was not really necessary. The bottleneck I found is, when you are using a big sample-set which is not loaded fully into RAM and the Raspi needs to load samples while playing…
Yesterday I assembled my custom Zynthian box. It uses a Raspberry Pi 3 Model B and a HifiBerry DAC+, and the Zynthian screen / rotary controls. Works like a charm… almost.
The Jack buffer size defaults to 256. This is not fast enough for me. On my laptop (built-in HDA-intel) and my desktop machine (RME digi card) I use 128… and it feels about alright. With 256 samples, the synthesizers simply feel too slowly responding. Even with 128 when I play fast stuff in setBfree it feels sometimes really weird.
However, the Zynthian system does not work without audible xruns at 128 samples buffer size.
Furthermore, when using my target configuration with setBfree, Dexed and PianoTeq, the latter overloads the system into xruns. However, this is the thing that I badly want… a DX7 something, a Hammond orgen and a real good piano. As for “analog” synthesitzers… I have some that are hard to beat.
Mhh unfortunately I’m quite in love with the “Barking” MK1 Rhodes from PianoTeq. However, PianoTeq is not the primary concern, since so far my Kawai MP6 also does sound too bad.
Without PianoTeq, so Dexed (+ Delay Layer) and setBfree, things work OK at 256 samples. At 128 samples, I get xruns sometimes even without playing notes, so the system generally has issues with it.
I will perhaps try the new Tinker Board S.
One detail may be that Dexed uses integer maths only, as it emulates the DX7. I’m pretty much sure that PianoTeq uses plenty of floating point calculations. These are however my assumptions, this is not hard facts. Asus claim that the Tinker Board S has twice the floating point performance compared to “competitors”.
It might appear nit-picky to insist on a 128 samples buffer but I really can feel the difference and I’m doing my project not to play with PCBs, but to get a instrument for everyday and on-stage use. (Plus, when in multichannel mode, it work out of the box with my setBfree controller prototype: https://youtu.be/ss7H-st3WQU [English subtitles available]).
I’m sure we’d all really appreciate someone putting together a zynth with the tinker board S. I have a pi4 and I don’t notice the latency with 2 periods and 256 samples. Also the best price I found was £90 for the tinkerboard S. It’s a bit steep for me.
Finally, are you using an official pi psu? It seems like nearly all people’s issues with x-runs come down to a combination of poor psu or usb lead.
2 periods and 256 sample buffer at 44100 sample rate gives a playback latency of 11.6ms. This is certainly noticeable by a player, being the equivalent of positioning a loudspeaker 25m from the player. Playing is impacted by anything above 4ms, becoming very challenging when latency increases beyond 30ms. Reducing sample buffer to 128 yields a latency of 5.8ms which is pretty much undiscernable by most players (though may impact virtuoso musicians). In practice most physical instruments have similar latency so this should be an optimal / ideal setting. The RPi3 seems to support a minimum of 11.6ms latency. RPi4 may be better -TBC but we also want to leverage improvements to engines like PianoTeq so may need to stick with 11.6ms. The Python implemented middleware, including the MIDI router may add some latency and MIDI itself adds approximately 1ms (or more depending on the interface).
Jitter is often a bigger issue to players. A player can usually compensate for small amounts of latency but if the latency varies it becomes challenging to play as timing is impacted. There may be scope to review the MIDI layer in Zynthian to check for jitter, i.e. variation in latency, e.g. due to software routines behaving different under different conditions or at different times.
Since I might give the Tinker Board S a chance, I ordered the corresponding Asus power supply for it today. It should also serve the RasbPi 3 nicely. So I will see if this solves something within a couple of days.
In my opinion the Tinker Board S is not too expensive. If you don’t need the audio input, it might as well suffice with its audio output quality, so you’d save the expensive HifiBerry card. So that’s about 30€ more than compared to RaspPi 3 + HifiBerry. I think this is OK when you get twice the performance in return. Perhaps one can use the built-in flash memory, which might be faster and safer than the SD card.
Concerning the feel of latency: Go ahead and youtube for some videos of Hammond players, e.g. Jon Lord, or Booker T. Jones - on the Hammond, one plays extremely short and fast things and this yields a very special effect. I also try to do this, even though I’m not Booker T. - and I it really feels different with setBfree on my PC with 128 samples and on something like the Nord Electro, which is faster. It is a faint difference. But with 256 samples it is disturbingly obvious to me. It’s not like “oh there is latency”, it is like the instrument not interacting properly. Like if there was some chewing gum stuck somewhere.
I’m not sure if the latency argument is aimed at me, but just to be that guy anyway, I’ve never once said that no one would notice the latency. I’m well aware that people notice shorter periods than I do, I expect people who drive F1 cars would notice shorter latency delays than any of us. I’m a grumpy old man and not a professional musician.
Sorry, I don’t want to rain into anyone’s parade, I’m just a grumpy middle-aged man who is picky about the right feel of his instruments. (I recently got caught cooking bass strings in our shared apartment’s kitchen. )
Then we’re reconciled! As a peace offering I set my Pi4 to 128 samples and played as fast as I could. It seems to work fine (I didn’t notice any latency improvement though :D)
Edit to say Pianoteq Steinberg D did give me about 3 or so noticable Xruns in the couple of minutes I played it.
I second Baggypants here regarding USB and Power supply. I noticed disturbing latency only when using an USB keyboard instead of tty. Or if the powersupply was not reliable.
You are sure that you can outrule those?..not using USB Midi…You might have a bumby road ahead if you want to make it work on a Tinker…being the first who ever did.
Mmmmm… Sorry, my friend. The sound speed is 343 m/s … so 11.6 ms is about 3 m. Of course, the latency exist and some highly skilled players are capable of playing fast enough to notice it, but this latency is not a problem for most of players.
Anyway, RBPi4 should alliow us to reduce the buffer size to 128 and have a latency of 5.6 ms.
I don’t think that reducing the latency more than this have any sense for most of use-cases. Reducing latency have a price, performance, and i doubt that anybody in this world can notice a latency of 5ms.
Doh! I should check my maths as well as my grammar! It isn’t necessarily how fast someone plays but how they react to hearing their playing. My playing changes when there is latency even when playing slowly, e.g. playing MIDI guitar leads to very different performance than playing electric or acoustic guitar. I agree that 5.6ms should be fine for most players and that there is little that can be done to reach that on the RPi3.
I tried it and while most stuff like setBFree & OB-Xd was fine, Pianoteq & foo-yc20 had a couple of audiable xruns. Maybe have a 128or 256 setting for it in the webconf if there isn’t one already? Although maybe I then need a heatsink?
I think the question is, “do you feel a difference in latency” as I doubt many of us will hear this latency This is most likely to affect your playing style rather than be a noticable delay of audio.
(I recently got caught cooking bass strings in our shared apartment’s kitchen. 
)
It isn’t necessarily how fast someone plays but how they react to hearing their playing. My playing changes when there is latency even when playing slowly, e.g. playing MIDI guitar leads to very different performance than playing electric or acoustic guitar. I agree that 5.6ms should be fine for most players and that there is little that can be done to reach that on the RPi3.