As per my previous post, just testing out the demo version of Mimolive and love what we see so far. We’re have a little trouble getting a few things working, one of which is the Mimocall beta. We’re on the latest beta release, and we’re running the latest Chrome download on a couple different iMacs and Macbooks to test video input. Mimocallers can see our program feed, but they can’t send back audio or video.
Specifically, we’re testing this on a 2013 iMac and a 2013 Mac Mini, both running the latest version of Chrome as of today. The broadcast / Mimo machine is a maxed-out 5k iMac Retina 4ghz with 4GB of VRAM. The callers can click the invite and see our program feed. But the audio/video configuration pull-down menus are all blank. There appear to be items available for selection for both audio and video, but they are blank, i.e. not labeled, and choosing them produces no output.
Is Mimocall fully functional in the demo version? If so, any ideas as to what may be happening? Perhaps some kind of security setting so the browser can access the hardware?
@Troy Yes, mimoCall is fully functional in the demo version. We’ve recently updated the web client. Could you please verify that if you add a /v1/ in the URL just after call.mimo.live if the users can see video and audio? This will revert back to the first version. (The ULR becomes something like https://call.mimo.live/v1/…)
Hi Oliver - thanks for the speedy response. Just tested, and yes, the v1 client works.
The possibility of handling group calling and all the associated mix-minus monitoring in one application is appealing. Currently we have Skype running on a separate machine and all audio processing, including three separate monitor mixes, are generated via Logic. Those mixes are fed back to their respective destinations - the Skype machine, Wirecast, and the host’s monitor mix - through Loopback and a system-level aggregate device that includes all those Loopback devices plus all the connected hardware interfaces. It works well, with low CPU usage considering Skype is basically just an uncompressed video source. But it’s pretty complicated. The prospect of handling all this automatically inside one application on one machine is potentially very appealing if the hardware can handle it without dropping frames. Look forward to testing further when you get the V2 client working.
For our purposes, the only remaining reason to run Logic would be to process guitar and mic signals with our usual effects, including ducking, so vocal mics can shut down when the amps are blazing. I see you already have ducking for audio layers. Have you guys considered implementing audiounits on audio layers? That would probably do the trick.
Hi @troygrady, we are aware that there are problems with the new web client occuring during the beta phase. This is why feedback from our customers is so valuable to us.
Can you please tell me whether camera & microphone settings are both configured like in the attached screen shot? If not, set it to that value manually and reload the page.
Hi Stefan- I did not know that menu was there! I suspected it might be a permissions issue. I can see that camera and mic are both set to “allow”, and indeed, the V2 client is now working. I didn’t change these settings from the last time, so that’s a little strange. But I won’t complain.
I’m seeing about 20fps on my mid-2012 MBP Retina. I can test on better hardware in our studio. What determines the caller’s frame rate, is it automatic?
@troygrady: Thanks, glad that worked. We definitely need to find a way around the permission problem then (it seems like Chrome sometime doesn’t ask even though it should…).
You are right about the framerate. The browser sets the framerate completely automatically, depending on the computer’s CPU and network connection speed. And of course the maximum framerate available from the camera.
No problem. For now, while we’re testing, it’s a simple matter to remember to check the security settings. In fact, you could probably just do some kind of sanity check in the client to make sure the hardware is accessible, and remind the user/caller via popup to check their settings if it’s not.
Ok ran another test today from our studio to a remote caller on a Macbook Air. There was initially no prompt to use the camera/mic, but I reminded the caller about the security settings and that worked. However a few more glitches:
I can hear the remote caller but they’re not receiving my program audio. Verified in technical call settings on the remote machine - incoming audio is zero. I streamed a test to YouTube, thinking Mimolive may need to see an outgoing stream, but that didn’t work - still no audio from me to the caller. I was not recording to disk at the time, not sure if that is necessary. My monitor mix was fine, and the audio on the recorded YT stream was also fine. Is there any particular setting I need to enable to ensure that the remote caller hears the program output?
Outgoing video monitor feed from me to the remote caller was poor. Around 20fps from me, dropped to <10fps one I started the YouTube stream, and occasionally froze to zero fps. Once I stopped the YouTube stream, fps when back >20fps. Frame rate from the remote caller was pretty smooth. Technical call info said 30 or near 30 the whole time. Subjectively it looked smooth on my side, and the recorded YouTube stream looks smooth as well. It appears to be just the monitor feed sent to the remote caller that suffers. Any idea what factors influence this?
Hi troy, thank you for your ongoing interest in mimoLive & mimoCall.
I just updated the web client after identifying and fixing the permissions issue. Now, a new visitor or anyone with a setting of “Ask” will be correctly asked for permission. I also added a link to this article, hoping it will help users in the future should it be necessary: https://boinx.com/connect/mimolive/knowledge/mimocall/WS100514
Regarding your questions:
I just built a sample document using a playlist source to generate audio, added it via a audio-only layer and connected a mimoCall to the current version of the web client and I was able to hear mimoLive’s audio in my browser. Please check the “Incomming Audio” section of the stats overlay (icon in the top right of the remote video feed) and tell me wether there is data being sent. Also make sure that the correct output device is selected in the web client’s preferences.
Your total outgoing network bandwidth is shared between all mimoCall outgoing video feeds and active streaming destinations such as Youtube. It sounds like your upload was saturated and therefore the framerate was reduced. Can you please visit http://speedtest.net and measure your internet connection? For your specific question, outgoing bandwidth is the important aspect. For 720p video, a bandwidth of ~2.5mbit/s per video transmission is recommended.
Hi Stefan - thanks again for the quick reply. Yes, I checked the technical call info in the client and confirmed that zero data was being sent from me to the caller. However my monitor mix and the program output was fine. Strange.
I just tested Mimocall here at home with two computers and the built in mics, and audio is flowing in both directions. So it may have something to do with the audio setup on the machine in our studio.
Possibly related, I notice that Mimolive will not receive input from Loopback devices, but it does seem to work with Soundflower. We have both on our studio machine, a 5K iMac, so maybe there is some kind of interaction that is causing this. We’ll try and duplicate this test on the studio machine with the simplest possible audio setup to see if we can get audio to work in both directions.
Few more studio tests today. These went better - not sure what changed, but we’re finally seeing audio and video flowing in both directions, which is great. The main issue is highly variable frame rates on the monitoring feeds to the callers. These were sometimes very good (>25fps), and sometimes very poor (<1fps, appearing to freeze). We don’t experience similar interruptions in group Skype calling.
The incoming feeds from the callers were solid - 20+ fps most of the time, so it’s mainly the monitoring feeds.
We’re broadcasting at 6 megabits, and our upload speed is only about 12 megabits so it could be that we’re cutting it too close and Mimocall needs more headroom. We can try to test in an environment with greater upload bandwidth. What’s the recommended minimum upload bandwidth for [ edit ] two simultaneous Mimo callers + broadcast feed?
I started using MimoCall with a partner on a radio show, and ‘it just works’, and still does. But I did 4 FB Live sessions between yesterday and today, and all 4 of those people could see/hear but no transmission.
I will check into the security issue and report back
@troygrady: I’m sorry to hear that the monitoring feeds display such a poor quality. I am currently talking to my colleague about this issue.
Theoretically, ~11 Mbit/s outgoing bandwidth should be enough to stream to FB and have two mimoCalls. However, you never know what other application is using network bandwidth (e.g. online backups, iCloud Photo Sync etc.). Try using two mimoCalls from within the local network. If the framerate is ok, then it is most likely a limitation based on the available bandwidth. If you experience the same problem, video quality might e.g. be bound by CPU processing power.
Hi Stefan! We don’t have any other network services running on the machine, specifically to lock down potential sources of interference. But it could still be a bandwidth issue - I don’t totally trust our network provider. We’ll run a test from an environment with better upload speeds and see what kind of performance we get.
Microsoft said that Skype uses 1.5 Mbits for HD Calls. How many Mbits are used by MimoCall for one connection? I try to calculate my total amount of all-in-all needed bandwidth. Thx for reply, JoPhi
