pcmjam
A project reworking Jamulus to use straight 16bit pcm/48k audio - no compression. How would it sound? Would the mix get mushy with larger groups? Could it be done? There have been mentions of a version of Jamulus that was pcm based — but never heard of it working reliably, and couldn’t seem to get a copy. Someone’s got to make it happen..How hard can it be :-) Jamulus does really well with opus and offers a great balance of bandwidth/latency/sound quality and there has been excellent work done to make it what it is. While opus will likely remain as the optimal option for most, Jamulus has competition from platforms offering pcm + opus + various bit rates, depths — Can’t Jamulus? We almost have an entirely new internet (better) than a few years ago with many more folks that can support more bandwidth. I’ve always felt that Jamulus has a potential advantage for pcm due to server side mix vs a p2p solution - the numbers work better. Maybe this can help, perhaps someone more experienced in the art of c++ can get some ideas here.
This version works, it sounds great — clearer and higher highs and strong lows. It has been tested with ~100 users with jam sizes from 5 - 25 users. Mixer seems to behave the same with a larger group. While it has not been ‘bench’ tested for audio response or to validate delay numbers - we did it by feel and ear, it was good, a proof of concept.
How: by extending the buffer code to handle 16bit.. This also involves being able to separate jamulus proto data from pcm audio, padding 8bit jamulus protocol messages in 16bit structures.. There’s a few things I did there that appear to eat some more cpu.
Caveats: Jamulus is the first c++ that I’ve studied and worked with in any depth. I’m not very strong with git as well. This repo was the 11th rewrite of pcmjam/jamulus and I called time on it after getting to a working stopping point. Originally, it was intended to support opus and pcm, and different bit depths, then I realized I was taking on too much.. It’s messy with a lot of AI garble, much that could be cleaned up. I had originally intended to get back to it and refine, but I’d rather get this out for anyone to be able to study and play with. Again, just a proof of concept.
-was only tested at settings for best latency, above this I think we have a math problem and delay would be too high.. -F on server 64/small clients -must have auto jitter buffer on when entering a session or audio does not start -‘mute myself’ missing in client code - -requires some additional server cpu due to filtering of jamulus photo vs pcm audio 8/16 bit… -stock jamulus client will be disconnected from pcm server and send a message to user. It works sometimes..It was a last minute add to help avoid confusion if someone ran one of these servers and registered it on public list - highly recommend a separate pcmjam prepared that could be installed alongside of the stock jamulus client and not cause problems with it.
Huge thanks to Patrick for getting the client builds together so we could test this — PLUS all of the folks jamming at 🌊CBVB🌊 for the fun sessions playing with this! Disclaimer — it’s as-is, and will likely see no further clean-ups or fixes. Hopefully someone can take the idea, perhaps design a more modular structure in jamulus that could support pcm.