The audient Evo 4 is a great little low price device that works really well. Also has a handy auto gain function to avoid nasty digital clipping https://amzn.to/2BwKJ6j
Last edit: Alex Buckland 2020-06-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No issues at all. Audient spend alot of time working on improving performance in their drivers. What you get with the EVO 4 is a trickle down of what they work on for their bigger products. Driver install guide can be found here https://evo.audio/driver-installation/
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have used the Evo 4 and Scarlett 2i2, both natural options on the lower end of the budget. Caveat - the Evo has been tested on Mac and linux, the Scarlett on Mac, Win and linux.
Both have worked fine. The hardware knobs on the 2i2 are probably preferable for some musicians - really no UI to get used to. The Evo's simpler controls actually need some practice.
Sound-wise I marginally prefer the Evo 4, esp. because my headphone (Senn HD600) is a bit fussy and very revealing.
There is one characteristic of the Evo 4 that may be a deal-breaker for some users - the headphone out mutes the monitor output. You cannot have output simultaeously to both. Where I live the Evo 4 is about 20-25% cheaper than the 2i2, so local pricing is obviously another factor to consider.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Although it is not a proper audio interface for musicians, this little and super-cheap device could be useful if you are on a strict budget. At least on a Mac, it works with Jamulus. It seems to have specific drivers for Windows, but I did not try.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was not able to find an ASIO driver for the LEAGY device, therefore I don't think it would be useful on Windows. It appears to be yet another device that only works with ASIO4all.
The price looks good, and you are right that it should work fine on Mac, but I suspect it works about as good as the built-in audio, which also works fine on Mac.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I saw drivers for Windows but I did not check which kind - thanks for the info. Regarding Mac, builtin audio is okay, however some old Mac, like the one of our drummer (MacBook Airs mid 2013), has a jack socket that can be alternatively used as output or input, not together. Furthermore, this device provides two inputs, one line and one mic level, and this may be useful (although we have yet to try the combination).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I suggest that the Hardware page should mention USB microphones. We've found that decent USB microphones provide acceptable quality and latency for singers and acoustic intruments such as recorders, bypassing built-in mics and sound cards. Economical and platform-independent. No drivers needed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bob makes a very good point! I can definitely recommend the Blue Yeti mic's. I was a sound engineer for many years and am really suprised at the quality of them. The yeti also has headphone output jack built in (essential for great Jamulus session), and you can control the gain and pickup pattern too. Its really awesome. Can find it here https://amzn.to/3eGUtJJ
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Alex is right about the Blue Yeti. I am pretty sure I added it to the recommended hardware page, but with a couple of notes:
1 - it works great on mac (there is a checkbox to turn off local monitoring)
2 - it works ok on windows with ASIO4all. a bit more latency than on mac. you can turn off the local monitoring if you go deep into the settings
3 - latency on linux is good but i did not find any way to turn off the local monitoring.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Somewhere in the documentation you will read the "Number 1 rule of Jamulus, don't listen to your local signal - only listen to your signal as it comes back from the server".
With the Blue Yeti microphone, by default the local signal (the input to the microphone) comes directly out of the headphone jack. Blue calls this "zero-latency" monitoring.
Unfortunately, if you hear your signal with zero latency, and the rest of your band with 40ms latency, then you won't be able to do a good job of playing in time with the others.
So you have to turn off this feature.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have played around a bit with alsa_in, alsa_out, and qjackctl and I can now get my Blue Yeti to feed Jamulus for input and get output from Jamulus on my system's headphone jack. The page at https://jamulus.io/wiki/Sound-Devices currently says, "Latency on Linux is good but I did not find any way to turn off the local monitoring."; if someone wants me to pass along what I did I'd be happy to do so. Note that I have not myself found a way to plug headphones into the Yeti and not be in monitor mode; I have simply "jacked" around it. It's a manual process, and looks like this on my particular system:
$ cat /proc/asound/cards
0[C615 ]: USB-Audio - HD Webcam C615
HD Webcam C615 at usb-0000:00:1d.0-1.7, high speed
1[Microphone ]: USB-Audio - Yeti Stereo Microphone
Blue Microphones Yeti Stereo Microphone at usb-0000:00:1a.0-1.4, full speed
2[PCH ]: HDA-Intel - HDA Intel PCH
HDA Intel PCH at 0xe1660000 irq 37
$ alsa_in -d hw:Microphone # Connects the Yeti to alsa
$ alsa_out -d hw:PCH # Connects the onboard headphone jack to alsa
$ # fire up Jamulus
$ qjackctl # to patch together things from alsa <-> Jamulus; see attached screenshot
I happen to be running LMDE4 on an old Dell Optiplex 990.
Sorry if this is considered thread-revivification; if there's a better place for it please let me know.
It's a pretty old thread but it is good you mentioned it. The known-working hardware page is a lot harder to find now, and harder for us to edit too.
The Blue Yeti (and the smaller Yeti Nano) can have their local monitoring turned off by running alsamixer and toggling the control (i think it was with the 'm' key)
The Yeti Nano actually has a (hidden) hardware switch for it - you hold down the 'pattern' button for 5 seconds.
So both microphones are completely good on linux , with headphones plugged into them.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The Google finds all pages. The alsamix "m" solution seems to work perfectly, thanks.
It does seem that even when using alsamix to turn off monitoring, I still have to run alsa_in and alsa_out along with qjackctl to get things plugged into Jamulus with my Yeti. There must be "something simple" I'm missing, but I've found that sound is hard no matter what the task or platform. Doesn't help that my system has the Yeti, the onboard sound hardware, and a recently added Logitech camera that also has a mic. Yeah, it's complicated.
"The "known-working hardware page is... harder for us to edit too." That's sad; would you mind pointing me to the thread explaining why editing a wiki should be hard? Curation is hard(tm), but actually editing the things is the reason for fame, such as it is.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We've used the Samson Meteorite and the Blue Snowball mics. It's not so much particular models that need highlighting but the approach of using a USB microphone rather than an expensive audio interface and a microphone for purely acoustic sources.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see, although using the computer's built-in audio interface isn't always the best idea as latency tends to be higher than if you use an external interface (as punshon notes above in fact). Your milage may vary of course, but there's a reason why the hardware page is full of audio interfaces :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A USB microphone does analogue-to-digital conversion itself, without using the computer's built-in audio interface. It's like a microphone with an external sound card bundled in. I don't know why ASIO4all was needed. As long as the sampling rate it implements is 48 khz (or even 44.1 we've found), a USB microphone should work with Jamulus with acceptable latency.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not technically knowlegable enough about the exact relationship between the various components of the audio stack to know why Jamulus needs an ASIO-compatible driver to work on Windows (I think it's something to do with the sound subsystem it uses on that platform). But if an audio interface simply passes the digital signal from a USB mic to Jamulus then that may well mean a lower latancy than using an analogue mic with it.
Anyway, I've updated the hardware list and mentioned USB mics on the Getting Started page.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
While I understand that an audio interface helps to get better sound, I don't understand why an audio interface would reduce latency. Why would the internal mic and internal headphone jack create more latency then an external device? It would seem if anything using the internal mic and internal headphone jack would reduce latency.
Thank you in advacne for your patience with this question.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The short answer is that for analog audio, low latency is easy. But for digital audio, low latency requires the audio interface to really work hard. Most onboard audio isn't capable of doing it.
Kind regards,
John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think it's essentially a question of component cost. Most PCs don't sell on features like audio latency becuase most users don't know or care about that if all they are doing is Zoom calls or listening to MP3s. So manufacturers will choose cheap components for this to keep their costs down. Dedicated auto interfaces do sell on latency speed, so their price reflects the quality of the circuits in them.
Last edit: Gilgongo 2020-07-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for this information, I am finding the latency of the mic and
headphone out on my Apple laptop to be almost identical to the latency of
my external Focusrite audio interface, though I understand not everyone
will have the same experience.
My issue is creating a server that others can access that has a low ping
time.
John - did you make a video of how to create a server?
I think it's essentially a question of component cost. Most PCs don't sell
on features like audio latency, so manufactutuers will choose cheap
components for this to keep costs down. Dedicated auto interfaces do sell
on latency speed, so their price reflects the quality of the circuits in
them.
The audient Evo 4 is a great little low price device that works really well. Also has a handy auto gain function to avoid nasty digital clipping https://amzn.to/2BwKJ6j
Last edit: Alex Buckland 2020-06-04
Thanks For the post, it looks like it has a native ASIO driver, is that correct? Any latency issues?
No issues at all. Audient spend alot of time working on improving performance in their drivers. What you get with the EVO 4 is a trickle down of what they work on for their bigger products. Driver install guide can be found here https://evo.audio/driver-installation/
I have used the Evo 4 and Scarlett 2i2, both natural options on the lower end of the budget. Caveat - the Evo has been tested on Mac and linux, the Scarlett on Mac, Win and linux.
Both have worked fine. The hardware knobs on the 2i2 are probably preferable for some musicians - really no UI to get used to. The Evo's simpler controls actually need some practice.
Sound-wise I marginally prefer the Evo 4, esp. because my headphone (Senn HD600) is a bit fussy and very revealing.
There is one characteristic of the Evo 4 that may be a deal-breaker for some users - the headphone out mutes the monitor output. You cannot have output simultaeously to both. Where I live the Evo 4 is about 20-25% cheaper than the 2i2, so local pricing is obviously another factor to consider.
Although it is not a proper audio interface for musicians, this little and super-cheap device could be useful if you are on a strict budget. At least on a Mac, it works with Jamulus. It seems to have specific drivers for Windows, but I did not try.
I was not able to find an ASIO driver for the LEAGY device, therefore I don't think it would be useful on Windows. It appears to be yet another device that only works with ASIO4all.
The price looks good, and you are right that it should work fine on Mac, but I suspect it works about as good as the built-in audio, which also works fine on Mac.
I saw drivers for Windows but I did not check which kind - thanks for the info. Regarding Mac, builtin audio is okay, however some old Mac, like the one of our drummer (MacBook Airs mid 2013), has a jack socket that can be alternatively used as output or input, not together. Furthermore, this device provides two inputs, one line and one mic level, and this may be useful (although we have yet to try the combination).
I suggest that the Hardware page should mention USB microphones. We've found that decent USB microphones provide acceptable quality and latency for singers and acoustic intruments such as recorders, bypassing built-in mics and sound cards. Economical and platform-independent. No drivers needed.
OK sure - can you tell me which model(s) you've found that rock?
Bob makes a very good point! I can definitely recommend the Blue Yeti mic's. I was a sound engineer for many years and am really suprised at the quality of them. The yeti also has headphone output jack built in (essential for great Jamulus session), and you can control the gain and pickup pattern too. Its really awesome. Can find it here https://amzn.to/3eGUtJJ
Alex is right about the Blue Yeti. I am pretty sure I added it to the recommended hardware page, but with a couple of notes:
1 - it works great on mac (there is a checkbox to turn off local monitoring)
2 - it works ok on windows with ASIO4all. a bit more latency than on mac. you can turn off the local monitoring if you go deep into the settings
3 - latency on linux is good but i did not find any way to turn off the local monitoring.
Forgive my ignorance, but what does turning off local monitoring on a microphone do? I'll add your reccommendation to the hardware page.
Somewhere in the documentation you will read the "Number 1 rule of Jamulus, don't listen to your local signal - only listen to your signal as it comes back from the server".
With the Blue Yeti microphone, by default the local signal (the input to the microphone) comes directly out of the headphone jack. Blue calls this "zero-latency" monitoring.
Unfortunately, if you hear your signal with zero latency, and the rest of your band with 40ms latency, then you won't be able to do a good job of playing in time with the others.
So you have to turn off this feature.
Oh OK, I didn't realise the mic had a headphone jack. I assumed you'd use the computer's output for that.
I have played around a bit with alsa_in, alsa_out, and qjackctl and I can now get my Blue Yeti to feed Jamulus for input and get output from Jamulus on my system's headphone jack. The page at https://jamulus.io/wiki/Sound-Devices currently says, "Latency on Linux is good but I did not find any way to turn off the local monitoring."; if someone wants me to pass along what I did I'd be happy to do so. Note that I have not myself found a way to plug headphones into the Yeti and not be in monitor mode; I have simply "jacked" around it. It's a manual process, and looks like this on my particular system:
I happen to be running LMDE4 on an old Dell Optiplex 990.
Sorry if this is considered thread-revivification; if there's a better place for it please let me know.
Last edit: Del Merritt 2020-12-23
It's a pretty old thread but it is good you mentioned it. The known-working hardware page is a lot harder to find now, and harder for us to edit too.
The Blue Yeti (and the smaller Yeti Nano) can have their local monitoring turned off by running alsamixer and toggling the control (i think it was with the 'm' key)
The Yeti Nano actually has a (hidden) hardware switch for it - you hold down the 'pattern' button for 5 seconds.
So both microphones are completely good on linux , with headphones plugged into them.
The Google finds all pages. The alsamix "m" solution seems to work perfectly, thanks.
It does seem that even when using alsamix to turn off monitoring, I still have to run alsa_in and alsa_out along with qjackctl to get things plugged into Jamulus with my Yeti. There must be "something simple" I'm missing, but I've found that sound is hard no matter what the task or platform. Doesn't help that my system has the Yeti, the onboard sound hardware, and a recently added Logitech camera that also has a mic. Yeah, it's complicated.
"The "known-working hardware page is... harder for us to edit too." That's sad; would you mind pointing me to the thread explaining why editing a wiki should be hard? Curation is hard(tm), but actually editing the things is the reason for fame, such as it is.
We've used the Samson Meteorite and the Blue Snowball mics. It's not so much particular models that need highlighting but the approach of using a USB microphone rather than an expensive audio interface and a microphone for purely acoustic sources.
I see, although using the computer's built-in audio interface isn't always the best idea as latency tends to be higher than if you use an external interface (as punshon notes above in fact). Your milage may vary of course, but there's a reason why the hardware page is full of audio interfaces :-)
A USB microphone does analogue-to-digital conversion itself, without using the computer's built-in audio interface. It's like a microphone with an external sound card bundled in. I don't know why ASIO4all was needed. As long as the sampling rate it implements is 48 khz (or even 44.1 we've found), a USB microphone should work with Jamulus with acceptable latency.
Ah, interesting.
I'm not technically knowlegable enough about the exact relationship between the various components of the audio stack to know why Jamulus needs an ASIO-compatible driver to work on Windows (I think it's something to do with the sound subsystem it uses on that platform). But if an audio interface simply passes the digital signal from a USB mic to Jamulus then that may well mean a lower latancy than using an analogue mic with it.
Anyway, I've updated the hardware list and mentioned USB mics on the Getting Started page.
While I understand that an audio interface helps to get better sound, I don't understand why an audio interface would reduce latency. Why would the internal mic and internal headphone jack create more latency then an external device? It would seem if anything using the internal mic and internal headphone jack would reduce latency.
Thank you in advacne for your patience with this question.
Hi Scott,
I addressed this in my video, Jamulus Tech Essentials 1
https://archive.org/details/jlp_jamulus_tech_essentials_1
The short answer is that for analog audio, low latency is easy. But for digital audio, low latency requires the audio interface to really work hard. Most onboard audio isn't capable of doing it.
Kind regards,
John
I think it's essentially a question of component cost. Most PCs don't sell on features like audio latency becuase most users don't know or care about that if all they are doing is Zoom calls or listening to MP3s. So manufacturers will choose cheap components for this to keep their costs down. Dedicated auto interfaces do sell on latency speed, so their price reflects the quality of the circuits in them.
Last edit: Gilgongo 2020-07-08
Thank you for this information, I am finding the latency of the mic and
headphone out on my Apple laptop to be almost identical to the latency of
my external Focusrite audio interface, though I understand not everyone
will have the same experience.
My issue is creating a server that others can access that has a low ping
time.
John - did you make a video of how to create a server?
Thank you,
Scott Roewe
On Wed, Jul 8, 2020 at 8:35 AM Gilgongo gilgongojones@users.sourceforge.net
wrote:
--
Music Teacher
New Roads High School
Music Director
Unitarian Universalist Church of Santa Clarita