jamulussoftware / jamulus

Jamulus enables musicians to perform real-time jam sessions over the internet.
https://jamulus.io
Other
999 stars 223 forks source link

Diagramming Jamulus #64

Closed gilgongo closed 4 years ago

gilgongo commented 4 years ago

I've had a go at trying to explain the basic Jamulus configuration in diagram form with a view to putting this on the wiki for non-technical users.

EDIT: Following discussions below, here's the latest versions

BTW I'm using this to make the diagrams the basic version of which is free for non-commercial use and lets you save the files externally. There might be a better one though. It was just the first I found on Google.

Overview

For people who just need to get the general idea:

Overview

Public Server At Home

PublicServer

(I was trying to keep the diagrams wide rather than deep so they wouldn't need too much scrolling on the page, but I might move the central server down a bit so the signal path can be straight like it is in the diagram below)

Private Server At Home

PrivateServer

ann0see commented 3 years ago

I think this diagram would go somewhere where more experienced users could find out more about how Jamulus works technically (e.g. a specific page in the community KB which describes how jamulus works in a more detailed way.)

drummer1154 commented 3 years ago

@gilgongo What I am referring to is e.g. this: http://behringerwiki.music-group.com/images/1/11/X18-XR18_block_diagram.pdf

As to your question "... would it matter" - I agree that this is a valid question. The reason I came across the block diagram was when I started using Jamulus with our band, nothing worked and - as engineers - we started troubleshooting by trying to understand how the service is supposed to work. Volker's 2015 "case study" was a good starting point, and besides the text describing the principle, it contains "Figure 2: Simplified Jamulus block diagram", which, however, does not show how the "Personal Mix" feature is supposed to work. So I was completely mislead by "This mix is again compressed with OPUS and transmited [sic] to all connected clients ..." suggesting that there is only ONE mix - where in reality there are as many as clients are connected. So it mattered to me and this was the main reason why I considered updating Volker's diagram.

One thing I wonder about is how "personal mix" works.

Are you kidding? But if you are seriously putting this question then I am even more convinced that the documentation needs to be enhanced.

What I am saying now is pure guessing, taken from the information read in several discussions and needs to be confirmed by the Jamulus architects (mainly @corrados). But for me it is obvious that - as in a "real" mixing console - in the server there are attenuator and pan functions which are controlled by each client's GUI elements and transferred via the "Control" channel. I did not yet take up any such function in the diagram as from my PoV it is a more deep down detail which is, however, not really required to understand the overall principle. I would like to continue with the diagram on a next page giving something like an "exploded view" of those functions (as well as the "real" audio routing in the client so as to show how "Mute Myself" is working and that it violates the "golden principle" "ONLY. LISTEN. TO. THE. SIGNAL. FROM. THE. SERVER!", maybe a bit better than the drawing above :-).

As to where to finally make such a diagram available to the public - this should be left to the people who are currently doing most of the valuable documentation on jamulus.io - in so far I absolutely agree to @ann0see above.

But what I would strongly request is a quick guide to "where to find what" and where to enter contributions, maybe kind of a "tree view". When I (of course in a state of frustration because nothing worked as expected) documented https://github.com/jamulussoftware/jamuluswebsite/issues/174 - which then was commented to be in the wrong repository - I blindly followed the advice given in https://github.com/corrados/jamulus/issues/778#issuecomment-743774622 ...

WolfganP commented 3 years ago

I would change the "audio compression / decompression" labels on server side as it may imply a compressor effect on audio which is not what's happening. Probably "audio encode / decode" may fit better.

drummer1154 commented 3 years ago

@WolfganP 100% agreed, thanks, taken over thoughtlessly from Volker's paper. Will be changed on Client also in the next edition. !!CoDec!!

gilgongo commented 3 years ago

@drummer1154

What I am saying now is pure guessing

OK so when you ask if I'm kidding (I wasn't, BTW) you mean you can't answer that yet, or that it's too low-level a question for the diagram as it currently stands? I'm a bit unclear.

when I started using Jamulus with our band, nothing worked

I think you've said that before and I've been meaning to ask: to what extent was that "not working" due to the fact that the Jamulus client's UI presents itself as a mixing desk? I have wondered whether it might be the case that the more familiar somebody is with real-world mixing desks and sound engineering, the greater the likelihood of them becoming confused with Jamulus when it doesn't behave in exactly the same way. It's just a hypothesis, but your statement about being an engineer and "nothing worked" seems to support the idea so I'm curious.

drummer1154 commented 3 years ago

@gilgongo Please don't get me wrong - I do not want to express any emotions towards any other person.

[is it] too low-level a question for the diagram as it currently stands?

Absolutely not - I only want to say that I do not have all the knowledge which the creators of the SW have, and I am absolutely not able (and also not willing) to reverse-engineer the source code to gain the information required to create a complete and accurate diagram. Therefore I need help from these experts - at least review.

As it stands now my diagram is e.g. missing the stereo signal capability, but I believe this is again a next deeper down level of information (which I cannot add because I do not understand the mechanism behind Settings - Misc - Audio Cannels (Mono; Mono-in/Stereo-out; Stereo) - according to my tests documented in https://github.com/jamulussoftware/jamuluswebsite/issues/174#issue-765437110 a lot of unexpected things happen when you change this setting).

to what extent was that "not working" due to the fact that the Jamulus client's UI presents itself as a mixing desk?

To none. The GUI is OK for me (with an open gap for some small changes which could remove unnecessary inconsitencies as e.g. discussed in https://github.com/corrados/jamulus/issues/778 (from my PoV just the relationship between L/R channel and slider up/down movement should be consolidated to a "natural" feeling - but especially there you see that excessive expectations from some users may not meet the developer intentions at all - leading to the developer apparently going into fold-back).

My initial problem was that key facts are not stated prominently in the documentation (e.g. Jamulus only supports 48 kHz sample rate (prio 1), it only supports IPv4 (prio 2) etc. - one of the reasons why I supported creating the table in https://github.com/corrados/jamulus/issues/763) so that after having removed the primary obstacles I still was unable to hear my vDrums via Jamulus - just because I was not aware of the fact that I need to connect to a server or else I will not be able to hear myself. I do not want to copy/paste my input from https://github.com/corrados/jamulus/issues/712 here but I want to state: would there be a sound audio block diagram covering all technical aspects, a lot of problems could be solved without the need to call for help from any of the Jamulus support/development platforms (I believe that in 90% of the cases the root cause is on the user side - or it cannot be resolved due to technical reasons - but please also see in https://github.com/corrados/jamulus/issues/712 the fact that my interface tells me that something in the "application" (as the manual says it, i.e. Jamulus) has not set up the interface correctly - and the difference in mindsets is that even if it is working somehow, I can hardly accept this, while someone else would certainly say: it's working so why worry).

Latest version: JamulusABDv104.pdf Edit: Sampling rate added. JamulusABDv105.pdf

ann0see commented 3 years ago

My initial problem was that key facts are not stated prominently in the documentation (e.g. Jamulus only supports 48 kHz sample rate

The sample rate problem will be documented in the upcoming version of the documentation. So this will be fixed.

it only supports IPv4

This is already documented on the server setup page. You can nevertheless open an issue to make this fact clearer in the documentation repo. (Use the bug report or feature request template).

drummer1154 commented 3 years ago

I have taken up the sample rate into the diagram v105. Sorry to be late - it came to my mind in the very moment when I uploaded v104 :-). I want to have the important things in the diagram - a picture is worth a thousand words - and I am rather going to create the next drawing for the client audio than initiating a discussion how and where to put the according verbal description - other people are able to do this better than me.

ann0see commented 3 years ago

I just found this: http://www.aesmelbourne.org.au/wp-content/media/Nov2020_slides.pdf

Maybe we can ask FABIO MARRACCINI if he allows us to use some of his slides?