Jamulus
Improve Connection Monitoring to identify root cause of dropouts #1061
Replies: 7 comments
-
|
Guys, thanks for this. I too would like to see a bit more information coming from the server buffer. I too normally go to an empty server and try it out before I join someone else, but that doesn’t tell you about the server you are joining, unless I’m fundamentally misunderstanding something. Also, you may be joining a session halfway through, and you really don’t want to interrupt someone’s session to check whether they are hearing you okay. It would be a bit like gatecrashing into a practice room and then expecting everyone to stop while you fiddle with your amp! While there is an LED for the local buffer, It’s the server buffer which is not easily audible and which affects what everyone hears coming from you. As a musician It’s very important to be confident that you are being heard without problems. Yes, people will tell you if there’s a problem, but that interrupts the flow of the thing. Or worse – they just fade you out. |
Beta Was this translation helpful? Give feedback.
-
|
@marktheharp |
Beta Was this translation helpful? Give feedback.
-
That's right - and separately the other week, I also proposed the exact same thing - so "Mute myself" becomes a sort of "pre-fade listen" but goes to the server and back without anyone else hearing you. That makes very much sense. The only difference with my suggestion was having an option to be able to hear the others as well at your local end - which you could always fade down, but it gives a change to also check that you can play with the delay without anyone else hearing you. Great minds, and all...! |
Beta Was this translation helpful? Give feedback.
-
|
Not in my computer to test, but hearing just yourself with the audio going thru the server may be accomplished by using the Solo button on your own channel IIRC, like in any other mixing table. Or are you proposing something different? |
Beta Was this translation helpful? Give feedback.
-
|
Good point – yes, just tested it out and solo does allow you to hear yourself via the server, but it would be really great if we could do that and simultaneously mute ourselves for everyone else who is listening to the server. There is no one in my server so I can’t check that, but I’m pretty sure that even if I solo myself, other people connected via other clients will still hear me. If I’m wrong, and soloing myself also mutes me from other people’s feeds, then that’s perfect! |
Beta Was this translation helpful? Give feedback.
-
Still not in my computer to test, but I think you're right. Solo will only act in your own mix, it will make your upstream available for others users to listen to. |
Beta Was this translation helpful? Give feedback.
-
|
Hi all - this seems to be related to a wider discussion about telemetry in Jamulus. In order that we can get to a point where we can identify reasonably clear work tickets for the Issues list for this, I'm converting this to a discussion if that's OK. |
Beta Was this translation helpful? Give feedback.
-
Taken from the Discussion forum: https://sourceforge.net/p/llcon/discussion/software/thread/57841cd9c4
First of all, Congratulations to this SW!
As a musician, the SW is a great solution for band rehearsal, especially in the time we're facing right now.
As a developer, jamulus is a piece of SW with a clear UI and architecture.
Several 'instrument' clients are UP-streaming their audio to a central server, which does the mixdown and the DOWN-streaming to a distributed set of 'loudspeaker'.
At least this is how I understand and simplify the functionality for description here.
After several rehearsals with my bandmates and others, using private and public servers, there seem to be options for improvals, especially when it comes to nail down the root cause of dropouts and crackling in the lines and help others to find it quickly.
The technical questions behind the issue for the musicians are :
-- are all 'instrument' clients able to at least UP-stream their data without dropout to the chosen server and is there perhaps only one instrument client that need some (buffer) adjustments for jitter compensation along the path. An error in one client affects all others!
-- or is the problem that there is too much jitter just on the DOWN-stream path to a specific (or all) 'loudspeaker' clients. This error is meaningful only for a specific client.
-- also we encountered that especially WINDOWS server sometimes very difficult to setup/tweak to really fulfill realtime responsiveness for soundcard/ASIO sample buffer handler
-- is the server performance sufficient to compress/decompress/mixdown or does this cause the jitter increase or dropout
I think some improvement can be (easily) added, if it would be possible to indicate jitter separately for UP/DOWN stream path and add some indicators to each client to better figure a problem.
I attached a drawing for a tweaked UI and here is a short desription :
-- add monitor LED to input samplebuffer (UP-stream), that is triggered most probably in case of overflow (indicator for OS soundcard driver setup problem)
-- add monitor LED to output samplebuffer (DOWN-stream), that is triggered most probably in case of underflow (indicator for OS soundcard driver setup problem)
-- replace 'buffers' LED indicator by 2 separate UP/DOWN-stream LED indicator
-- DOWN-stream/path error LED is indicated when there is a problem in 'output-samplebuffer' OR 'Local' jitter buffer
-- UP-stream/path error LED of all individual 'clients' need to be shown to all users, as errors affect all listeners
I think these are all kind of small changes as information seem to be there already. Question is, is this possible and convenient. What do you think?
Last edit: mmatt 4 days ago
Thumbnail
jamulus3.JPG
Volker Fischer
Volker Fischer - 4 days ago
I am not sure why you need all these new LEDs to fine tune your system. The Jamulus software is already pretty technical (people already complain about the complexity), I would not make it more complex.
One issue is that you only have control of your local jitter buffers. The ones at the server are remote. You would have to transmit the jitter buffer states with additional network state packets. Much too much effort for little improvement.
If I want to fine tune my system, I connect to a free server where nobody else is connected. Then I turn down the jitter buffer faders until I can clearly hear the audio drop outs. Then I lift the jitter buffer fader just a bit.
Usually the jitter is equally distributed between up/down stream. If you do not have others using the local network, the stream is usually pretty stable and the jitter is mostly defined by the sound card timing and the server timer routine jitter. The server you usually cannot improve but at your side you could improve the jitter by using, e.g., a better ASIO driver. Even the operating system makes a difference. I have a Lexicon Omega and I cannot really use it under Windows. The latency is too high. But it is completely different on my old Mac Mini. On Mac I can get very low latencies with that audio interface.
mmatt
mmatt - 3 days ago
Thanks Volker for feedback!
I can agree to some points you mentioned but still like to comment on others as I still think and being convinced that there possibilituies with little effort.
Yes, its my opinion, and everyone see this differently, i also understand :-)
When joining different rehearsals, there is still lot of discussions on a level ".... for me it works....try this...which fader buffer to increase .... or your answer about working interfaces with mac mini".
This discussions are pain. Why guessing/discussing what to do when making music - and the system could help, if it indicates some more details or errors more understandable.
Looks like I'm not the only one having this intent, have a look at feedback from 'sonicedge' in 'New Jamulus Release 3.5.1'
"..E.g. maybe you can also transmit the individual delay / buffer status LEDs and then show them next to each channel? So it would be quite easy to spot who in the group is the weakest link (and needs optimization efforts)..."
Please let me explain.....I updated my figure according to the following
I agree to
... I would not make it more complex ...
The SW is intended for musicians, so keep the user interface simple I think this should still be the focus.
So adding randomly LEDS for technical stuff like error in the samplebuffer interfaces might confuse. So yes, I would skip to find favor for this samplebuffer errors LEDs.
The reason for people complaining about 'technical' to my opinion might be, that they absolutely do not know what buffers are for, i can understand (my wife does not)!
BUT again, I think everyone knows what TRANSMIT and RECEIVE of audio is,so use this instead of local/server.
So instead lets say, the system has problem to TRANSMIT audio data or problems on the RECEIVE audio path. And yes, this can be buffer errors, but no one needs to know this detail.
There we need separate error LED for the faders. If its red, increase simply the fader belongig to this LED, easy and convenient to understand.
But if LED is meant for both, as it is right now, you start to guess and try playing with both faders if not using 'auto'.
Saying this, having only one LED here is more complex to understand than having two of them!
And yes, there could be real issues with your individual Systemsetup (as you explained in your feedback too, and also in lots of threads).
I agree, systemsetup is not information to be shared realtime to others with new packets, because, yes, the Systemsetup should be corrected before joining a rehearsal room.
Thats the job for the user to do.
We encounter problems especially on windows machines, when running the local server and client same time.
I'm pretty sure, that this is also related to some realtime behaviour of the audio callback handler sometimes causing the samplebuffer to overflow or drain out.
Technically this could be catched by SW (maybe you do it already), but indicating this with samplebuffer error is meaningless for the generic user (he does not understand).
However, this means an error with your SYSTEMSETUP, this is something that can be understood by everyone. So why not indicating this as such to help?
With that in mind I updated my proposal for improvemnt of the jamulus dashboard with 3 error LEDS
SYSTEM - if the SW detects ANY error in the setup, use this. Link this error to states for static or dynamic errors (input/output samplebuffer overflow/drainout). This indicates issues with realtime behaviour or OS.
TRANSMIT - Link this error when buffer on the server side can not compensate the jitter
RECEIVE - Link this error when buffer on the local client side can not compensate the jitter
Also worth to mention, thinking about e.g. breaking changes in future releases, how do you handle the scenario when a client runs with a version that is not compatible with the server.
As a SW developer I know, this can be pain and you have to think about how to handle this in a very early stage
In that case you could do version check when connecting to the server and in case of incompatibility between client/server just set this SYSTEM error led additionally.
In this way, you can add additional error cases to SYSTEM/TRANSMIT/RECEIVE and may be add a tab for details of these errors like you do for profile settings etc. (for people that need more information).
One question, is it like that, that you already transmit the status of the server jitter buffer to the corresponding client?
If yes, why not send all status at the server side to all clients of the session. This should be possible without effort, in that case you could have TRANSMIT LEDS for all users to see if these cause errors or even dont send data (muted/unlit)?
This is really useful, as everyone know, which client is the 'weakest' in uploading audio (TRANSMIT).
I appreciate your feedback on this and hopefully see some improvements in this context.
What do you think?
Beta Was this translation helpful? Give feedback.
All reactions