sound dropping out for some seconds
USB stick with Jamulus out of the box
Brought to you by:
eleandar
Menu
▾
▴
Hi Laurent, everyone,
I now got a laptop with Jamulus OS installed (with some help). Connection seems normal, speed also ok, interface recognized etc.. But a few times per hour I completely lose sound for a few seconds, also no noise coming from Jamulus and nothing going out. And then it is back again. Never happened with Jamulus in Windows, so I don't suspect my internet connection. Something happening in the Background of this ubuntu version?
Another thing I noticed is that running hardware settings gives different outcomes. first time it chose the internal soundcard over my edirol interface (both at 128), second time it gave both as option, third time it also recognized the 64 option of my interface.
Hi Juriaan,
Thanks for taking time to ask questions.
For the sound dropping:
- have you update to the last Jamulus software version r3_5_6 ? https://youtu.be/ffP2VHVQWtw
- did you have some sound dropping connecting to your localhost server or connecting to a distant private or public server ? If you connected to a distant server can you reproduce the sound dropping connecting to a different distant servers and connecting to your localhost server ?
For hardware settings:
That's possible hardware options changes across calls. It depends on hardware and CPU load at test time. If the sound card performs better at one of your tests, some new options like 64 frames may show up. You may want to increase the test duration for more accurate configuration testing. Press CTRL+ALT+t and type the following command and then press enter:
jamulus-audio-check -t 60 -dExplanation:
-t arg : for test-duration, arg is the number of seconds for each configuration test.
-d : debug information.
BR,
Laurent
Last edit: Laurent Schwartz 2020-06-17
You may read this comment also: https://github.com/corrados/jamulus/issues/212#issuecomment-646661571
Last edit: Laurent Schwartz 2020-06-20
Thanks,other post however sounds not related. Sound quality did not change with me, only a few times (about 4 in an hour I lost 4-10 secs of sound), not a local server but private VPS that I use for my ensembles. I still have to check with other servers, but was afraid to compromise my own ensembles, so for them I returned to windows (and as usual no problems there).
explanation hardware settings: thanks, seems logical. But perhaps also safer not to go for 64 but stay on 128....
Last edit: Jurriaan 2020-06-19
Yes, i agree. Use only results that doesn't generate too much xruns in your use case. You can see XRuns (if any) by clicking on messages button on qjackctl.
If you have too much XRuns, this may result in dropping sound. But 4-10 seconds ... This is a lot.
4 to 10 seconds of dropping sound could be due to:
network issue (May be a download or upload on your network ... as said by Volker on the link above)
too much CPU use (To know how much CPU is being used press CTRL+ALT+m, it loads the taskmanager, You will see if a process is taking 100% CPU and will see its name).
Sorry for that.
Last edit: Laurent Schwartz 2020-06-19
if you use the private server as a service on Jamulus OS side, you could try to remove --fastupdate option (see Jamulus service parameters icon) but in this case the minimal audio latency is 128 frames/period and not 64. Without the --fastupdate it will take less cpu and network resources.
I Haven't been using the private server yet. On the sound dropping out I experimented a bit more, interestingly enough, the faderlights were still going up during sound dropout., so it looked like Jamulus was still recieving and senting those few seconds of silence. Also the network and cpu seemed ok in tastmanager, nothing special or no peaks to be seen. see pic . I now suspect Jack, who gave me some headaches on windows too.... But it might be an error solely bound to my setup...
On the screenshot you did, in the Jamulus settings, the indicator is red in the Jitter Buffer Column indicating the audio is interrupted. You might want to change your Jitter Buffer settings according to http://llcon.sourceforge.net/settingswindow.html, The lower, the better if Jitter Buffer indicator is green and overall delay is green. You can also try in auto mode Jitter Buffer (It will try to adapt automatically to your network).
What type of connection have you got ? (ethernet, powerline, WIFI) ? (ADSL, fiber ....) ? Your overall delay is yellow indicating this is not optimal. If you could lower your ping by n ms you could substract 2*n ms to your overall delay.
merci, the photo was just after the dropout, got another with green light. Not sure whether the 5 second dropout had red lights, but I believe not. And I know how to handle jitterbuffer, thanks. I will stay on windows now, until I have more time to experiment further....
Have you got the same settings on Jitter Buffer in Windows and Linux ?
About the same, also experimenting. But jitter is different, you always hear some sound or crackling. Here the sound disappears completely for 5 seconds. or more. Without one crack or jtter even..... perhaps its just a peculiar thing with this laptop, dont worry too much about it for now!
I've been suffering complete audio drop-outs too - I'd guess maximum 5 seconds or so. This is both with JamulusOS on USB stick, and also with Mint19.3 (PulseAudio disabled) on same laptop (Lenovo L440). Today I did some testing, and seem to have a solution.
I've changed the Periods/Buffer value from 2 to 3, and it now seems fine.
I then changed Frames/Period from 128 to 64, and it's still fine and less latency.
So for me at least this seems like a solution.
Thanks for the tip @Rick.
When you increase the period/buffer value in qjackctl, you increase the latency for the same Frames/Period. (so It requires less cpu)
I read somewhere that for USB sound card, a period/buffer of 3 is preferable but i did not verify the information. I observed that it increase the audio latency and generates less Xruns for the same Frames/Period. So better sound quality but more audio latency.
So it seems to be a sound card issue for you (@Rick). Have you got a USB sound card ?
it could also be a side effect of ubuntu services running in the background and which are not necessarily useful for the audio session (there are a few). I'm curently making a script that stops them and restart them at the end of audio session. This may also help.
Let me know if you want to give it a try.
Yes, I'm using a UMC404HD external interface, so that may well be part of the problem. Also, I forgot to mention in my previous post that the audio drop-outs were always with multiple XRUNs, so that all makes sense. I've not tested this, but I think the problem was less when using the internal sound, so again it all makes sense.
I did wonder what other services are running that are not needed, so would be interested to see what you're working on.
Thanks for your rapid reply.
I have some other thoughts on JamulsOS in general, so I'll add another thread when I've worked out what I'm trying to say!
You can download audio-session-1.06 from here
Open a terminal on the Download dir and type (or copy/paste) the following to install in your HOME directory:
mkdir -p ~/.local/bin && cp audio-session-1.06 ~/.local/bin/audio-session && chmod 755 ~/.local/bin/audio-sessiononce done, you can type the following to start an audio session:
audio-session startIt will stop uneeded services and stop WIFI (on some old systems this can be an issue)
The sudo password will be ask if you're running JamulusOS on hard disk rather than USB stick otherwise it will execute without asking password.
Once your audio session has ended and you want to come back to normal use, type
audio-session stopThis script is a work in progress. If you use it please report your success/failure.
Last edit: Laurent Schwartz 2020-07-05
Thanks for the script. I've looked at it but not yet tried running with it - very busy here!
Only comment so far is that unconditionally disabling WiFi may be a problem for some users. I know a few users who have to use WiFi as it's not practical to run a cable. My tests so far suggest that it's ok if there is nothing else on the WiFi.
I'll reply properly when I've had a chance to test.