Jamulus
Sound deteriorates on Mac for some audio drivers #1059
Replies: 50 comments 57 replies
-
|
Can you try with the latest Git source for the server issue (not closing). That should have a fix for it. |
Beta Was this translation helpful? Give feedback.
-
|
@pljones Would I have to compile that source? If so, I don't currently have a way to do that (no development environment). |
Beta Was this translation helpful? Give feedback.
-
|
OK - that should be fixed when 3.5.3 comes out, at least. |
Beta Was this translation helpful? Give feedback.
-
|
More on the Settings window issue: The reason I have the Settings window open, of course, is that I am monitoring Delay (and to a lesser extent, Buffer). How about displaying these times on the client window under the lights? Does anyone else care? Would it be distracting to do this? Should it be complicated to solve the underlying issue, is it possible to prevent users from keeping the Settings window open as I have been doing? |
Beta Was this translation helpful? Give feedback.
-
|
I leave the Settings window open all the time. I can run Jamulus for hours without any issues. I do this under Windows and Mac. So the question is if this problem only occurs for you or are there any other users affected? |
Beta Was this translation helpful? Give feedback.
-
|
BTW, have you tried version 3.5.3? I have just released the new version. |
Beta Was this translation helpful? Give feedback.
-
|
Uh oh. Really? What can be the difference between your setup and mine? |
Beta Was this translation helpful? Give feedback.
-
|
Do you run the client and server on the same PC? If yes, can you try to shut down the server and just run the client and connect to some remote server. Do you still see the issue then? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, they are both on my Mac. I'll try connecting to some other remote server nearby. After about 30 min. now there is no issue. No change in either Ping or Overall Delay times, or complaints from the Buffer dept. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, thanks for testing. I saw that you already posted in #133. Do you think we need two Github issues on this matter or shall we close this and leave the other one open? I would prefer to have just one open Issue about this bug. |
Beta Was this translation helpful? Give feedback.
-
|
One issue is better than two. :-) But let me test whether my issue can
happen when the Settings window is closed (#133 doesn’t mention Settings,
but incidentally I am running on the same hardware as he was).
…On Sat, May 16, 2020 at 07:44 Volker Fischer ***@***.***> wrote:
Ok, thanks for testing. I saw that you already posted in #133
<#133>. Do you think we need
two Github issues on this matter or shall we close this and leave the other
one open? I would prefer to have just one open Issue about this bug.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#212 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/APPMA2TYCUOBK4GJH52PJGDRR2RGFANCNFSM4M7FOS5A>
.
|
Beta Was this translation helpful? Give feedback.
-
|
BTW: Here is another one which is similar: #40 |
Beta Was this translation helpful? Give feedback.
-
|
One more question:
Does this mean his own signal is also distorted (which mean the server has an issue) or he just hears your distorted signal (which would mean your client has a problem) but his own audio is still ok? |
Beta Was this translation helpful? Give feedback.
-
|
She says that only my sound was bad. Hers was okay.
… On May 16, 2020, at 08:39, Volker Fischer ***@***.***> wrote:
One more question:
Deteriorated sound quality is also experienced by the other musician (only tried with 1 other) who is connected to the server.
Does this mean his own signal is also distorted (which mean the server has an issue) or he just hears your distorted signal (which would mean your client has a problem) but his own audio is still ok?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Beta Was this translation helpful? Give feedback.
-
|
Ok, this is an important information. So it is the client not the server which makes problems in your case.
Is it crackeled sound what you here? Can you describe the type of sound quality you get a bit more? |
Beta Was this translation helpful? Give feedback.
-
|
My understanding is Jamulus implemented something to re-order out-of-order packets as of Version 3.6.0. I like your theory about the late packets; that would explain the phenomenon, though I have no way of knowing if the condition you posit is actually the case. It would be nice if Werner or another developer could offer a comment. As it happens, I connected to a session this morning as a listener, and while on the session, turned off my anti-virus. It seemed to help. I've now also turned off iStat menus. I have a rehearsal later today; it will be interesting to see if these steps make a difference. I don't know if I've mentioned it in this thread, but I seem to experience better behavior on another platform (Soundjack). But since that is primarily peer-to-peer (their server capability is in a fairly primitive state of development), it's hard to make a definitive statement. |
Beta Was this translation helpful? Give feedback.
-
|
I would be glad to discuss strategies for using the enumeration to understand the audio defects. You can use Activity Monitor to determine if you have enough spare CPU cycles to leave some of those other task running. Regarding SoundJack. It is easy for a new early-stage code to be fast and nimble. As the code becomes more fully-featured, those features will consume CPU cycles. A motorcycle can be fast and nimble but it is not a car. I spent a significant time looking at JamKazam, another peer-to-peer solution. Scaling with Jamulus is much better. I expect a similar characteristic with SoundJack. |
Beta Was this translation helpful? Give feedback.
-
|
Right, I know server-based models scale better to larger number of singers. But what is true is for just a few singers, where point-to-point makes sense, Soundjack works great -- about half the latency (as you're connected directly to the other peers, rather than via a server); and I don't get the annoying accumulation of sound garbage. RE CPU cycles, for Jamulus I never get above about 8% of CPU devoted to Jamulus on my Mac. Since I shut down everything I can, the CPU is mostly idle when I have Jamulus running. I was on another rehearsal tonight, with anti-virus and iStat menus disabled. Still the accumulation of noise/crackles etc. Since I have a half-year-old quite capable MacBook Pro, and since others running older, less capable machines seems not to have this problem I have to assume the problem is not my computer. So I wonder if the problem can be in the router or modem -- though I am using an integrated gateway that is also new, and capable of GB+ speeds. So where else can I look? |
Beta Was this translation helpful? Give feedback.
-
|
I have been thinking about the accumulated sound problem as a server issue. Your MBP shouldn't be the problem. Running at <10% load shouldn't cause any delays. To me, noise/crackles are caused by dropped, late, or out of order packets. (Since you report Jamulus reorders packets, out-of-order packets is not the problem.) With your MBP running <10% loading, I would look at your transport. Currently, the only transport-related clues you would have is the fluctuating latency and total delay numbers. Use the largest buffer setting you can. If the latency fluctuation is larger than the buffer time equivalent, every time you get a big latency bounce, you are likely to get a buffer underrun followed by a buffer overrun (which is a lost packet). |
Beta Was this translation helpful? Give feedback.
-
|
Two thoughts: (1) I didn't notice a big change when Jamulus 3.6.0 came out, so it's not clear to me that Jamulus's ordering of packets was completely effective. The release notes didn't provide any detail. (2) I looked at my gateway's firewall log just a short while ago and found over 11000 WANATTACK drop attempts this evening. Along with 3629 PPv6 FORWARD drops and 2736 IPv6 input drop attempts. I have no idea what generates these, but it seems like something that could tie up the gateway and interfere with orderly packet transmission. My observation though is that when this packet loss phenomenon happens, it only affects what I hear, not what others hear of me. RE firmware updates, this is the cable company's router, I have no means to check for, let alone install, a firmware update. |
Beta Was this translation helpful? Give feedback.
-
|
1- I am curious about what the packet ordering algorithm does. My wild guess is it is of limited effect. |
Beta Was this translation helpful? Give feedback.
-
|
Re your comments: 1. I agree. 2. The bursts of scans can account for inbound packets not making it to my computer in a timely fashion, which would certainly impact audio. Unclear to me why this effect should increase in time, and why resetting the Jamulus buffer delay would make it temporarily better. But anyway I am going to contact my ISP to see if there is anything that can be done to alleviate the attacks. 3. There is no place in the gateway's management interface to trigger a firmware update. Apparently the gateway provider (Comcast) rolls out firmware updates automatically. |
Beta Was this translation helpful? Give feedback.
-
|
Hi all - I'm moving this to a discussion until we can identify the thing(s) that need doing to fix this, at which point we can raise the appropriate work tickets. |
Beta Was this translation helpful? Give feedback.
-
|
The working word is "supposedly". The clock chips make no difference in the accuracy, the quartz does. And very accurate quartz's are very expensive. I am not aware of any computer that uses the same clock for the processor and for the RTC. They are two completely different animals. The processor needs a clock that is fast, up to several GHz, and can be tuned in steps. The RTC (Real Time Clock) supports only one frequency and must be very low power to allow battery backup, which implies slow. It is not practical to do both with the same clock. |
Beta Was this translation helpful? Give feedback.
-
|
I am reviewing some of the responses I've gotten from the two local choirs. As mentioned most of the mac users have my problem, and most have macs from the past few years. The only Mac user who responded and is not having the problem is on a 2012-vintage machine. And he reports very low numbers (within a ms) from sntp. Maybe coincidence, but... |
Beta Was this translation helpful? Give feedback.
-
|
Maybe this user is in a special place on the Internet with very little delay and jitter. |
Beta Was this translation helpful? Give feedback.
-
|
Well, no, I just tried sntp on my work computer, about 3 feet away from the Macbook Pro I've been complaining about, and it too has very low results from sntp. Same network, etc. It's also a Macbook Pro, about 3 years old. Main difference, as far as I know, is it's on Mohave (as is the 2012 Mac described in the preceding message). I'm not allowed to put personal software like Jamulus on the work machine, so I can't test my thesis there. |
Beta Was this translation helpful? Give feedback.
-
|
I'm out of clues. The only ordinary possible cause is the TCP traffic sharing the link. Of course, we don't have data on that. |
Beta Was this translation helpful? Give feedback.
-
|
I was still betting on removing the trailing period from time.apple.com. Except -- in the past couple of minutes the offset measured by sntp on my (newer) personal laptop just went up by over 30 ms. Much larger than the variability of ping times to the same time server. And it's staying at the higher value, then slowly dropping. And during roughly the same interval the sntp time on my work laptop barely changed (still around 6 ms). So, I venture to say this has nothing to do with changing internet conditions. What I am starting to think: that in MacOS Catalina and Big Sur, there is a bug in the synch algorithm. What happened a few minutes ago, I think, is that the Mac attempted to synch -- but in doing so it is setting the clock to an incorrect value (about 52 ms behind what it should). Then on next sampling, because ntp recognizes that the clock is behind, it speeds up the clock; the error gets smaller, until the next synch, which starts the process over again. Whereas what SHOULD happen is that the computer sets the clock to its best guess at spot-on time, then re-measures delay and sets the clock speed accordingly. The current behavior is, I'm guessing, better than the old behavior of losing 2 seconds in a day because I removed the spurious dot in the time server address. |
Beta Was this translation helpful? Give feedback.
-
|
Regardless of discussion of TCP traffic, I now have pretty conclusive evidence that an error in synchronizing time was introduced in MacOS between Mohave and Big Sur, and I'm pretty sure it was in Catalina. (I'll have that info shortly). If I uncheck "set date and time automatrically", manually set time to something wrong, recheck "set date and time automatically", then query clock accuracy, it is within a ms or so on Mohave, but off by 10's of ms in Big Sur -- and I now have this data from several different machines of different vintages and architectures (Intel and M1). Regardless of Jamulus, this will be a problem for apps requiring ms accuracy of time. I will follow up with Apple. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your persistence in cornering this source of error. |
Beta Was this translation helpful? Give feedback.
-
|
Some updates for anyone following. I've collected more data. The time synchronizing issue seems to affect new (past couple of years) macs running Big Sur, and not affect older macs on older OS's. I don't know whether it's the machine, the OS, or a combination. And I can better characterize the behavior on a given machine -- time error pretty stable for a while, probably until the Mac tries to re-synch, then a change, sudden or gradual, to a new value 10's of ms removed, but not necessarily closer, to perfect synchronization. So depending on the direction of the shift, one can expect buffer under-runs or overflows involving many packets of sound info. I am wondering if Jamulus how (or if) Jamulus deals with this. I've had my second conversation with Apple Tech support about the synch issue; Apple has collected some log info and I expect to hear something further from them next week. |
Beta Was this translation helpful? Give feedback.
-
|
Further follow-up, met again with Apple, we took screen captures of time setting error in Big Sur and accurate time setting in Catalina; these along with system logs are being forwarded to Apple engineers. But even in Catalina I still have annoying glitchiness (I guess a parade of buffer under-runs/overflows) that are not there on my ancient Macbook Pro. I wish someone could point me (and others with the same issue) to a solution. |
Beta Was this translation helpful? Give feedback.
-
|
Hoping to wake up this thread with the following observation: The problem I was discussing in this thread -- gltichy, crackly audio that increases with time, and increases with the number of participants contributing audio to the mix, until something (like re-pressing the buffer delay button) temporarily heals by forcing a clearing out of buffers -- does NOT occur on my 11-year-old Macbook Pro running High Sierra -- ever! But it occurs on every Jamulus session with more than 2-3 clients when I run my 2020 Macbook Pro, running either Catalina or Big Sur. So it is NOT related to my particular internet connection, or router/modem. I was thinking the problem was related to errors in the clock synchronization in the newer MBP running Big Sur (see previous posts), but I've been able to fix that problem by running chrony instead of timed to synchronize the Mac's clock. That does not solve the problem. I keep looking to other Jamulus discussion threads for solutions or at least other threads discussing a similar issue, but haven't found much. I'm hoping this latest bit of additional info about the new vs old Mac might inspire some ideas out there. |
Beta Was this translation helpful? Give feedback.
-
|
Hoping to revive this thread with some new (to this thread) info -- in hopes of, finally, a solution. And pardon if this turns out to be a repeat post, I composed a similar remark last night but it seems to have gotten lost. The problem I have been chasing down is the following: On my, and at least some other recent, Macbook Pro, running either Catalina or Big Sur, sound on Jamulus sessions with many participants degrades over several minutes, becoming more crackly/garbled. Problem gets worse faster with more participants. I do not have this with other low-latency audio apps, e.g. Soundjack. My new observations: (1) I NEVER have this problem when running Jamulus on my 11-year-old Macbook Pro running High Sierra. Same network, same router/modem, same ethernet cable. So what is it about new macs running new OS's? And seemingly, not all macs running new OS's. (2) Another piece of new info is I have a report of this phenomenon from someone running a desktop year-or-so-old Mac Pro. And (3) Fixing the clock synchronization issue discussed in previous posts (by setting system time with chrony rather than timed) did not solve the problem. Any ideas as to cause, or better yet a workaround? |
Beta Was this translation helpful? Give feedback.
-
|
Hi Ron, We are actively looking into eliminating or avoiding these Mac problems and have already spend a lot of time on it, but don't really have a good handle on what is happening yet. Unfortunately most of the development team uses Linux or Win10, so we can't throw a big team at the problem as most of us don't have Mac hardware to test on. Be assured, however, that this is at the top of our priorities right now. |
Beta Was this translation helpful? Give feedback.
-
|
Hello DonC, |
Beta Was this translation helpful? Give feedback.
-
|
No. There’s no real documentation; the closest you can get is this paper: https://jamulus.io/PerformingBandRehearsalsontheInternetWithJamulus.pdf |
Beta Was this translation helpful? Give feedback.
-
That is great! As to the code; Jamulus is a typical one-man project. The documentation is in Volker's head. |
Beta Was this translation helpful? Give feedback.
-
|
I am also experiencing distortions on my Windows10 computer. 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, the the sound is ok again. Then I can change to the original settings again. This happens 4 to 6 times during our choir rehearsal. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not so sure taking monojk's issue to a separate thread is such a great idea, as monojk's symptoms seem very similar to mine, even if the platform is different. At the least I would like to get a link to the new thread so I can see if a constructive solution is developed through it. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! See #1831 |
Beta Was this translation helpful? Give feedback.
-
|
Well -- the post about synchronization issues on Windows, and the remark about it being "unrelated to the one mentioned above" got me wondering about -- synchronization issues. So after the better part of a year trying to figure out why I, and SOME people on newer Macs are getting crackles and glitches that increase in time until one re-selects the buffer delay -- I have found the source of the problem and a workaround. It is indeed a synchronization issue. It is the clock in my external USB mic (Blue Yeti) drifting out of synch with the Mac clock. My guess is that people experiencing these gllitchy sound issues on new MBP's are all using devices that introduce multiple clocks, while those with similar-age Macs that don't have this problem are either using the built-in mic, or an external device with clock that slaves to the internal clock, or something similar. My workaround: use Apple Midi Setup to create an aggregate device consisting of my external (USB) mic and the built-in mic, set the clock source to be the internal mic, with drift correction checked for the Yeti. Then I set the channel mapping within Jamulus to map only the Yeti to the L and R stereo channels. I have now been on two hour-long Jamulus sessions completely free of the deteriorating sound problem, whereas if I directly use the Yeti as input and headphones as output I would get glitchy sound after a few minutes with the same number of participants. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe worth a Knowledge Base or better troubleshooting entry? |
Beta Was this translation helpful? Give feedback.
-
|
Wow Ron, that is a great find! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, but that paper is not much to go on. I am wondering how the current developers managed to get a sense of how the code structure.
On Sunday, June 6, 2021, 01:11:39 AM PDT, ann0see ***@***.***> wrote:
No. There’s no real documentation; the closest you can get is this paper: https://jamulus.io/PerformingBandRehearsalsontheInternetWithJamulus.pdf
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Beta Was this translation helpful? Give feedback.
-
Yes, it's challenging and I've not read and understood the whole code. However, you can try to start following the conversations here, reading some code (start with server.cpp for example and search which method gets called where). The comments are usually quite good. |
Beta Was this translation helpful? Give feedback.
-
|
Probably so. How would I go about submitting an entry to troubleshooting? (I see the option to contribute an article to the knowledge base, but nothing similar for troubleshooting.)
On Friday, June 11, 2021, 02:43:39 AM PDT, ann0see ***@***.***> wrote:
Maybe worth a Knowledge Base or better troubleshooting entry?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Beta Was this translation helpful? Give feedback.
-
|
You can edit the file here: https://github.com/jamulussoftware/jamuluswebsite/edit/next-release/wiki/en/Client-Troubleshooting.md This is the troubleshooting page. It will however not go live yet (since it needs translation). A KB page can be created based on this link: |
Beta Was this translation helpful? Give feedback.
-
|
Thanks. I realize that I don't completely understand why an out-of-synch clock on my mic would cause everyone else's sound to be glitchy in my client, but I seem to have a solution despite that, so I guess I can post it as something for others (on Macs) to try.
I think there are similar issues with Jamulus on Windows, but it is less obvious how to construct a workaround. The ASIO4ALL documentation on aggregate devices describes the synchronization problem but doesn't present a solution.
On Friday, June 11, 2021, 11:48:01 AM PDT, ann0see ***@***.***> wrote:
You can edit the file here: https://github.com/jamulussoftware/jamuluswebsite/edit/next-release/wiki/en/Client-Troubleshooting.md
This is the troubleshooting page. It will however not go live yet (since it needs translation). A KB page can be created based on this link:
https://github.com/jamulussoftware/jamuluswebsite/new/release/_posts/?value=---%0Alayout%3A%20post%0Atitle%3A%20%22Your%20Title%22%0Alang%3A%20%22en%22%0Aauthor%3A%20%22YourName%22%0Aheading%3A%20%22Heading%22%0A---%0AName%20this%20file%20and%20edit%20the%20parameters%20above%21&message=New%20post
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Beta Was this translation helpful? Give feedback.
-
[There may be two issues here. See below.]
If the Settings window is left open for a period of time (15-30 min), and musicians are connected to the server, then there's a good chance that sound quality will go all to wreck (overall delay episodically > 500ms at the client that is running on the same machine as the server). Once the Overall Delay starts increasing it gets progressively worse and worse. Deteriorated sound quality is also experienced by the other musician (only tried with 1 other) who is connected to the server.
MacOS, server running on the same machine as the client, wired Ethernet connection.
Replicated. Annotated screenshot is attached.
Possible second issue: Did I have multiple server instances running?? There is no "Server Stopped" message from the first instance, which (I thought) I had killed by closing the Server window. (see the Terminal window in the screenshot). Does closing the Server window not kill that server (because it was launched via the Terminal not the GUI)? If not, shouldn't it?
Beta Was this translation helpful? Give feedback.
All reactions