Distortion creeping up

[monojk]

I am experiencing distortions on my Windows10 computer with Jamulus. It starts after let's say 15 to 20 minutes like distortions of an overdrive sound. My remedy is to change the channel or quality on the settings, then the sound is ok again. Then I can change to the original settings again. This happens 4 to 6 times during our 2 hours choir rehearsal.

It's only me who hears the distortions, not the other participants.

I am using ASIO4ALL.
Micro: t.bone SC440 USB
Earphones in Bose loudspeaker jack, Bose connected to monitor driven by HDMI, driven by Intel Display-Audio (Internal High Definition Audio Bus) (Ausgang 1.1.x)
Realtek HD Audio is present on the computer, but not used according to my Jamulus soundcard settings selection.

[ann0see]

Ok. Thank you for opening a new discussion! What happens if you plug your headphones into the internal sound card? Maybe this solves your problem. As I said, it might be related to some kind of synchronization problem (since you're using two different devices)

I would also have a look at https://www.asio4all.org/index.php/help/instruction-manual/#Device-aggregation

[dcorson-ticino-com]

Our experience is that such problems are almost always related to Internet connection problems. Things like sudden jitter peaks, that happen seldom, but create havoc.
As we see in your screen shots, you already have quite a bit of jitter as you have the jitter buffers above 3 or 4. And it is not surprising that the others are not hearing the problems as it is your download line from the server, the local jitter that is higher. I presume that you have already tried all the combinations of audio parameters to see what works the best.
Unfortunately there is not a whole lot you can do about this other than choose a different server that your ISP may have a better connection too. Or change the ISP, although that can be more challenging.
Changing the connection parameters as you do stops the old connection and starts a new one letting all the communication nodes between you and and the server empty their buffers and start anew.

There is still the possibility that you can optimise something locally with your interfaces that may help. Does the t.bone USB mic not have an ASIO driver from the manufacturer? Personally I have never been able to get ASIO4ALL to work.

[gene96817]

Changing the connection parameters as you do stops the old connection and starts a new one letting all the communication nodes between you and and the server empty their buffers and start anew.

Can we put this flushing of buffers in the code? This would make Jamulus easier to use under a wider range of Internet conditions.

[dcorson-ticino-com]

The problem is not Jamulus' buffers, but the route between client and server over which we have no control.
Automatically flushing that would mean automatically causing short dropouts.
I would not like to do that.

[gene96817]

There are two choices.... minimize dropouts and run more and more behind the other musicians or have a dropout to maximize sync with other musicians. I have experienced some jittery days when the sound continues to get delayed until manually disconnecting and reconnecting. I would prefer a few dropouts to stay in sync.

When there is a buffer underrun, there is always an audio dropout. The length depends on the duration. The problem is with multiple underpins, the delay is cumulative.

[dakhubgit]

What I wonder is what the accumulative behavior of Jamulus is when there is drift between server clock and client soundcard clock (or packets get lost or disordered). There will be a dropout eventually. The question is how much this dropout contributes towards moving to a state where the next dropout is going to be a significant time away again. And of course, how does this differ with "Auto" and with fixed jitter buffer sizes?

[gene96817]

What I infer from the discussions from the past months, packet reordering was introduced to fix some (Internet) transport defects. Of course the range of reordering can only span the size of the buffer. Reordering requires holding packets until the missing packet appears. The maximum holding time is one buffer delay.

A dropout happens when a packet is late and there is a break in the audio stream. An underrun always causes a dropout. Maybe some dropouts are too short for some people to hear. For me, it is not helpful to try to use one duration of a buffer underrun to predict the duration of the next event. What is perceivable is the accumulation of underrun periods. Because Jamulus tries very hard not to lose packets, the underrun periods become additive and the delay is additive. I don't think it is desirable to attempt to process every packet and let the delay accumulate to multiple seconds. It would be better to have a noisy channel and maximize being in sync.

I am not aware of any mechanism that limits the skew between the server and client clocks. On one session when the Internet was particularly noisy/jittery, the accumulated delay exceeded 3 seconds. ( At that point I heard enough and killed the connection.)

[ghost]

@gene96817

I am not aware of any mechanism that limits the skew between the server and client clocks. On one session when the Internet was particularly noisy/jittery, the accumulated delay exceeded 3 seconds. ( At that point I heard enough and killed the connection.)

• It is possible that the delayed packets are 'in flight', thus buffered by the internet.
• Will Jamulus actually buffer 3 seconds of packets?
• Maybe Jamulus doesn't read all of the packets on its doorstep
  and the operating system queues them.
• Jamulus should keep reading packets until there are none waiting...
  Jamulus could then discard those that overflow the buffers.

[gene96817]

It is possible that the delayed packets are 'in flight', thus buffered by the internet.

Yes, packets can be buffered by any routers along the path. Mostly, traffic congestion at a router will buffer packets.

Will Jamulus actually buffer 3 seconds of packets?

The Jamulus buffers are too short for 3 seconds worth of buffering. This is not what I am suggesting. I am pointing out that with a series of buffer underrun at the Jamulus code (which would be caused by buffering in the Internet) can result in packet delays of 3+ seconds. I have observed this condition.

Maybe Jamulus doesn't read all of the packets on its doorstep and the operating system queues them.

This is a normal condition. That is why there are buffers. Under normal (actually, nominal) conditions, the total delay is steady and there is accumulation of long delays.

Jamulus should keep reading packets until there are none waiting... Jamulus could then discard those that overflow the buffers.

This is the behavior under nominal conditions. Note that a stream of packets for audio wants to be processed without pauses. A pause (or break) in the flow, such as when there is underrun, means the sound has a glitch. Now consider three users receiving the server audio mix. If one user (A) has a network delay and buffer underrun, when the packets begin to flow, this user will hear the sound of the resumed audio stream delayed in time compared to B and C. If A is on a congested data path, this can happen many times. Each time the audio stream for A accumulates additional delay relative to B and C. Supposed A eventually is 750ms (or 3 seconds) behind B and C. It is more and more difficult to play in time. The only way for A to be back in time is to flush the data stream (by disconnecting and reconnecting).

I am trying to point out, there are two options here. Player A can stop jamming and reset his connection (which is a big interruption in the A's sound) or Jamulus could flush the buffer (and all the late packets). If this happens automatically, then there will be occasional glitches in the sound but A can continue to jam with B and C. I propose that when there is a congested Internet path, it is better to have some glitches and continue to jam.

[monojk]

Ok, I'll use the laptop's jack for the headphone the next time.

Btw, the connection to our server "seems" to be good as I don't hear any blops. When we started using Jamulus there were blops (all participants could hear that), but since over a moth the blops are cone.

[monojk]

Using the Laptops jack (Realtek driver) doesn't change the problem....

[dcorson-ticino-com]

We have seen here #1059 (reply in thread)
that using a USB microphone can cause synchronisation problems on a Mac.
It could be that there are the same problems on Win10.
Could you try if you have the same problems using the internal mic ?

[monojk]

Sorry, internal microphone has too much noise from the internal fan and HDD. I cannot use it in our rehearsals....

[dakhubgit]

DonC ***@***.***> writes:

We have seen here #1059 (reply in thread) that using a USB microphone can cause synchronisation problems on a Mac. It could be that there are the same problems on Win10. Could you try if you have the same problems using the internal mic ?

It's probably different. For typical sound applications, you want a synchronized common clock for recording and playback, and there are a number of USB microphones that have a headphone output for that purpose. With Jamulus, I am not sure how much of a difference using unsynchronized devices for recording and playback should cause other than by chance: after all, the mixing is done using the server's timer clock, so you have drift between recording and mixing and drift between mixing and playback even if recording and playback are working with the same clock. Some sound systems may refuse to work with more than a single clock source, though.

…

-- David Kastrup

[jujudusud]

The problem is between USB microphone clock and the system clock on which it is plugged in.

[jujudusud]

If you want to achieve a rehersal at low latency you should have a look to an audio interface + xlr microphone + wired headphones.
Or, you have to use bigger buffers.

[dakhubgit]

Julien Taverna ***@***.***> writes:

If you want to achieve a rehersal at low latency you should have a look to an audio interface + xlr microphone + active nearfield monitors. Or, you have to use bigger buffers.

Nearfield monitors? Not a good idea because of echo/feedback. Great if you are playing an electronic instrument but then you want some sort of push-to-talk microphone arrangement where the monitors get strongly attenuated when you want to say a few words yourself (only having the instrument speaking can be a bit disconcerting). Some mixers with computer interface have a "Control Room" section setting up such a system (control room monitors get attenuated while you push-to-talk into the control room microphone), but for a normal audio interface that would be kind of unusual.

…

-- David Kastrup

[jujudusud]

You are right, while i'm playing bass guitar... I just don't have feedback problems.
I will edit my comment with wired headphones instead.