Triaging and specifying major feature for Jamulus 4

[ann0see]

In https://github.com/orgs/jamulussoftware/discussions/3341 we discussed potential larger features for Jamulus 4.
This discussion serves as triaging the most important and actionable feature we can implement for Jamulus 4.

Step 1: Decide on primary feature to focus on
Step 2: Plan how to get this feature going.

The best outcome would be to have an actionable plan as issue on what to work on exactly in form of a checklist.

We have 4 larger feature requests:

1. Provide uncompressed/higher quality audio.
   2. Add multi channel support
2. Implement Access control functionality
3. Introduce plugin compatibility in Jamulus

[ann0see]

Thread for improved audio quality

[softins]

(talking about Opus)

It would be great to see the updated version and have access to its capabilities.

Yes. But the last time I tested upgrading it, it crashed Jamulus. This shouldn't happen and totally needs investigation.

I have compiled with Opus 1.5.2 and it does indeed crash. I've tracked it down to a change introduced between 1.4 and 1.5, in celt_encode_with_ec() using a pointer that could be NULL without testing for that first. I've registered with https://gitlab.xiph.org to report the bug. Just waiting for my account to be approved.

[softins]

https://gitlab.xiph.org/xiph/opus/-/issues/2381

[ann0see]

Since the fix is available, we could apply it and test for any changes in our repo.

[ann0see]

We'd need to enable the ML features manually: https://opus-codec.org/demo/opus-1.5/

[softins]

Since the fix is available, we could apply it and test for any changes in our repo.

I have a branch in which I am testing. Will raise a PR next week.

We'd need to enable the ML features manually: https://opus-codec.org/demo/opus-1.5/

Haven't looked at what this is. Can be dealt with separately once 1.5.2+ is integrated.

[ann0see]

Thread for multi channel support

[ann0see]

Personally, I don't think we can bring multi channel support easily to Jamulus 4 due to the need of larger restructuring of core functionality of the code. I would rather not add this as to do.

[ann0see]

Can we decide to not have this initially as proposed Jamulus 4 feature?

[ann0see]

Since there hasn't been much discussion in this, I declare this not the main Jamulus 4 feature.

[ann0see]

Thread for access control

[softins]

Maybe, but that's a bit more involved. The client connect dialog would need also to send a CLM_REQ_VERSION_AND_OS to every listed server and process the CLM_VERSION_AND_OS responses, which it doesn't do currently.

[pljones]

Yes or the response to a request for the list of participants could be both the participant list and the CLM_VERSION_AND_OS, which would be ignored if unexpected and processed if expected.

[softins]

Yes or the response to a request for the list of participants could be both the participant list and the CLM_VERSION_AND_OS, which would be ignored if unexpected and processed if expected.

The request for a participant list is only sent to a server that gave a non-zero client count in CLM_PING_MS_WITHNUMCLIENTS and a different count from the previous time. So with that scheme, empty servers would never send the version number. So it would be best if the connect dialog did explicitly request the version when sending a ping to a server, if the version of that server is not already known.

[pljones]

Mmm, okay so old servers are the limiting factor in compatibility for everything -- yeah, sounds like this is the only way.

[softins]

It should be doable ok on the client side. It's only the new version that wants to display the version that needs to send the request for it. It's just more complex than simply displaying the version of a connected server.

[ann0see]

Thread for plugin compatibility

[pljones]

I'm suggesting focussing on CLAP for the reason that it's an open spec without a restrictive licence agreement (Steinberg VST2 and 3 are both restrictive) and has cross-platform support (at least on Windows and macOS - don't know about Linux and probably not mobile).

[ann0see]

Seems as if this doesn't get that much vocal attention even though it's nice and probably doable. Any thoughts on concretizing CLAP support?
I'd like seeing this in Jamulus 4 though.

[pljones]

"Getting Started" page for developers: https://cleveraudio.org/developers-getting-started/ - very much oriented at plugin developers, though.
Host example (using rtaudio, which we'd rip out, of course): https://github.com/free-audio/clap-host?tab=readme-ov-file#minimal-clap-host

[ann0see]

@pljones Could you please raise an issue for CLAP support?
In it we should have:

1. A link to the CLAP repo
2. A clarification that client and server would have CLAP support
3. A general overview what needs to be done to make this happen

[pljones]

Done
#3405

[iamthechrisb]

In https://github.com/orgs/jamulussoftware/discussions/3341 we discussed potential larger features for Jamulus 4. This discussion serves as triaging the most important and actionable feature we can implement for Jamulus 4.

Step 1: Decide on primary feature to focus on Step 2: Plan how to get this feature going.

The best outcome would be to have an actionable plan as issue on what to work on exactly in form of a checklist.

We have 4 larger feature requests:

1. Provide uncompressed/higher quality audio.

2. Add multi channel support

3. Implement Access control functionality

4. Introduce plugin compatibility in Jamulus

These are all great ideas and the group should take ample time to weigh this out. Jamulus had great momentum during the pandemic, but development may need to shift gears to remain attractive to new users. Please don't take that negatively, Jamulus is a great work of software and the team here has done an amazing job. Everyone who has spent time playing is grateful. It's still amazing how well it works and how great it sounds for typical internet conditions.

Has any thought been given to moving Jamulus to utilize the Juce audio framework? I had not seen this topic in the past, and through some basic searches. Juce could allow the development effort make leaps in capabilities rather than building everything from the ground up while allowing core components, such as the Jamulus protocol, to get a fair balance of effort in refinement -- while bringing other capabilities to users. It is used by so many audio applications and very mature. Couldn't this help refocus efforts to get these features up and running -- are there license or cost issues with it?

[pljones]

If you can show an example of a Qt application using JUCE that running on Android, iOS, macOS, Linux and Windows (and supports JACK on both Linux and Windows - ideally we'd also support it on macOS), then it might be worth considering. If we have to ditch Qt, then we're left with nothing but the protocol formats. No code.

Then go check the amount of new code that was delivered in the last year and calculate how long adopting something new would take and decide if there might be a better use of that time elsewhere.

[dcorson-ticino-com]

Sonobus provides a solid study that says it is stable for this type of application -- and has implemented some of the features being discussed.

Sonobus is the least stable of Jamulus' competition in my experience. I would not use it as a good reference. Even JamKazam works better.

[ann0see]

I would rather prefer not to rewrite the whole app. Please note that moving to another framework should have been discussed in https://github.com/orgs/jamulussoftware/discussions/3341 instead.

See the initial post:

This discussion serves as triaging the most important and actionable feature we can implement for Jamulus 4.

Step 1: Decide on primary feature to focus on
Step 2: Plan how to get this feature going.

[iamthechrisb]

I would rather prefer not to rewrite the whole app. Please note that moving to another framework should have been discussed in https://github.com/orgs/jamulussoftware/discussions/3341 instead.

See the initial post:

This discussion serves as triaging the most important and actionable feature we can implement for Jamulus 4.

Step 1: Decide on primary feature to focus on
Step 2: Plan how to get this feature going.

that post probably needed more time

[ann0see]

The goal was to get to the most important and requested features for Jamulus 4. I expect that the most important ones would get in quite quickly.
We must triage and decide on what to do at some time. Having it around the release seemed sensible for me. You can always open a new discussion/issue.