Just wanted to share my experience on using Jamulus on a Raspberry Pi 4 (4 GB version) with the PiSound Hat. (https://www.blokas.io/pisound/)
This hat is a high quality, low latency ADC/DAC board that has 1/4" jack input, 5 pin midi input, and 1/4" jack output. It uses the I2S bus for superior (compared to USB anyway) communication with the Raspberry Pi. It comes with an optional PatchBox OS that is based on the Raspian OS (a variant of Debian) that has some things pre-configured for you. PatchBox OS also uses a real-time kernel, but it works fine with just the regular Raspberry Pi kernel as well.
I installed Jamulus on this machine, and have used it both as a server and a client. Now as a server, you don't need the PiSound hat, so this post will discuss the experience of using the Rpi in client mode, with the PiSound as my audio input/output device.
Basically, the PiSound shows up as an audio device to ALSA, and is fully compatible with Jack. Now, I'm not an expert at all with Linux audio, so I'm sure there are better ways to set it up than what I ended up doing:
The PatchBox OS has jack2 pre-installed, and in my case, I chose not have to jack auto-start at boot.
The PatchBox OS has Patchage pre-installed to handle audio connections, but I wasn't able to get it to work. I'm sure it's just my limited experience with it.
So I installed qjackctl instead. The trick is to start qjackctl before starting the Jamulus client, and select the audio device you want to use (in this case, the PiSound). I set the buffer size to 64 samples, 2 periods.
Then I ran the Jamulus client and connect to a Jamulus server. The appropriate Jack connections, at least for me, were automatically made (of course I told qjackctl what device to use.)
In my tests, for a Jamulus server I set up an Amazon AWS EC2 server (t3.micro instance) in the LA Zone of the Oregon region. I set it up there because I'm located in Phoenix, and this gave me the closest connection to an AWS server that I could get. With Jamulus running on the Raspberry Pi/PiSound, I get a stable ping time of 16 ms, and an overall delay of 25 ms. That's pretty darn good!
The thing is, with the Raspberry Pi/PiSound, the Jamulus connection is ROCK SOLID. It rarely varies from these times. So far, I've been able to test it with three other musicians (for four in total), and on my end, after several hours of jamming, I never had a single xrun. The auto-jitter-buffer had settings of 2 for local, and 2 for server. The jitter buffer settings rarely varied from these amounts after settling in.
The other musicians said my fiddle was coming across clear. Their instruments were clear at times, warbled at other times, but not intolerable. These other musicians don't necessarily have the best audio devices or the best internet connections. I forgot to mention I'm running COX Gigablast, which means a fast, stable, fiber optic line. The other musicians, located in other parts of Phoenix, are using slower, more conventional COX connections, and were reporting 20-25 ms ping, and their overall delays were in the 40-50 ms range. Some were using a Mackie mixer interface, some were using lowly Behringer UM2 devices. Compared to these, my Raspberry Pi client was roughly 15 - 35 ms faster not including the ping times.
I have to say I'm impressed with this set up. My Windows desktop Jamulus setup is just as fast, with the same amount of delay, but it has occasional dropouts, so it's not as good, even though it runs at 3.5 Ghz. It's also fully loaded with stuff, including many old-school hard drives. Having a machine dedicated to Jamulus, with little on it, really helps, even if it's a lowly 1.5 Ghz Raspberry Pi 4.
I've tried hooking up a Behringer UMC404HD USB audio device to the Raspberry Pi, but I couldn't go below 128 samples for the buffer size, (qjackctl would balk if I tried), and it had roughly 5 ms more delay overall. Tomorrow I'll try using a FocusRite Scarlett 4i4, which if using this on a desktop PC is any indication, I might be able to get it to run with a sample size of 64, and thus I expect to see the same overall delay times as the PiSound. But will it be as rock solid?
It's my belief that using an I2S connection from Pi to PiSound is what gives this setup its very stable, rock solid performance. That, and using an AWS server instead of my own.
Also, later I am going to test with even lower sample buffer sizes, like 32 or 16. I don't expect these to work, but it's worth a try. I learned long ago never to assume anything.
NOTE: One problem with using the PiSound as your audio device: It has a single 1/4" input jack with guitar-like levels and impedance. So if you want to use a low-impedance mic with XLR connections, you'll have to get an adapter. And if that mic requires phantom power, you'll have to provide that somehow. In my tests with an Audio Technica condenser mic on my fiddle, I routed the mic through a ART tube pre-amp. This supplied the conversion to high impedance, guitar-like line levels, and gave me a 1/4" jack output, and also conveniently supplied the 48V phantom power I needed.
UPDATE: I was able to get a Scarlett 4i4 3rd generation USB device to work on the Raspberry Pi. I was able to use a 64 sample buffer, and I achieved the same good performance as with the PiSound hat (16 ms ping, 25 ms overall). I've only run it for ten minutes, but it appeared to settle down to a stable connection with no dropouts. This means you could just use an ordinary Raspberry Pi 4 (say the 2GB) version, with an ordinary Raspian OS, and then a Scarlett, and you'd get good, stable performance assuming a good internet connection.
This test implies a lower priced Scarlett 2i2 would also work well on the Raspberry Pi. The Scarlett 2i2 is roughly the same price as the PiSound hat. However, the Scarlett has two inputs (XLR or guitar) whereas the PiSound only has a guitar-like input. However, the PiSound has in/out midi ports if that were to prove useful. On the Scarlett line, you have to go to at least a 4i4 to get 5 pin Midi. (Though there's nothing stoppping you from using USB midi on the Raspberry Pi.
One scenario where using the PiSound makes sense is if you just are playing guitar or something with a 1/4" high impedance input. Then, since the PiSound hat sits on top of the Raspberry Pi and can be placed in a compact case, you'd have a more compact unit than having an external audio device to deal with. Also, if you wanted to have, say, a midi keyboard running some kind of synth on the Pi, that would be possible thru either the 5 pin Midi In port, or via USB midi. My limited testing says the 5 pin MIdi port, while 1 ms slower in latency, might have less jitter, but don't quote me on that. Thru my own testing, I think the Rpi 4 can keep up as a lightweight keyboard synthesizer -- at least my own tests using custom drum software I'm developing would suggest that.
Last edit: Bryan Flamig 2020-08-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Update from yesterday: I got the Behringer UMC404HD working on the Rpi 4 with a buffer size of 64 samples. Don't know why I couldn't do that before. Operator error I guess. So, like the Scarlett, I end up with a latency of ping + 10 ms (16 ms + 10 ms = 26 ms in my case).
I can also get the same performance on my fully loaded desktop (3.5 GHz, 32 GB ram). Up until now, it was always 8 - 10 ms slower than my best performances on the Raspberry Pi 4. However, I went and turned off automatic Windows updating, and also turned off "Selective USB Suspend" in the Advanced settings of the Plan settings of the "Power & Sleep" settings on Windows 10. And now after things settling down I get ping + 10 ms latency with the Behringer. I could go even further and turn off the auto-disable power for each USB device on my system in Device Manager, but I decided that was too much trouble. This is a general purpose computer, not a dedicated Jamulus client.
My desktop has three USB audio interfaces attached (a Scarlett 4i4, a Behringer UMC 404HD, and an old non-ASIO, high latency external Creative Sound Blaster that records and plays back digitized vinyl record recordings. I don't use it for real-time stuff.
The fact that I can have all these audio devices hanging out, plus numerous old-school hard-drives, SSD drives, two monitors, you name it, and still get the processing latency down to just ping + 10 ms is interesting, even with various browser windows open, blah, blah, blah -- pretty much everything you shouldn't do when doing real-time audio. I even have virus checking is still running in the background, waiting to thwart me at any moment.
But no matter, I'll be using Jamulus on the Rasperberry Pi a lot, because it has nothing else to do, and will be stable and consistent for that task.
This was all a very interesting exercise to set what various setups can do.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for this write-up Bryan, useful info for anyone building a Pi client, which I'll likely try soon.
I wonder how hard it would be to setup a headless client that auto-connected to the same server every time you booted it up? That would be great for some of our band members that loathe technology and hate setting up there gear on Windows all the time.
Cheers!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting that you got the Pi4 running as a client. For me I have a Pi4 that I would like to run as a server. The reason for this is so that who ever is the drummer can run the server with the least latency. I bought the Pi4 when I wanted to monitor the 3D printer remotely but with Covid that kind of left it sitting idle. It was easy to setup the Pi for the printer as they had the NOB image that you just created on a SD card and ran. It would be great to have the same for Jamulus. The Pi4 sure runs low latency with its DDR4 memory. Wonder how many clients the Pi4 server could support. Anyway I am looking into Jamulus for my daughters high school band. Currently running the client on a Windows 10 PC stick at about 10ms machine latency but found a cheaper Windows 10 for $120 with its own gig lan connection DDR4 memory and 3 USB ports = will see how it goes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just wanted to share my experience on using Jamulus on a Raspberry Pi 4 (4 GB version) with the PiSound Hat. (https://www.blokas.io/pisound/)
This hat is a high quality, low latency ADC/DAC board that has 1/4" jack input, 5 pin midi input, and 1/4" jack output. It uses the I2S bus for superior (compared to USB anyway) communication with the Raspberry Pi. It comes with an optional PatchBox OS that is based on the Raspian OS (a variant of Debian) that has some things pre-configured for you. PatchBox OS also uses a real-time kernel, but it works fine with just the regular Raspberry Pi kernel as well.
I installed Jamulus on this machine, and have used it both as a server and a client. Now as a server, you don't need the PiSound hat, so this post will discuss the experience of using the Rpi in client mode, with the PiSound as my audio input/output device.
Basically, the PiSound shows up as an audio device to ALSA, and is fully compatible with Jack. Now, I'm not an expert at all with Linux audio, so I'm sure there are better ways to set it up than what I ended up doing:
In my tests, for a Jamulus server I set up an Amazon AWS EC2 server (t3.micro instance) in the LA Zone of the Oregon region. I set it up there because I'm located in Phoenix, and this gave me the closest connection to an AWS server that I could get. With Jamulus running on the Raspberry Pi/PiSound, I get a stable ping time of 16 ms, and an overall delay of 25 ms. That's pretty darn good!
The thing is, with the Raspberry Pi/PiSound, the Jamulus connection is ROCK SOLID. It rarely varies from these times. So far, I've been able to test it with three other musicians (for four in total), and on my end, after several hours of jamming, I never had a single xrun. The auto-jitter-buffer had settings of 2 for local, and 2 for server. The jitter buffer settings rarely varied from these amounts after settling in.
The other musicians said my fiddle was coming across clear. Their instruments were clear at times, warbled at other times, but not intolerable. These other musicians don't necessarily have the best audio devices or the best internet connections. I forgot to mention I'm running COX Gigablast, which means a fast, stable, fiber optic line. The other musicians, located in other parts of Phoenix, are using slower, more conventional COX connections, and were reporting 20-25 ms ping, and their overall delays were in the 40-50 ms range. Some were using a Mackie mixer interface, some were using lowly Behringer UM2 devices. Compared to these, my Raspberry Pi client was roughly 15 - 35 ms faster not including the ping times.
I have to say I'm impressed with this set up. My Windows desktop Jamulus setup is just as fast, with the same amount of delay, but it has occasional dropouts, so it's not as good, even though it runs at 3.5 Ghz. It's also fully loaded with stuff, including many old-school hard drives. Having a machine dedicated to Jamulus, with little on it, really helps, even if it's a lowly 1.5 Ghz Raspberry Pi 4.
I've tried hooking up a Behringer UMC404HD USB audio device to the Raspberry Pi, but I couldn't go below 128 samples for the buffer size, (qjackctl would balk if I tried), and it had roughly 5 ms more delay overall. Tomorrow I'll try using a FocusRite Scarlett 4i4, which if using this on a desktop PC is any indication, I might be able to get it to run with a sample size of 64, and thus I expect to see the same overall delay times as the PiSound. But will it be as rock solid?
It's my belief that using an I2S connection from Pi to PiSound is what gives this setup its very stable, rock solid performance. That, and using an AWS server instead of my own.
Also, later I am going to test with even lower sample buffer sizes, like 32 or 16. I don't expect these to work, but it's worth a try. I learned long ago never to assume anything.
NOTE: One problem with using the PiSound as your audio device: It has a single 1/4" input jack with guitar-like levels and impedance. So if you want to use a low-impedance mic with XLR connections, you'll have to get an adapter. And if that mic requires phantom power, you'll have to provide that somehow. In my tests with an Audio Technica condenser mic on my fiddle, I routed the mic through a ART tube pre-amp. This supplied the conversion to high impedance, guitar-like line levels, and gave me a 1/4" jack output, and also conveniently supplied the 48V phantom power I needed.
UPDATE: I was able to get a Scarlett 4i4 3rd generation USB device to work on the Raspberry Pi. I was able to use a 64 sample buffer, and I achieved the same good performance as with the PiSound hat (16 ms ping, 25 ms overall). I've only run it for ten minutes, but it appeared to settle down to a stable connection with no dropouts. This means you could just use an ordinary Raspberry Pi 4 (say the 2GB) version, with an ordinary Raspian OS, and then a Scarlett, and you'd get good, stable performance assuming a good internet connection.
This test implies a lower priced Scarlett 2i2 would also work well on the Raspberry Pi. The Scarlett 2i2 is roughly the same price as the PiSound hat. However, the Scarlett has two inputs (XLR or guitar) whereas the PiSound only has a guitar-like input. However, the PiSound has in/out midi ports if that were to prove useful. On the Scarlett line, you have to go to at least a 4i4 to get 5 pin Midi. (Though there's nothing stoppping you from using USB midi on the Raspberry Pi.
One scenario where using the PiSound makes sense is if you just are playing guitar or something with a 1/4" high impedance input. Then, since the PiSound hat sits on top of the Raspberry Pi and can be placed in a compact case, you'd have a more compact unit than having an external audio device to deal with. Also, if you wanted to have, say, a midi keyboard running some kind of synth on the Pi, that would be possible thru either the 5 pin Midi In port, or via USB midi. My limited testing says the 5 pin MIdi port, while 1 ms slower in latency, might have less jitter, but don't quote me on that. Thru my own testing, I think the Rpi 4 can keep up as a lightweight keyboard synthesizer -- at least my own tests using custom drum software I'm developing would suggest that.
Last edit: Bryan Flamig 2020-08-18
Update from yesterday: I got the Behringer UMC404HD working on the Rpi 4 with a buffer size of 64 samples. Don't know why I couldn't do that before. Operator error I guess. So, like the Scarlett, I end up with a latency of ping + 10 ms (16 ms + 10 ms = 26 ms in my case).
I can also get the same performance on my fully loaded desktop (3.5 GHz, 32 GB ram). Up until now, it was always 8 - 10 ms slower than my best performances on the Raspberry Pi 4. However, I went and turned off automatic Windows updating, and also turned off "Selective USB Suspend" in the Advanced settings of the Plan settings of the "Power & Sleep" settings on Windows 10. And now after things settling down I get ping + 10 ms latency with the Behringer. I could go even further and turn off the auto-disable power for each USB device on my system in Device Manager, but I decided that was too much trouble. This is a general purpose computer, not a dedicated Jamulus client.
My desktop has three USB audio interfaces attached (a Scarlett 4i4, a Behringer UMC 404HD, and an old non-ASIO, high latency external Creative Sound Blaster that records and plays back digitized vinyl record recordings. I don't use it for real-time stuff.
The fact that I can have all these audio devices hanging out, plus numerous old-school hard-drives, SSD drives, two monitors, you name it, and still get the processing latency down to just ping + 10 ms is interesting, even with various browser windows open, blah, blah, blah -- pretty much everything you shouldn't do when doing real-time audio. I even have virus checking is still running in the background, waiting to thwart me at any moment.
But no matter, I'll be using Jamulus on the Rasperberry Pi a lot, because it has nothing else to do, and will be stable and consistent for that task.
This was all a very interesting exercise to set what various setups can do.
Thanks for this write-up Bryan, useful info for anyone building a Pi client, which I'll likely try soon.
I wonder how hard it would be to setup a headless client that auto-connected to the same server every time you booted it up? That would be great for some of our band members that loathe technology and hate setting up there gear on Windows all the time.
Cheers!
I am currently trying just that on a Raspberry Pi 3 with a USB microphone for non-tech members of a choir in the current lockdown.
Interesting that you got the Pi4 running as a client. For me I have a Pi4 that I would like to run as a server. The reason for this is so that who ever is the drummer can run the server with the least latency. I bought the Pi4 when I wanted to monitor the 3D printer remotely but with Covid that kind of left it sitting idle. It was easy to setup the Pi for the printer as they had the NOB image that you just created on a SD card and ran. It would be great to have the same for Jamulus. The Pi4 sure runs low latency with its DDR4 memory. Wonder how many clients the Pi4 server could support. Anyway I am looking into Jamulus for my daughters high school band. Currently running the client on a Windows 10 PC stick at about 10ms machine latency but found a cheaper Windows 10 for $120 with its own gig lan connection DDR4 memory and 3 USB ports = will see how it goes.