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
- UP-stream/path error LED is indicated when there is a problem in 'input-samplebuffer' OR 'Server' jitter buffer
-- 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?
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
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
- UP-stream/path error LED is indicated when there is a problem in 'input-samplebuffer' OR 'Server' jitter buffer
-- 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 2020-04-23
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.
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?
Last edit: mmatt 2020-04-25
I have just created a Github feature-request Issue: https://github.com/corrados/jamulus/issues/150
We should continue the discussion in that Issue instead of here, then it is easier to track feature requests.