Jamulus
Replies: 12 comments 53 replies
-
|
Those are all behind the scenes things that will make things better for some, but hardly a reason for a major version change. IMHO the most pressing improvement would be to add uncompressed PCM to have better sound quality. (our biggest advantage compared to the competition is that Jamulus never crashes. Never a break to reboot or people getting lost, which is common for our competition. Jamulus just works.) I had an uncompressed version, with a 5th audio quality "best", almost working, but never found what was causing buzzing at times and gave up. Unfortunately I don't have the time to pick this up again in the near future. |
Beta Was this translation helpful? Give feedback.
-
|
Agree. Sound quality is also a thing I heard about in the past. |
Beta Was this translation helpful? Give feedback.
-
This is dependent upon two separate points:
On the Qt6 point above, we may also want to move entirely to Qt6 for a more consistent UI look-and-feel across platforms. However, getting good UX on mobile and desktop devices will need more than just Qt6, it needs a complete reworking of how the UI components are handled (on different runtime platforms). |
Beta Was this translation helpful? Give feedback.
-
|
I think we also need to review the build processes -- it needs to be easier for a developer for a specific platform to understand how they can proceed locally with development for that platform. Currently there's probably too much reliance on Github tooling, rather than on platform tooling. (I don't mind pulling in a Github build platform image, so long as we keep that to current, supported releases of the platform and we can say how to install - by hand, from a version supported by its supplier - each of the needed tools to build the artefacts we build on that image.) |
Beta Was this translation helpful? Give feedback.
-
|
So you're saying we should ensure that each OS has a build script and working + tested setup guides. I think although we aren't there yet fully, it's doable. |
Beta Was this translation helpful? Give feedback.
-
|
I'm saying any developer for a platform should be able to develop for that platform without reliance on Github to do the builds. Not only does this give the developer faster feedback (i.e. they don't need to wait for the Windows ASIO build) by allowing them to test and fix locally, it also enables the Jamulus project to have less dependence upon Github, should there ever come a time when it can no longer be used. |
Beta Was this translation helpful? Give feedback.
-
|
Linux -> Works |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, two out of five is what I mean - it's not that good. And for Android, it needs to work on Windows and Linux based development systems (and MacOS, if it supports Android development), ideally directly inside QtCreator. (QtCreator on Windows sucks. I don't know how they've managed to make it run so slowly - it runs as slowly on my shiny new 32core CPU as it did on my old 8core.. They must have single threaded absolutely everything (including syntax checking, highlighting, etc). I generally use the Linux version remotely desktop'd because of that!) |
Beta Was this translation helpful? Give feedback.
-
|
Multi-channel support would be another great addition for a major version. Currently Jamulus supports a stereo pair meaning that users have to mix in a vocal using patchbay/Blackhole/VoiceMeter or some analog mixer solution. With multichannel interfaces that shouldn't be necessary. Along with uncompressed PCM, being able to send, and therefore record, multiple channels would make Jamulus a very good recording utility. |
Beta Was this translation helpful? Give feedback.
-
|
Multichannel support is a problem for Jamulus. |
Beta Was this translation helpful? Give feedback.
-
|
Understood. I just felt the topic was searching for those potential, significant changes to warrant a new version. I guess Sonobus can achieve it more easily peer to peer, but that is a great feature it has. As has been highlighted, we use Jamulus because of its relative simplicity and robustness so that shouldn't be lost. I just wish I could mute all the microphones bleeding in (or rather I wish my bandmates would mute their microphones bleeding in)! |
Beta Was this translation helpful? Give feedback.
-
|
If the problem is just muting micros a two channel version would work and would let you mute them. |
Beta Was this translation helpful? Give feedback.
-
|
A "multi-channel client", in Jamulus terms, would be exactly the same as running multiple instances of the client -- just with the advantage on Windows ASIO of having a single ASIO connection, which some ASIO drivers might find helpful. It would make multi-platform support even harder, of course - it's hard enough currently keeping the simple view of different platforms' ways of providing audio channels coherent. To add cross-platform multi-channel support is certainly do-able (in the sense above - instantiate multiple client connections to the server for each audio in mono or stereo pair) but would probably take a few years to achieve. Given that on all platforms there are alternatives (either via JACK on Windows or the platform itself) using multiple instances of Jamulus already, the time spent on it might not be considered that worthwhile if there were other goals that could be achieved. |
Beta Was this translation helpful? Give feedback.
-
|
Related to: #516 I don't think that we will get multi channel support in Jamulus 4. PRs are still welcome, but this could require a lot of work. |
Beta Was this translation helpful? Give feedback.
-
|
Access control functionality. As I understand it, @Rob-NY has already submitted RPC code updates awaiting approval to be merged that provides new RPC calls to manage access to server by IP address. |
Beta Was this translation helpful? Give feedback.
-
|
I have only seen this feature used in petty, hostile ways that diminish the utility of the mesh network. |
Beta Was this translation helpful? Give feedback.
-
|
The potential to have permitted clients utilize the RPC interface to manage access to the server while in a session would be a useful function, and relieve the permitted client of the need to ssh/rdp/www into a server and add a firewall rule, interrupting/delaying playing. (Yes, it would mean running the RPC listener on a WAN interface, not localhost, but access to that could be defined once in a firewall config, sharing the JSON-RPC "secret" to predetermined client(s), inputting that value into a field in the Settings dialog for example) Adding functionality to the server GUI log dialog box to select then block using the backend RPC interface could prove very useful as well for those that run a server from their home connection and may not be familiar with or permitted to alter their routers/firewalls. @mcfnord It's not surprising you'd only see it that way given you have a personal stake in this as you, and your bots, are blocked on a number of servers. That is a situation of your own making, and doesn't bear on the ACL discussion at large. What you perceive as petty and hostile sounds like a personal issue best left off this discussion. I see firewalling being used in healthy, productive ways, benefitting player communities and server operators. The utility of the mesh network isn't diminished at all. Directory servers aren't blocked, indexers like explorer.jamulus.io aren't blocked. A user being blocked on a server has no impact whatsoever on the mesh network itself, or the rest of the users using jamulus. @pljones I can understand your feelings on this. Thanks for the explanation, it's much appreciated, and thanks for your consideration. |
Beta Was this translation helpful? Give feedback.
-
Off topic. |
Beta Was this translation helpful? Give feedback.
-
I don't think you can compare a corporation like Google with the providers of the public Directories. That's stretching things a long way. |
Beta Was this translation helpful? Give feedback.
-
|
Related to: https://github.com/orgs/jamulussoftware/discussions/1057 Feel free to discuss further in this discussion. I think even though it's possible to implement this, we'd need to agree on what is acceptable and what isn't. |
Beta Was this translation helpful? Give feedback.
-
|
Random ideas to consider, some of which may have been suggested long ago but deemed too hard or inappropriate at the time...
|
Beta Was this translation helpful? Give feedback.
-
|
The details on using a Script to run multiple instances on Mac are accurate. BUT using a Script is only necessary if you care about having separate INI files for each instance. A simpler solution on Mac for the person who only needs 2-3 instances (and one that I detail in my doc, which is linked from https://jamulus.io/wiki/Tips-Tricks-More already) is to make a copy of the Jamulus application (Jamulus.app in the Applications folder) with a different name, then run both (or many) - as each is launched, it will have the (single) INI settings, but then can be manually updated before connecting to a server. When quitting the app, the INI file will be overwritten by the settings from the last instance running. |
Beta Was this translation helpful? Give feedback.
-
|
Is it simpler to lose settings you thought you'd changed? As far as I can see, without passing the ini filename explicitly, there doesn't appear to be a way for a Mac app to know where it's run from and guess either it's name or directory. I could (likely) be wrong - I'm basing this on uninformed Google searches that might not even be asking the right question. |
Beta Was this translation helpful? Give feedback.
-
|
You're correct: MacOS doesn't care about the location of the app - it looks for the INI file in a pre-defined location regardless of the app location. So scripts are the only way in which a user can specify a unique INI file (whether running multiple instances or not). Yes, you could lose settings you thought you'd changed, but the harm isn't significant. Worst case, you run Jamulus and have the wrong Audio Device selected, the wrong Name/Icon/etc., and maybe a couple other settings that you have to update before Connecting. It only takes a moment to fix all that. When the WorldJam was active (during Covid), I was regularly running 3 instances of Jamulus without using scripts, and just ensured that I quit last the app instance that had settings I wanted to retain in the INI. An advantage to NOT using multiple INIs (via scripts) is that settings related to Solo, Mute, etc. are true for all app instances, rather than being maintained separately. This is particularly handy when all the app instances will be connected to the same server. Keep in mind that only more-technically-capable users are likely to be running multiple instances, so they're less likely to be bothered by the need to update some settings when running the app. A v4 feature might be to add an INI Location field to Jamulus, allowing the user to specify the file to be loaded, with a Load button. Then a user could run Jamulus1.app and Load their INI1 file, followed by running Jamulus2.app and Load their INI2 file (which they made by copying INI1). Over time, the two INI files will diverge, but the user with multiple instances won't need to use scripts to access them. |
Beta Was this translation helpful? Give feedback.
-
|
Without a substantial rewrite of the application, reading the inifile at anything other than application start up won't happen. There have been at least two attempts at rewriting the inifile handling, both of which failed to produce an improvement, so far, so I wouldn't hold your breath on "load whilst running" happening soon. (Jamulus determines if it's "client" or "server", instantiates the settings object for client or server from the appropriate inifile and then instantiates a client or server, passing it the settings object. It would need to re-instantiate the client or server after looping back out to re-read the updated inifile if the location were changed "on the fly" - and, if the location had been passed on the command line, it would still use that location instead... unless something even more confusing happened...) |
Beta Was this translation helpful? Give feedback.
-
|
@chrisrimple Could you please open an issue on the mixer board change and sum up the discussion here? I think this could be part of Jamulus 4 - if we are clear on what to improve. |
Beta Was this translation helpful? Give feedback.
-
|
See the Audio Device dropdown, which has both IN and OUT in a single list. I propose that they be broken up, with an IN dropdown above the Input Channel Mapping controls and an OUT dropdown above the Output Channel Mapping controls. |
Beta Was this translation helpful? Give feedback.
-
This does not fully hold true for macOS and iOS. In macOS the standard audio system is capable enough. The user selects the correct input output tuple from the Cartesian product of input and output devices. And this is as user unfriendly as it sounds. |
Beta Was this translation helpful? Give feedback.
-
|
OK, so we should say "Core Audio" for the audio device and lock it? Presumably there's a reason it's like it is... Can you take inputs across different hardware inputs, for example, and retain buffer synchronisation? |
Beta Was this translation helpful? Give feedback.
-
Not sure. But there's a clock synchronization toggle in audio/midi setup on macOS - the application where you configure advanced audio settings. |
Beta Was this translation helpful? Give feedback.
-
|
Hopefully the core audio api would support an application turning that on, if needed, too. Sounds like what we'd need, I think. |
Beta Was this translation helpful? Give feedback.
-
|
Related to: #3216 @pljones can you copy your suggestion into this issue please? |
Beta Was this translation helpful? Give feedback.
-
|
Some Jamulus' sessions are enviably professional, hosting amazing musicians. To me, it would make sense to have the focused server able to record better quality audio (no lossy audio stream as alluded before but also adjustable sample rates 48 to 96 mHz and bit depths of 24 or 32).
To developers and supporters , my sincerest thanks. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think I'm getting what you're after at all. First, I'll just say the 16bit 48KHz audio is likely to be part of what Jamulus is for a while. It keeps the clients and servers in sync without the server having to do too much work resampling (and thus losing more audio signal to noise). The mixer you see in Jamulus is sending instructions to the server, you understand. The server does all the mixing for all the connected client channels. Up to 150 stereo channels in, 150 stereo channels out, currently. Each of those up to 150 clients only sends or receives a single (mono or) stereo pair. So the client has nothing to do mixing with. The audio data is only in the 150 separate streams on the input side at the server before the mix happens. That's where the server recorder currently captures the data. Currently, all audio gets compressed, yes. There's already a patch around, I believe, to work with PCM data in place of OPUS compressed data. That's not too hard, and can be done in a backwards compatible way (allowing existing clients to connect to a PCM+OPUS server and choose whether to use PCM or OPUS data). The issue isn't whether it's compressed or not. It's that the Jamulus server is the mixer. That's how Jamulus works. If that's not what the server is doing and you want peer to peer audio, then you don't want to be using Jamulus. If you want to work with the server recordings, that's fine - Audacity and Reaper projects are both plain text files and the audio is 16bit LPCM WAVs (and, as I say, that's likely not to improve in V4 unless someone wants to show a V3-compatible audio engine for the server that can do it). |
Beta Was this translation helpful? Give feedback.
-
|
Lossless will be nice for those with accomodating bandwith , but what beyond ? In case of different bit-depth/sampling (characteristics) of inputs, I see the point that with backward compatibility ("don't break anything" rule) a server could not mix different characteristics streams without resampling some and possibly "...losing more audio signal to noise)...". But even legacy support is bound to have its limits (Jamulus 1x , 2x , support for Mac pre-X , Windows pre-XP ? ). I doubt Jamulus is stuck at 16b/48mHz forever ( or at least all it's future existence, which I hope very long :-) so eventually Jamulus will evolve to use better audio quality ; channels/depth/sampling or whatever better ( AD/DA or else ) standards will come along and become norms. So maybe this is a suggestion for version N roadmap then, not 4.x. |
Beta Was this translation helpful? Give feedback.
-
|
Working on the basis people generally update the client, we can look at Jamulus Explorer to see what the rule for the server is. The oldest looks to be is 3.4.2. I think that may have been the first that required registering with a directory - rather than needing to be set on the directory command line - and the server providing its version number. However, the oldest tag in git is 3.4.3 (2018-05-17). 3.4.4 (2020-03-25) brought server-side recording ... and then Covid hit! During Covid, the previous quarterly-ish release cadence picked up to once or twice a month for a while. 3.4.5 (2020-04-04) upped the number of clients to 50; 3.4.6 (2020-04-09) added the mixer channel meters for visual reference; 3.4.7 (2020-04-11) added a second directory, as Covid had flooded the original one. 3.5.0 (2020-04-15) allowed the client to choose which directory provided the server list - but not in the connect dialog; 3.5.3 added multi-lingual support and dropped Qt4 because of that, IIRC; it also added the multi-channel audio settings support, plus recorder improvements (with a fix in 3.5.4) and putting the directory dropdown in the right place. 3.5.11 (2020-09-19) finally brought update checking - so we can assume the may be both clients and servers out there before that but that clients, at least, should be getting notified of any updates. However: the check is only on start up and a "no GUI" (headless) Jamulus instance only logs the notice to stdout, it can't issue a pop-up, hence the few servers older than that. 3.6.0 (2020-10-25) dropped the ability for a directory to pre-register servers on start up at all in favour of server registration. Hence most servers are 3.6.0 or newer. Most of the changes during this period (April 2020 to December 2020) were usability improvements rather than architectural, plus bug fixes. 3.7.0 (2021-03-17) rewrote the build system and new directories on a new domain were introduced - both major changes. This was also the first release after Volker passed on support of Jamulus. (This was the only 3.7.x release.) 3.8.0 (2021-06-02) made a breaking change to the server - a truly breaking one, meaning clients from before Feb 2013 (3.3.0) could no longer connect as they didn't not start sending audio before hearing back from the server. There was a lot of soul-searching. It also made Qt 5.12.2 the main platform, introducing the "legacy" 5.9.9 build to continue supporting macOS 10.10 to 10.12 (July 2017 to September 2019), again, trying hard to maintain support for legacy platforms. It also featured some significant UI changes. 3.8.1 (2021-10-23) and 3.8.2 (2022-02-20) followed with minor changes, plus improved experimental iOS and Android support. 3.8.1 slipped in the IPv6 changes, too. 3.9.0 (2022-07-29) introduced the experimental (still) JSON-RPC interface, gaining the x.y.0 bump. Lots of minor GUI, tooling and packaging changes and Qt6, too! 3.9.1 introduced Qt5 compatiblity back into the ISO country code handling to enable Qt5 and Qt6-based clients to understand each other. Plus sundry usability improvements. 3.10.0 (2023-09-03) Dropped pre-Windows 10 64bit support with the move to Qt 6.5.2 (use 32bit as "legacy" build). MacOs legacy now built on 13.1 which isn't officially supported by Qt 5.9.9, so macOS "legacy" is looking close to end of life, too (flagged as deprecated in the release notes). Otherwise mostly internal changes. The coming release is pretty much more of the same - internal changes, trying to keep up with dependencies, plus bug fixes and some small feature improvements. But anything that looks like breaking support for older versions has to be looked at carefully. We still have that 3.4.2 server. Clients prior to 3.8.0 could still be using any server older than 3.8.0, too (but are not supported on newer ones). |
Beta Was this translation helpful? Give feedback.
-
|
@pljones could you point me to that PCM patch please. With that I could probably have a working PCM version quickly. |
Beta Was this translation helpful? Give feedback.
-
|
I think it was probably what you were working on :) |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to close this discussion after the release of 3.11.0 and open a new one for deciding and prioritizing. |
Beta Was this translation helpful? Give feedback.
-
|
To sum up the intermediate state: I think the top requested Jamulus 4 feature is improved audio quality. Afterwards thinking about multi channel support, ACL and the other mentioned features. |
Beta Was this translation helpful? Give feedback.
-
|
The reverb should probably go into advanced settings first. But I'm already seeing negative community reactions if we remove it. |
Beta Was this translation helpful? Give feedback.
-
|
I guess adding CLAP support might not be a bad thing, if feasible. It should be possible on both the input chain and output chain, I'd think, without any investigation. |
Beta Was this translation helpful? Give feedback.
-
|
From some quick research it seems nice but since it's "new" there might be some quirks. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks folks. The logic in my thought/idea was that everyone can switch down to the lowest setting, if it were available, without resampling, but not every device can easily switch up. For audio quality in general the input from our band members is so variable with artifacts, ground loops, cats, children, network glitches etc that sample rates and bit depths are pretty much irrelevant! Obviously having the option to go better for recording and overall audio improvement is something to be strived for, but low latency and simplicity rightly trumps premium quality audio imo. +1 on not requiring reverb - as noted that's either a plugin, but ideally should already be there in the source if olk want it. That said it is a feature that's used often by vocals so I think there'd be upset if it were lost. |
Beta Was this translation helpful? Give feedback.
-
|
@pljones I think it's worth opening an issue on CLAP support. |
Beta Was this translation helpful? Give feedback.
-
|
I will close and summarize this discussion tonight due to the release of 3.11.0 Then we can start linking issues and planning further steps. Please add final thoughts if needed. Feel free to find and link or create new issues. |
Beta Was this translation helpful? Give feedback.
-
|
To sum this up: We have 4 larger feature requests:
All of those were already discussed or touched upon somewhere but have implementation/philosophical questions. Smaller topics were reworking UI components (restructuring how the UI works, redesigning driver/audio device selection, rethinking how the mixer board user information looks like). Usability/Documentation wise, we should streamline the development process and make (installing/)updating servers easier. Infrastructure wise, questions were raised for more reliable directory servers. While not all of those points are actionable, I think in the next step we should focus on triaging one or two bigger of the feature requests from above. For the smaller topics raised, I think issues should be raised. Please do so! |
Beta Was this translation helpful? Give feedback.
-
|
Triaging discussion is out: https://github.com/orgs/jamulussoftware/discussions/3382 |
Beta Was this translation helpful? Give feedback.
-
With the project for Jamulus 4 already existing (https://github.com/jamulussoftware/jamulus/milestone/9), I think it makes sense to define a broader goal roadmap for Jamulus 4.
By definition Jamulus 4 would introduce breaking changes like more IPv6 support and potentially larger scale improvements.
Moreover, this should be a larger release and must be well planned.
So far I see the following feature:
Architectural changes:
User visible changes:
Project changes:
I would like to start a discussion on how we want to make 4.0.0 look like. Please your thoughts about long term goals!
Beta Was this translation helpful? Give feedback.
All reactions