Remove the LED indicators in the settings window #762
Comments
|
You could at least color the overall delay & ping in green/yellow/red (I don't know if green/yellow is already the case) depending how high it is. I usually don't look at the leds in the main window but in settings. |
Yes, good idea. So the ping time would look like the one in the server list then (they are also color coded). |
|
Any other thoughts on this? If not, I'll do the change for the next release version of Jamulus. |
Yes. But also the overall delay should be color coded. |
|
It was a typo. I wanted to write "Overall Delay". I don't think it makes sense to color code both, ping time and overall delay. This just causes confusion. So: Only the Overall Delay will be color coded. |
Yes. That makes sense. |
|
Sorry, I do not quite understand. In the Settings window,
|
What are your arguments? |
Same here. When I'm playing, there's nothing I can do - I have to live with it. If the sound is good, it's okay. Otherwise, I'll need to go into settings to see what's happening and maybe change things. So, I'm looking at them when I'm checking settings more than when I'm actually playing. The connect screen shows the ping but I want to see the overall delay, so I'll generally start with settings open. The jitter LED needs to be there -- if it's constantly red, there's no point trying. The delay LED I can live without entirely. |
|
My argument would in principle be the same - as a drummer I need both hands to play and therefore while playing with others I cannot change settings. Our trio currently suffers from overall delay - that's why for me the delay LED is important - while playing I cannot read the numbers but the LED indicates the condition good enough. If the jitter buffer LED is important: Please reconsider making the slider colored instead of a separate LED. |
Me too - I don't ever look at the LEDs in the "mixer" panel |
This is really a topic for another ticket, but as a thought experiment: what would happen if you had no LEDs at all and just relied on your ears? I ask because I think the differing views here on which LEDs to show reflect people's differing tactics on what to do if their ears tell them something is wrong. This also depends on how much they understand about the relationship between buffers and other things. I think the whole issue of "telemetry" and what to do about audio issues needs a bit of a re-think in Jamulus to help people understand what to do (for example, a "tradeoff" slider between dropouts and latency has been proposed somewhere). I also made #549 (comment) here about this on visual status in general. I think #756 is also relevant. Fundamentally: the system can show you what is happening, but if you can't do anything about it, then it's a bit pointless. |
|
Yes – these discussions are good. The more I read though, the more I think part of the problem is that this has been focused on the technical client/server/infrastructure solution – which is of course brilliant – and maybe it now needs a bit of input from a proper user experience professional.
I get that we can listen, but not always! I would really like to have an LED to show dropped packets from my client to the server, because otherwise the only thing I can do is join a jam, make sure I’m not muted or faded down, and then listen back to my contribution. Which is great if I am joining at the beginning of a session, but if I drop in halfway through no one will thank me for experimenting with sliders to see how well my signal is breaking up, they’ll just mute me. And of course yes I can listen, but what I am listening to is both the server and the local buffers, effectively in series. Because I’m listening to what I am sending, and then what’s coming back in my mix.
So… Presumably the idea is that I should join a session with myself muted, modify the local – which I think of as the “listen” – slider, then unmute myself and alter the server – which I think of as the “send” - slider.
As these discussions have gone on and on I’ve learnt a huge amount more about how Jamulus works. I now understand much more about the client server relationship, and maybe that the mixing desk you see on the client is more of a monitor mix and not a more traditional mixing desk. But it seems that a lot of the arguments for doing something/not doing something focus on the architecture and not on the user / social aspect of joining a jam.
…Sent from my iPhone
On 9 Dec 2020, at 08:43, Jonathan ***@***.***> wrote:
@pljones
If the sound is good, it's okay. Otherwise, I'll need to go into settings to see what's happening and maybe change things.
This is really a topic for another ticket, but as a thought experiment: what would happen if you had no LEDs at all and just relied on your ears? I ask because I think the differing views here on which LEDs to show reflect people's differing tactics on what to do if their ears tell them something is wrong. This also depends on much they understand about the relationship between buffers and other things.
I think the whole issue of "telemetry" and what to do about audio issues needs a bit of a re-think in Jamulus to help people understand what to do (for example, a "tradeoff" slider between dropouts and latency has been proposed somewhere). I also made #549 (comment) here about this on visual status in general.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Oops – I had a comment disappear and I’m not sure why. Anyway, pertinent to this discussion, and to my workflow above, why not have a new set-up mode, which allows you to unmute yourself and hear yourself coming back – but no-one else can hear you. That way you could check both the local and the server buffers without disturbing anyone, even if you join midway through a session. You could then get used to the delay – maybe by hearing other people – and then exit this set up mode and join properly. Unless I misunderstand that, this is not currently possible in Jamulus but I’m sure it could be done. This would be the best of all worlds and would mean you could be confident in the delay and in the quality of your own signal before joining with other people. It would also be simple enough to check occasionally using this special set up function, that everything is still okay. |
Ideas such as these still beg the question: if you knew that X was happening, how would you know what to do about X? |
I would certainly have more of an idea of which slider to tweak if I had indicators for both server and local dropped packets. A problem on the server buffer would sound the same as a problem on the local buffer, hence needing an indicator for both. And the ability to hear as well as see the result what you were doing with make it very very quick. So, two sliders as at present, LED under each, and the ability to isolate yourself and hear yourself come back before joining a session in progress – that would be perfect. |
|
@marktheharp OK so that would answer the "if you knew about X what would you do?" question (although I'm not qualified to know about the technicalities of showing those things in the UI, or what "dropped packets" means - but that doesn't matter). |
|
In an ideal world, I'd have a "diagnostics panel" showing counts for the following with status lights adjusting when they change:
Most of the places things can go wrong are "reliable" -- it is only the network connection that's explicitly unreliable. But they're all potential sources of drop out and can indicate an appropriate response (e.g. larger soundcard buffers, checking whether Windows has decided to download a major update in the middle of session, etc...). But, like @marktheharp says, being able to hear yourself on the server you're using goes a long way to knowing whether you need to investigate further. |
|
@pljones OK so assuming that "diagnostics panel" isn't available, but we have the telemetry that is currently there in the UI, would it be feasible to suggest some recommended actions in some or other combination of circumstances? For example, you say: larger soundcard buffers, checking whether Windows has decided to download a major update in the middle of session, etc.. So could we expand on that? In other words, if Jamulus show that X has happened, it can clue the user that they should try Y? That would seem more productive an intervention for most people than to simply list (or remove) telemetry indicators. |
|
The point is there are many areas that can have the same effect. Generally the effects cascade. So having an indicator saying "Jamulus had an incoming buffer Xrun" doesn't necessarily tell you what to look for any better than "The client had an Xrun at the server". Both could be caused by any number of things. Basically, like I said, the only thing the jitter LED tells me is "something is seriously wrong" if it's constantly red. It doesn't indicate why at all (it cannot indicate why). ("constantly" being a bit vague. I mean it's on rather noticeably a lot...) You just have to have a poke around to see if anything unexpected has happened. (Like Win10 Updates deciding to re-enable all the services you'd carefully disabled, and so on... I'm getting more and more tempted back to Linux for my jamming PC -- it just needs to handle 15 instances of Kontakt and 25Gb of samples, through non-native VSTis, reliably...) |
|
That’s all really interesting, to peer under the hood of Jamulus. I had a go at running it from Jamulus OS, but on my particular machine I decided that it was just as good in windows, plus Windows is more familiar to me at the moment. I would like to just add, that it’s great hearing stuff about Jamulus, and I feel a real heel for even suggesting changes or enhancements. Maybe what we are seeing in the UI is fairly simple on the surface, and there is a lot of underlying stuff that goes on. |
So at the risk of asking another stupid question: in that case what is the point in having any visual indicators at all if you can hear what the indicator confirms? And to get back to the original subject of this ticket: from what I can understand, there is a relationship between drop outs and delay (the more you have of one the less you have of another). So is there an action that can be performed by somebody who knew nothing of how Jamulus worked that could address sound issues? The UI isn't currently set up to do that, but perhaps it could. |
I can totally live without the delay LED. And the only thing reason the jitter LED is useful is if manual adjustments can't stop it being red - if I'm looking at the settings, I'm not concentrating on the audio. I only need it in settings, as I said: it's no use on the mixer -- that's when I'm concentrating on the audio and will know if something's wrong. |
There is a relationship between drop outs and jitter -- that is variable delay. If a packet could be guaranteed to be available when needed, then the buffer would only need to hold that one packet. But if sometimes the packet is just late enough not to have arrived, then slightly larger buffer is needed. (If the buffer was empty, you'll get an underrun and a drop out in the audio.) So, after upping the buffer, there will mostly be two packets in the buffer, except when one is a bit late. But that's not a problem, as it's not the late packet being processed, so no drop out. If there's still an occasional problem, up bumps the buffer again... But if the buffer is always full, it might mean it can be made smaller. (I'm not quite clear on how those adjustments are managed. That's the principle... From what I vaguely remember, the algorithm was rather complex...) |
|
In my very simple way, this is how I visualise it - I know now that the mixing happens at the server, and what we see on the client UI is essentially a monitor-mix plus some controls, but this helps me with my sound desk understanding of it:
|
|
@pljones Actually you don't want the buffer to be full. If the buffer is full and another packet arrives, the arriving packet is dropped (lost). This condition is called a buffer overrun. Ideally, the buffer is never empty and never full. Both underrun and overrun causes a problem with sound quality. |
|
I personally like having the LEDs in both the settings and main dialog so count me as a vote for keeping things the way they are. When I'm looking at the settings page, I'm there to tweak buffer settings, and it's nice not having to look over at the main dialog to see what is happening. And if it's the case that "you have to listen to the audio to tell if your settings are good anyway" then what's the point of the LEDs at all? I do think moving the LED under the jitter buffer sliders to be just under the local jitter buffer is a good idea. It removes a point of confusion. Surely that's an easy change. As far as having the overall delay LED on the settings page and main dialog, I don't see why that's confusing at all. It's rather nice to have that indicator on both pages. |
|
If I understand the general gist of all this, it's that the presence of flashing lights on the main mixer window is somehow comforting, even though the user can't do anything about them (because they're playing). In Settings, they are slightly more practical as people might use them for visual confirmation of their adjustment to their sound quality. But the lights aren't necessarily saying the same as the sound - see Volker's reasons for removing them for this reason. I'd say removing the LEDs from the main mixer window would be a good idea as it would free up space for more helpful things in future. But the main issue is the fact that only 36% of users report they would know what to do when they hear sound issues (47% say they would "maybe" know) :-) |
Actually, I am using the LEDs in the main window a lot. These two parameters, delay and buffer, are the most essential indicators for Jamulus. That is the reason they are located on the main window. My computer monitor is located right next to my drums so that I can easily look at the main windows when I play. |
OK, but I'm curious about what action(s) you take as a results of seeing them. As @pljones points out, you're playing at the time (usually) so you can't adjust anything, and the lights can't tell you much about what is wrong if you hear a problem. And as you yourself point out, it's your ears that are the ultimate indicator. Of course, the presence of flashing lights on the main mixer window doesn't have to be practical. Perhaps it's just somehow comforting - part of the "psychological experience" of Jamulus, perhaps? That's a good enough reason to keep them. Other music apps have lights that blink with the music, or waveforms and things... |
|
Let's wrap up: It seems that we should keep the current implementation, i.e., have the LEDs in the settings window as well as in the main window. So I think it is time to close this issue. Do you agree? |
|
Personally, yes I agree. I updated to 3.6.2 and then experimented for ages messing about with buffers and ASIO today, and I think if you’re on any sort of a domestic connection that isn’t that great, then you really need the LEDs on that settings panel. The best I can get on my wired connection at home is 60 ms, and that’s variable, but that would be very difficult to be messing about with if I had to look over at the main panel while altering the server and local sliders. I think it might be different for people who are on a stable, fast, low latency connection, and maybe they might need to not need to mess around with the settings so much, but not everyone is unfortunately. |
|
I do not agree 100% because we still have the problem with the location of the Buffers LED in the Settings panel. If shifting this indicator to the slider knob is not wanted/accepted, then we need to move it to the left, underneath the "Local" slider which means to vertically shrink the sliders a bit (which I do not see as a problem). Otherwise to have information duplicated on more than one panel is not a problem from my PoV - what is wrong about it? If the settings panel is not required to be seen, simply close it. |
|
Not specifically about the LEDs, but I'd like to see some indication of dropped packets. I'm chasing a networking issue that "garbles" the sound. Near as I can figure it's in the data the client sends to the server but it's hard to say without more feedback from the engines. |
|
Just FYI: |
Shift the LED to position as per #762 (comment) perhaps? |
|
I also think shifting the LED over to the left would be a good idea. But it's not a big deal to me. |
|
This would be my proposal: |
|
I just reviewed this thread and appreciate the discussion. I just want to offer this observation. There is one use case overlooked. When I have a new user with problems, I much rather ask what do you see in the LEDs instead of what do you hear. (They are not likely to use the right vocabulary for the audio issues to be helpful.) |
Well, in fact there is no vocabulary for the audio issues :-) That, together with the fact that even if there was some kind of understood classification of audio problems ("Are you hearing burbling type A or B?"), there would be no reliable way of knowing what action you could take as a result of hearing them, since different programmatic conditions in and outside Jamulus can be responsible for the same perceived audio distortions. I think @pljones summarises it best #762 (comment) And you can only adjust a few things anyway, so in practice everyone just adjusts them all the minute they get problems. This isn't to say there's nothing we can do to improve that situation of course, but the provision of more (or less) flashing lights and numbers isn't much of a solution right now. I agree that flashing lights are at least comforting though. |
|
I have now applied the proposal in #762 (comment) to the git repo. Since the confusion about the buffer LED is solved now (the label clearly says to what jitter buffer the LED belongs to) and we do not want to remove the LEDs from the settings window (as in the title of this issue), I'll close this issue now. |
The two LED indicators in the settings windows are exact copies of the LEDs on the main windows as shown here:
These LEDs cause confusions as, e.g., written here: #747
Removing the LEDs has the following advantages:
The text was updated successfully, but these errors were encountered: