Feeding audio from Jamulus Server to a Zoom conference call #790
Comments
|
Hooking Zoom into the server is an interesting idea. It would need to access one client mix and route it to the Zoom app. I have put a system together that cross-couples Jamulus and Zoom. On the Mac, it's pretty easy to hook Jamulus into the Zoom computer input (Zoom Audio Device). You can even use Apple's sound system Multiple output device so you can route Jamulus audio to Zoom and your headphones. There is increased audio delay doing this so I recommend not using this approach if you are one of the musicians contributing a part to Jamulus. I'm doing the "house mix" on a separate Jamulus client that differs from any musician mix although that may not be necessary. In my application, I wanted to also feed Zoom audio back to Jamulus so the musicians hear audience feedback during song breaks (e.g., applause). I use SoundDesk as a mixer to tie everything together and BlackHole to loop audio from one app back into another. Any other mixer should work but you need separate outputs to feed Zoom and Jamulus with independent mixes. SoundDesk allows routing a changes audio directly to any audio device, bypassing the main mix. But aux buses or subgroups could be used. I did my first "Zoomulus" session last week and it went really well. Here's how I interconnected everything: |
|
I love the idea of having a generic way of getting the audio output out of Jamulus and feed it into Zoom, Jitsi, WebEx, etc. Maybe the generic solution could be some HLS-style chunked file writing similar to recordings (to avoid large files), a readable streaming HTTP endpoint or a streaming/chunking webhook. That would still require another piece of software which would handle the actual Zoom client stuff, but this could then be developed independent from Jamulus. If this ends up being too much effort, we might end up with the existing solutions/workaround as described here: https://jamulus.io/de/wiki/Tips-Tricks-More Personally, on the Linux-side I was hoping to get this implemented using jackd, however, I realize that this would be Linux-specific and might not fit the idea of a "simple" way. |
|
@kwindrem I've accomplished the same but with a simpler configuration...
Yes, this has the potential to result in some echo. I avoid that by (1) leaving the Jamulus faders at 50%, (2) muting the Zoom fader in the Jamulus client (not Mute Myself), and (3) ensuring that Zoom's echo control is enabled. I've used the same config successfully with Microsoft Teams. I'm running a dedicated Jamulus client to route Jamulus sound to Zoom, and a separate Jamulus client for my instruments, mics, etc. I've looked at your diagram and like that you're avoiding echo by using BlackHole channels other than 1-2, and am thinking about ways to accomplish that without the need for SoundDesk (which I don't have). Likely I could achieve the same by using Logic or MainStage. @kezzy1966 To your point that routing Jamulus audio to/from a web conference app is difficult, I don't think that's true. It does require that one member of a chorus have sufficient tech understanding to use a virtual audio driver and second instance of Jamulus, but not all members need that knowledge or configuration. Admittedly, achieving that on Windows is a bit harder than Mac for initial setup, but that's a one-time action. I can't speak to Linux, and maybe having a built-in solution in Jamulus is more necessary for that OS. |
|
@kwindrem Could you provide details on how to configure BlackHole for the configuration you described? I am having trouble understanding the BlackHole documentation to accomplish your configuration. I am assuming that once I understand this configuration, I could try replacing Zoom with WebEx or Jitsi. |
|
I have heard that the video processing on Zoom introduces a 150+ ms delay that affects lip-sync between Zoom and Jamulus. I assume this will also be true with other video conferencing solutions. Does anyone know what could become a standard way to add delay to achieve lip-sync? |
|
@gene96817 There's a link above (prior message) to a PDF showing @kwindrem's configuration - he's using an additional mixing application to combine/filter audio sources. My solution (also above) doesn't require anything but BlackHole and yes, it will allow you to send/receive Jamulus audio with any application (Zoom, Webex, Teams, etc.). The solution to the video processing delay is to send Jamulus audio + Zoom video to OBS (or other video mixing application) and add about 250ms of delay to the audio. This is how the Jamulus WorldJam accomplishes synchronization for their weekly livestreams to YouTube. More on my Jamulus-to-Microsoft-Teams solution (also works for Zoom) in this doc... https://docs.google.com/document/d/1smcvsxdaaViPQvGMQHmah_6BQeqowhmGSFMHfnlY2FI/ |
|
Jamulus needs low latency networking And low latency audio. Unless a given computer platform has sufficient hardware And operating system support for such, using Zoom and Jamulus may have time constricted contention for the same resources. I think it is better to use separate computers for Jamulus and Zoom. then you can take advantage of external audio connections and networking. Yes, there are times when you need more than one computer to get the job done. |
|
Please do not add discussion of how a normal client / singer can create this link. That is not what I am suggesting. Likewise this needs to be on a cloud server(s) but not have wires connect from one to another. I can understand that the Server must be running as efficiently as possible and there are other video services out there apart from Zoom (like Jitsi etc). What about allowing an additional 'head less' jamulus client to also run on the server that would be separate from the core Jamulus server software? It would connect to Jamulus, grab the aggregate audio and present that into Jackd (or alternatives ) for onward routing ? |
That's how many folks run their jamulus to videoconf/OBS livestreams interfaces today... The suggestion of using another machine for running the videconf/streaming server, is to avoid interfering with the resources in use by jamulus server which may affect the audio quality. |
|
Following multiple discussions on this, I'm pretty sure you're never going to see multi-channel output from the server. Thus the only way to get audio out is via a client and then it's not down to Jamulus to link that client's audio to whatever you want to link it to. |
|
Hi @kezzy1966 as @WolfganP points out, your own suggestion of a headless client (using See also #146 |
|
Hi Gilgongo, The high level stages we use on a gui jamulus client are:
Finally, you then have to test it is actually working. I think that can only be done by using another device to connect to the conference call and confirm you can hear the audio. |
|
OK sure. I'm just looking to tidy up the issues list really as it seems multi-channel output from the server isn't going to be possible. However, if you do achieve what you need by other means, then this might be a good addition to our forthcoming "knowledge base" section, which we are expanding from our current Tips section. |
|
What is the status of this issue? Is it done or should we keep it open? |
|
There is still a clear user requirement for Jamulus to Zoom (J2Z) but I don't think a solution can be in the server. It is more related to the client where it can be done manually but is quite awkward. Due to the complexity of managing several apps like jack, zoom etc I think a solution needs to be found outside of Jamulus SO I THINK CLOSE THIS NOW. Thanks anyway. |
|
Thanks, closed now. |
I cringe as I type this request and this goes against everything I believe in for Jamulus usage, however it is quite apparent that there is a user requirement to have Jamulus audio out to a zoom conference call so non Jamulus users can (...sort of) be part of 'the choir experience'.
As Jamulus has now successfully been developed for the large choir, it is clear that there are a sizable minority in those choirs that will never, ever use Jamulus.
The management of those choirs are stipulating that a link must be made to a zoom call so people can 'sing along'. There are various methods out there but they appear awkward and really I think it should be part of Jamulus server build.
Therefore may I suggest that a strategic solution is built with perhaps the zoom user id and password stored in a config file. Also that it somehow has the ability for the same server to be used for multiple large choirs and therefore have some mechanism to use different zoom meeting logons for each.
Post Ed:
Please do not add discussion of how a client / singer can create this link manually each time. That is not what I am suggesting. You can discuss that in the jamulus sourceforge open discussion.
Post Ed 2
On reflection, a more realistic solution might be to ask for more variables to starting a jamulus client at a command line.
So that it can startup, have a user profile name, connect to a specified server etc.
We can install this client on a small server somewhere. It can all run from a script but may have a gui that we can remotely connect to. It can be quite low powered as it is only grabbing the audio and passing it on to jack.
I think jack + zoom can already run from a scripts/ command line.
but definatly no physical cables between them.
Post ed 3:
Just found that a client can autoconnect to a server using the -c command. So that might be enough.
The text was updated successfully, but these errors were encountered: