Skip to content

Rawaudio dev#3653

Draft
dingodoppelt wants to merge 26 commits intojamulussoftware:mainfrom
dingodoppelt:rawaudio-dev
Draft

Rawaudio dev#3653
dingodoppelt wants to merge 26 commits intojamulussoftware:mainfrom
dingodoppelt:rawaudio-dev

Conversation

@dingodoppelt
Copy link
Copy Markdown
Contributor

@dingodoppelt dingodoppelt commented Apr 17, 2026

Add a new "raw" audio quality setting

This PR adds uncompressed audio ("raw") to the quality settings so there is no Opus compression along the way
Discussion in #3654

This feature improves latency as well. I gained 2ms by using uncompressed audio while having a better audio quality.

This is work in progress, please help me test it

Checklist

  • I've verified that this Pull Request follows the general code principles
  • I tested my code and it does what I want
  • My code follows the style guide
  • I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
  • I've filled all the content above

@dingodoppelt dingodoppelt marked this pull request as ready for review April 19, 2026 06:54
@ann0see ann0see added this to the Release 4.0.0 milestone Apr 20, 2026
@ann0see ann0see added this to Tracking Apr 20, 2026
@github-project-automation github-project-automation Bot moved this to Triage in Tracking Apr 20, 2026
Comment thread src/clientsettingsdlg.cpp Outdated
Comment thread src/util.h
AQ_NORMAL = 1,
AQ_HIGH = 2
AQ_HIGH = 2,
AQ_RAW = 3
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I said in the discussion- introducing a message specifying Raw support would be the cleanest approach to avoid the noise.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should be possible to do within the existing PROTMESSID_NETW_TRANSPORT_PROPS. But I have never analysed the way the two ends negotiate, or even whether it is an actual negotiation as opposed to just a notification.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But if that didn't work, yes, we would need a message exchange so that we had backward compatibility in both directions.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should be possible to do within the existing PROTMESSID_NETW_TRANSPORT_PROPS. But I have never analysed the way the two ends negotiate, or even whether it is an actual negotiation as opposed to just a notification.

I managed to get rid of the noise.
I added a version check so the client knows if the server can handle raw audio and if not the client will fall back to opus. This is backwards compatible and the changes made only affect the client.

Comment thread src/client.cpp
// free audio modes
opus_custom_mode_destroy ( OpusMode );
opus_custom_mode_destroy ( Opus64Mode );
}
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to cause issues from time to time. After closing the client I sometimes get an error with free() complaining about wrong sizes. Needs further investigation. Some help here would be appreciated

@ann0see
Copy link
Copy Markdown
Member

ann0see commented Apr 20, 2026

I'd prefer not to check for the Jamulus version number but rather based on capabilities - we don't have 4.0.0 out yet and it might break during the dev process.

@dingodoppelt
Copy link
Copy Markdown
Contributor Author

I'd prefer not to check for the Jamulus version number but rather based on capabilities - we don't have 4.0.0 out yet and it might break during the dev process.

I wanted to reuse information already available as much as possible so I just added the code where there were version checks already implemented. (For sequence number and pan feature)
Capabilities would be nice but also would require more changes to client, channel, server and protocol which I don't really have an idea on how to make that backwards compatible. We should rather replace all version checks with some capabilities struct that client and server can agree upon so everything lands in one place. I just don't feel like the right person to take on that challenge and rather pursue my hacky approach, as long as it works for everybody.
The version check with 4.0.0 could be replaced by a point release 3.11.1 and would work right away.

@ann0see
Copy link
Copy Markdown
Member

ann0see commented Apr 20, 2026

Tested it and yes, the noise would be unacceptable. What is our fallback if max is selected but the server doesn't support it?

@dingodoppelt
Copy link
Copy Markdown
Contributor Author

dingodoppelt commented Apr 20, 2026

Tested it and yes, the noise would be unacceptable. What is our fallback if max is selected but the server doesn't support it?

I just noticed that if you connect to a server with Max selected you get the noise unless you switch audio quality again while connected. The server code is fine and doesn't need changes, I misplaced the check for my introduced bRawAudioSupported in the client code. I'll have a closer look
Edit: Funny, the noise doesn't happen on legacy servers, only on rawaudio :D

@dingodoppelt
Copy link
Copy Markdown
Contributor Author

Adding a slot to the client to reinit when it receives the server version seems to have fixed the noise issue.

@dingodoppelt dingodoppelt marked this pull request as draft April 21, 2026 22:12
@dingodoppelt
Copy link
Copy Markdown
Contributor Author

We still get crashes on windows, especially when using more coplex setups including audio routing software. Linux, Mac and android builds work fine so far. Sounds great but still needs more testing and fixes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Triage

Development

Successfully merging this pull request may close these issues.

3 participants