I'm helping someone to get started with Jamulus (latest version) on Slackware (relatively powerful notebook).
Both on fibre connections with LAN cable to the router.
He has a zoom H4n as audio interface which is parameterized to 48kHz, 2 periods, 128 samples in Qjackctl = 5.33ms delay shown in Jamulus.
We connected to different servers with ping times between 15 and 18ms for both of us.
On my Raspberry Pi 4B8G with Ubuntu Mate, I have an overall delay of 35ms which is what I expect.
However he has an overall delay of between 85 and 100ms, depending on the settings of audio quality and manual stream buffer settings, so playing is impossible.
The buffer values settle at about 10..20% both in auto mode, resulting in an overall delay of 100ms or more.
By manually reducing them to below 10% this can be reduced to 85ms in the best case.
We cannot find out the source of this huge delay, can anyone help?
I don't know Slackware at all and I appreciate any hint.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When trying to isolate an issue like this, it's always worth "base-lining" the delay time by starting a server on that machine, connecting the client to 127.0.0.1 and noting the overall delay in settings. This should be your "background" delay time. Then it's worth doing a quick test booting the machine using Jamulus OS and doing the same to compare. If the results are similar, then that should at least rule out any software/driver issues on the local machine.
Props to your friend for using Slackware though. Hard core.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am not a Linux expert, but I play every week with someone using a Zoom H4n as their audio interface (on an old MAC). It has been so long now that I have forgotten what they said they had for a delay, it has never been noticeable. In any case the problem is not the H4n.
Could it be that the laptop is going into a power-down mode?
Let's hope that a Linux guru speaks up.
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I play every week with someone using a Zoom H4n as their audio interface (on an old MAC). It has been so long now that I have forgotten what they said they had for a delay, it has never been noticeable.
I am somewhat skeptical here since I read about Zoom H4n latency being not useful for some applications, and my own (quite older) Zoom H2 also had delays in a ballpark where I considered it pointless giving it to others. Of course the real killer misfeature with the H2 was that you could not disable hardware monitoring: if you were using playback and recording at the same time, the recording would always bleed through into the playback.
It's also a bit tricky to pin down "noticeable delay" in a session. The person itself may experience it when not muting their mixer, but other than that it exposes itself mainly in a tendency of the group to slow down. Once people learn to "compensate" for the perceived tardiness of others, delays become less tangible. There are players of large organs with pneumatic propagation of key presses: either when playing alone or in concert with other musicians, they have more to compensate for than what we see in typical soundcard setups.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem seems more into slackware and any specific parameters of ALSA, PULSEAUDIO or JACK that might be hidden there, or anything secret hidden in the signal chain between them.
He has tried it on another machine in his home, running Slackwar too, same problem.
He has tried with the internal sound card of the laptop, latency is the same.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If he's running Slackware comfortably, it would be worth a try to check out JamulusOS (a bootable Linux distribution with preinstalled Jamulus and suitable setup around it). If that happens to run better, the problem should be one of Slackware. If not, at least it helps focusing the search.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One thought: some things in Jamulus are done with timers. If timer granularity with your Slackware system is different to what Jamulus expects, maybe this causes problems? Maybe check out what kernel compilations/installation options are there with regard to timers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like to thank you who have taken the time to think about it.
The problem was solved by installing the pulseaudio-jack package which had been missing (obviously not automatically installed with jack in that distro).
This may have led to the 128samples/2 periods setting in qjackctl not becoming effective.
Everything works like a charm now, even on wifi if in close proximity of the router.
Good New Year!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Everything works like a charm now, even on wifi if in close proximity of the router.
Hi Jean,
Beware of wifi. It may appear to be good for minutes, but then for many seconds be unintelligible. Cable is really the only way to go, even if the wifi adherents say they have the worlds best, fastest, etc. We had one guy in our orchestra on wifi, who maintained that his wifi couldn't be the cause of the intermittent messes were were hearing. That until someone lent him a long cable. Then the messes were gone.
What delays are you seeing with your H4n now?
Happy New Year to all!
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks DonC. We'll bear in mind what you say about wifi.
The overall delay with the H4n was 32ms (12ms ping) on Lan cable and 35ms on wifi from central France to a server in London.
So the wifi was adding 3ms of latency (close proximity of the router, all other wifi participants switched off, of course).
The H4n was slightly better than the laptop's internal sound card but I don't have the exact details.
Me myself, I tested a 7€ USB soundcard on my raspi and the latency is about the same.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What WIFi really adds is not extra latency, but (much) extra variability (jitter) in latency. Variability in latency disturbs much more than few stable ms. The channel is shared, so you have to be sure all others are really switched off (in my home this means 3 phones, 4 iPads, another computer, Amazon TV Stick, Google Chromecast, ... ). Plus, you have to be sure no neighbours are set on the same channel.
If you are in "close proximity of the router", there is no reason for not using a cable. If you are far, I could understand - I have solved this with powerline (although for few people the results are not as good as cable, with my relatively recent electric wiring, ping jitter is drastically lower).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear all, thank you so much for your appreciated enlightenment. I will take it into account when giving assistance to musicians. But I'll consider every case individually.
I don't have the time to investigate in such depth all that stuff about wifi. The only criterion by which I am able to judge about wifi is the audio quality that I can obtain with it. If I understand Jamulus right, any network jitter translates to an increase of the buffer sizes in Jamulus, which in turn results in more "overall delay", too, implemented to change with inertia. But, as said, in our particular situation, this amounted to just 3ms (router at 3m, no other devices), no crackle at all.
Indeed, there are reasons not to ban wifi completely. The router may be at the ceiling of the basement just under the music room or in the neighbouring room and you just can't ask the musician to drill holes through their walls and floors until they feel that necessity themselves, motivated by the desire to improve musical experience.
Especially with classical musicians, there is a psychological phenomenon which I call "the Jamulus effect": You tell brilliant violinists in lockdown about Jamulus, they are just exalted and swear they'll install it the same night, then they read the website with all those "expensive" requirements and they never reply to any message again.
So to get people into the boat of this completely new experience, it seems essential to me to keep the entry conditions as low as possible, to meet them where they are, whenever possible.
And that is very often: wifi, internal soundcard and mic, and cheap in-ear headphones.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So to get people into the boat of this completely new experience, it seems essential to me to keep the entry conditions as low as possible,
You are right, I have seen the same trying to get the orchestra I play with onboard. I almost had to twist the arm of our director to get him to try it out with me once. But once they try all is good, unfortunately only one at a time. They have all started simply with their MAC, wifi connection and headphones of some sort. But already during the second rehearsal they start talking of the occasional noise, crackling, etc. Then you need to be ready with answers.
That starts with a cabled connection. In the meantime we are all cabled and have no sound quality issues, many have added better headphones. Now some are talking about an external interface and a good microphone.
As you say, the problem is the first step. After they have played together once all are happy they tried.
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
They have all started simply with their MAC, wifi connection and headphones of some sort.
I'm the technical support person in our accordion orchestra (not overly surprising). We have a diversity of systems. Of little surprise is that I am the only one running Linux (and responsible for the server). At our last live rehearsal (lockdown was already announced to start a few days later) I asked whether I should look for options regarding virtual rehearsal and everyone was positive.
A few weeks later I thought the project would be dead in the water due to the response. I got everyone together using a Jitsi video conference session in the browser (basically, you take https://meet.jit.si/WhateverYouCanThinkOf and everyone using the same link enters the same session). That got enough people to realise that meeting virtually was not without merit. So I started driving around with equipment (and of course masked up) and set people up with soundcards and microphones, or with microphone and any contraption making for a better preamp than whatever they had (old mixer, soundcard with dead digital circuitry but with plugin connectors still in the purely analog section), catering for the worst problems with latency and extensive hiss.
Now much of my old hardware is Firewire, and one member of the orchestra is running a Mac mini she has little clue about, with a built-in microphone (I suspect it to be in the monitor rather than the main computer). The monitor serves as a hub of some sort and also has Firewire.
That would have been one fertile playground. Except that her sound and connection quality is such that I never had a reason to drop by yet: other people were more pressing. Sure, by now her hiss level is among the stronger ones, but it's still not a major issue: the built-in microphones of other people were much more important to replace. And I've run out of microphones to distribute.
So judging from my experience, if you are living in Mac country (I am assuming that with MAC you don't mean network addresses), you likely already have an advantage in selling Jamulus. Though possibly things other than a Mac mini may not have as acceptable a sound quality out of the box: no idea.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I too agree: at least to begin, let's people start with what they have, but then give them indications on how to enhance their experience. When involving others, you will soon find that your WiFi situation is rarely replicable, in particular if the router is far from the music room (it's not only more latency: on WiFi you may temporarily reach ping of hundreds of ms ).
My band adopted a variety of compromises, because at the end our expectation is "just" to be able to play together, quality helps but is secundary. We all started with WiFi, but the first attempts were not particularly good.
The solution I found for me and for our keyboard player is using powerline adapters, which avoid holes in walls or temporary cables (I bought one, 20m long, but it interferes, ehm, with kids activities... ;) ). The keyboard player spent months telling that his MESH technology was superior, but the first attempt with powerline totally bought him. We still have one guitar player convinced that WiFi does not make a difference, but he is also the one with (way) more crackling than others. Including one singer and the other guitarists that do not have fixed internet connection, and use the cell phone hotspot to connect (via USB, not via WiFi). They have larger overall delay, but very stable. Regarding interfaces, we have one singer via the internal mic of his laptop (pitfall: more external noise, including his cat), and the other one with a cheap Trust USB microphone. The drummer has an old Mac with a sound check that can be only used as input OR output, not both together, so he is using a super-cheap soundcard for connecting his electronic drums (pitfall: he has to switch to the internal mic to speak with us).
As you see, some of our solutions are among the deprecated ones, however we know it and we know their pitfalls and how to upgrade. Asking the two without fixed internet to buy Internet is not possible; however, while with more delay, their sound quality is not bad at all. We are working with the guitar player - likely we will send him an anonymous gift :) .
Last edit: Vincenzo 2021-01-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm helping someone to get started with Jamulus (latest version) on Slackware (relatively powerful notebook).
Both on fibre connections with LAN cable to the router.
He has a zoom H4n as audio interface which is parameterized to 48kHz, 2 periods, 128 samples in Qjackctl = 5.33ms delay shown in Jamulus.
We connected to different servers with ping times between 15 and 18ms for both of us.
On my Raspberry Pi 4B8G with Ubuntu Mate, I have an overall delay of 35ms which is what I expect.
However he has an overall delay of between 85 and 100ms, depending on the settings of audio quality and manual stream buffer settings, so playing is impossible.
The buffer values settle at about 10..20% both in auto mode, resulting in an overall delay of 100ms or more.
By manually reducing them to below 10% this can be reduced to 85ms in the best case.
We cannot find out the source of this huge delay, can anyone help?
I don't know Slackware at all and I appreciate any hint.
When trying to isolate an issue like this, it's always worth "base-lining" the delay time by starting a server on that machine, connecting the client to 127.0.0.1 and noting the overall delay in settings. This should be your "background" delay time. Then it's worth doing a quick test booting the machine using Jamulus OS and doing the same to compare. If the results are similar, then that should at least rule out any software/driver issues on the local machine.
Props to your friend for using Slackware though. Hard core.
I am not a Linux expert, but I play every week with someone using a Zoom H4n as their audio interface (on an old MAC). It has been so long now that I have forgotten what they said they had for a delay, it has never been noticeable. In any case the problem is not the H4n.
Could it be that the laptop is going into a power-down mode?
Let's hope that a Linux guru speaks up.
Don
I am somewhat skeptical here since I read about Zoom H4n latency being not useful for some applications, and my own (quite older) Zoom H2 also had delays in a ballpark where I considered it pointless giving it to others. Of course the real killer misfeature with the H2 was that you could not disable hardware monitoring: if you were using playback and recording at the same time, the recording would always bleed through into the playback.
It's also a bit tricky to pin down "noticeable delay" in a session. The person itself may experience it when not muting their mixer, but other than that it exposes itself mainly in a tendency of the group to slow down. Once people learn to "compensate" for the perceived tardiness of others, delays become less tangible. There are players of large organs with pneumatic propagation of key presses: either when playing alone or in concert with other musicians, they have more to compensate for than what we see in typical soundcard setups.
The problem seems more into slackware and any specific parameters of ALSA, PULSEAUDIO or JACK that might be hidden there, or anything secret hidden in the signal chain between them.
He has tried it on another machine in his home, running Slackwar too, same problem.
He has tried with the internal sound card of the laptop, latency is the same.
If he's running Slackware comfortably, it would be worth a try to check out JamulusOS (a bootable Linux distribution with preinstalled Jamulus and suitable setup around it). If that happens to run better, the problem should be one of Slackware. If not, at least it helps focusing the search.
One thought: some things in Jamulus are done with timers. If timer granularity with your Slackware system is different to what Jamulus expects, maybe this causes problems? Maybe check out what kernel compilations/installation options are there with regard to timers.
I would like to thank you who have taken the time to think about it.
The problem was solved by installing the pulseaudio-jack package which had been missing (obviously not automatically installed with jack in that distro).
This may have led to the 128samples/2 periods setting in qjackctl not becoming effective.
Everything works like a charm now, even on wifi if in close proximity of the router.
Good New Year!
Everything works like a charm now, even on wifi if in close proximity of the router.Hi Jean,
Beware of wifi. It may appear to be good for minutes, but then for many seconds be unintelligible. Cable is really the only way to go, even if the wifi adherents say they have the worlds best, fastest, etc. We had one guy in our orchestra on wifi, who maintained that his wifi couldn't be the cause of the intermittent messes were were hearing. That until someone lent him a long cable. Then the messes were gone.
What delays are you seeing with your H4n now?
Happy New Year to all!
Don
thanks DonC. We'll bear in mind what you say about wifi.
The overall delay with the H4n was 32ms (12ms ping) on Lan cable and 35ms on wifi from central France to a server in London.
So the wifi was adding 3ms of latency (close proximity of the router, all other wifi participants switched off, of course).
The H4n was slightly better than the laptop's internal sound card but I don't have the exact details.
Me myself, I tested a 7€ USB soundcard on my raspi and the latency is about the same.
What WIFi really adds is not extra latency, but (much) extra variability (jitter) in latency. Variability in latency disturbs much more than few stable ms. The channel is shared, so you have to be sure all others are really switched off (in my home this means 3 phones, 4 iPads, another computer, Amazon TV Stick, Google Chromecast, ... ). Plus, you have to be sure no neighbours are set on the same channel.
If you are in "close proximity of the router", there is no reason for not using a cable. If you are far, I could understand - I have solved this with powerline (although for few people the results are not as good as cable, with my relatively recent electric wiring, ping jitter is drastically lower).
Dear all, thank you so much for your appreciated enlightenment. I will take it into account when giving assistance to musicians. But I'll consider every case individually.
I don't have the time to investigate in such depth all that stuff about wifi. The only criterion by which I am able to judge about wifi is the audio quality that I can obtain with it. If I understand Jamulus right, any network jitter translates to an increase of the buffer sizes in Jamulus, which in turn results in more "overall delay", too, implemented to change with inertia. But, as said, in our particular situation, this amounted to just 3ms (router at 3m, no other devices), no crackle at all.
Indeed, there are reasons not to ban wifi completely. The router may be at the ceiling of the basement just under the music room or in the neighbouring room and you just can't ask the musician to drill holes through their walls and floors until they feel that necessity themselves, motivated by the desire to improve musical experience.
Especially with classical musicians, there is a psychological phenomenon which I call "the Jamulus effect": You tell brilliant violinists in lockdown about Jamulus, they are just exalted and swear they'll install it the same night, then they read the website with all those "expensive" requirements and they never reply to any message again.
So to get people into the boat of this completely new experience, it seems essential to me to keep the entry conditions as low as possible, to meet them where they are, whenever possible.
And that is very often: wifi, internal soundcard and mic, and cheap in-ear headphones.
So to get people into the boat of this completely new experience, it seems essential to me to keep the entry conditions as low as possible,You are right, I have seen the same trying to get the orchestra I play with onboard. I almost had to twist the arm of our director to get him to try it out with me once. But once they try all is good, unfortunately only one at a time. They have all started simply with their MAC, wifi connection and headphones of some sort. But already during the second rehearsal they start talking of the occasional noise, crackling, etc. Then you need to be ready with answers.
That starts with a cabled connection. In the meantime we are all cabled and have no sound quality issues, many have added better headphones. Now some are talking about an external interface and a good microphone.
As you say, the problem is the first step. After they have played together once all are happy they tried.
Don
I'm the technical support person in our accordion orchestra (not overly surprising). We have a diversity of systems. Of little surprise is that I am the only one running Linux (and responsible for the server). At our last live rehearsal (lockdown was already announced to start a few days later) I asked whether I should look for options regarding virtual rehearsal and everyone was positive.
A few weeks later I thought the project would be dead in the water due to the response. I got everyone together using a Jitsi video conference session in the browser (basically, you take https://meet.jit.si/WhateverYouCanThinkOf and everyone using the same link enters the same session). That got enough people to realise that meeting virtually was not without merit. So I started driving around with equipment (and of course masked up) and set people up with soundcards and microphones, or with microphone and any contraption making for a better preamp than whatever they had (old mixer, soundcard with dead digital circuitry but with plugin connectors still in the purely analog section), catering for the worst problems with latency and extensive hiss.
Now much of my old hardware is Firewire, and one member of the orchestra is running a Mac mini she has little clue about, with a built-in microphone (I suspect it to be in the monitor rather than the main computer). The monitor serves as a hub of some sort and also has Firewire.
That would have been one fertile playground. Except that her sound and connection quality is such that I never had a reason to drop by yet: other people were more pressing. Sure, by now her hiss level is among the stronger ones, but it's still not a major issue: the built-in microphones of other people were much more important to replace. And I've run out of microphones to distribute.
So judging from my experience, if you are living in Mac country (I am assuming that with MAC you don't mean network addresses), you likely already have an advantage in selling Jamulus. Though possibly things other than a Mac mini may not have as acceptable a sound quality out of the box: no idea.
I too agree: at least to begin, let's people start with what they have, but then give them indications on how to enhance their experience. When involving others, you will soon find that your WiFi situation is rarely replicable, in particular if the router is far from the music room (it's not only more latency: on WiFi you may temporarily reach ping of hundreds of ms ).
My band adopted a variety of compromises, because at the end our expectation is "just" to be able to play together, quality helps but is secundary. We all started with WiFi, but the first attempts were not particularly good.
The solution I found for me and for our keyboard player is using powerline adapters, which avoid holes in walls or temporary cables (I bought one, 20m long, but it interferes, ehm, with kids activities... ;) ). The keyboard player spent months telling that his MESH technology was superior, but the first attempt with powerline totally bought him. We still have one guitar player convinced that WiFi does not make a difference, but he is also the one with (way) more crackling than others. Including one singer and the other guitarists that do not have fixed internet connection, and use the cell phone hotspot to connect (via USB, not via WiFi). They have larger overall delay, but very stable. Regarding interfaces, we have one singer via the internal mic of his laptop (pitfall: more external noise, including his cat), and the other one with a cheap Trust USB microphone. The drummer has an old Mac with a sound check that can be only used as input OR output, not both together, so he is using a super-cheap soundcard for connecting his electronic drums (pitfall: he has to switch to the internal mic to speak with us).
As you see, some of our solutions are among the deprecated ones, however we know it and we know their pitfalls and how to upgrade. Asking the two without fixed internet to buy Internet is not possible; however, while with more delay, their sound quality is not bad at all. We are working with the guitar player - likely we will send him an anonymous gift :) .
Last edit: Vincenzo 2021-01-01