Slack Calls: Now with video
slackhq.com
slackhq.com
If you are a paid subscriber to Slack, you can add the app to your Slack account for free. You still have to sign up for Screen Hero as well, but at least you can do it.
I'd hoped that Slack buying them would result in a more polished product, but I haven't heard a thing about it since the acquisition.
I heard they got audio calls, and then video calls, working in the main app.
If I were working to integrate Screen Hero with Slack, that's where I'd start.
https://medium.com/@chris_82106/implementing-webrtc-screen-s...
I don't use video much but I hope they've done as good of a job as they did with audio.
*Wow, tough crowd.
Does a certain region use this or its usage widespread?
Crisp is a word with a few meanings. In this context, it's a metaphor assigning physical qualities to sound. (A crisp dollar bill is smooth and without creases)
Of all the different solutions I've visited (Google Hangouts, Skype, Slack, Zoom, Join.me etc.), G2M has been the most reliable and best-sounding one that I've found. It's got things like native Mac app, screen sharing (just one presenter, unfortunately), audio/video recording, telephone dial-in, calendar scheduling, and persistence (i.e. you can reuse the same meeting every day). It uses little bandwidth and behaves really well on a low-bandwidth connection. And unlike GH, we've never experienced any issues connecting or staying connected.
The only thing I miss is the ability for it to pipe back a little bit of my own audio, the way I believe phones do, so that you can talk while wearing earbuds or a closed headset. (Without this, you won't hear your own voice, which I find too unnerving.)
[1] https://www.citrix.com/blogs/2016/03/22/gotomeeting-audio-ha...
https://www.rogueamoeba.com/freebies/
hear the sound coming in through a microphone
Edit: It is specifically called out in the Citrix blog referenced above as not working well enough. Not sure if the Loopback software would be any different, but it does offer a free trial.
> New in 2.3: A long-standing issue with latency in LineIn has finally been cured! We've also added a menu item for toggling play-thru.
I'll try it out.
Just being able to see which person in the meeting is speaking is enough to to choose G2M, even if the call quality and reliability wasn't vastly better.
I checked, and it looks like they are using pretty standard webRTC settings. The audio is compressed with Opus codec. They look to be limiting the bitrate to 40 kbps. (I'm not sure, but I thought Chrome default limited the AVERAGE bitrate to 40 kbps, not the peak, so Slack might actually be imposing an even tighter limit here).
Opus does a pretty nice job and is full band. A lot of older VOIP tech used compression that severely limited the frequency response.
We've been working on a more conversational video conferencing service called Locus (inthelocus.com). There we do some processing on the audio stream to spatialize audio sources, and found audio quality improved up to bitrate of ~120 kbps. The compression difference was more noticeable when processing the stream vs. directly playing back.
I don't think that's accurate. Most conventional VoIP (in North America) uses G.711µ, whose purpose is to provide the IP correlate to logarithmically companded PCM encoding used in a normal DS0 (digital PSTN loop carrier).
DS0s are not compressed. Logarithmic steps result in some approximation, but that has more to do with the mechanics of digital sampling and quantisation than bandwidth savings. In fact, G.711µ is an uncompressed 64 Kbps codec, exactly equivalent to the synchronous data rate of a DS0 in the circuit-switched world. This is in sharp contrast to codecs like G.729, which, to simplify things, use waveform translation tables to achieve significant compression (down to about 8 Kbps in the case of G.729 specifically). Some less patent-encumbered variants do similar things.
The frequency response is limited by the standard PSTN bearer channel range of ~3.1 KHz, which is for historical reasons. That was the most frequency response one could reliably squeeze out of copper analog lines, for both physical and economic reasons tied up in the history of the telephone system. Since the primary concern of the VoIP industry was—and still is—interoperation with the traditional telephone network (PSTN, or Publicly Switched Telephone Network), adopting codecs which translate readily into that world with a minimum of CPU-hungry transcoding and reframing makes sense.
WebRTC, as a peer-to-peer multimedia calling mechanism intended to resemble something like Skype, is more purely a product of Internet-orientated thinking and has a rather post-PSTN mindset. WebRTC endpoints, like IP phones supporting wide-band codecs (e.g. G.722), are not constrained by the requirement to talk to the old-school telephone network. So, they can use codecs like G.722 and Opus.
VoIP at work (At least with Cisco) is usually some grumpy telecom guy disabling HD audio or the company skimping on telephones.
If they disable HD audio on pure-IP extension-to-extension/intra-company calling, that's stupid, though, and indeed could be done only by Mr. Grumpy.
There is unfortunately a trend to skimp on desk phones, but I think it's out of the perception that most users don't really care or use them that much.
I legitimately want to know why, I'm not ranting.
the sooner i can remove skype from my life the better.
that said, why can't any of these phone systems deal with the use case of two people trying to call each other and then simply auto connect the two calls? why does one side have to drop the call and answer the other?
If not, I wonder if their APIs allow a bot to join a voice call and get access to the audio...
Either a way to call-out, have external people call-in, or just allowing a connection of a 3rd party service (paid or otherwise) that lets us connect a phone line.
Really we only have it now because it's nice to have support if needed, and having our work emails associated with the hangouts we do with people outside the company is nicer than everyone using their personal emails (with their personal profile pictures).
1. Facetime
2. Skype
3. Hangouts
4. GoToMeeting
5. Slack
6. Facebook
7. WhatsApp
The fragmentation / lack of standards we had with IM is now a reality in video/voice calling as well.
IMO, competitions, choices with communication SW are very good for all users. I like all the apps, options, free, ads, paid, webbase, mobile, etc. No need for unified standard.
Think the web/browsers.
i don't really want to merge all of those contact pools into a single app.
You can then choose to either:
- use a client that supports multiple accounts/profiles (either one at a time or multiple concurrent logins); or
- use two separate apps.
"I want to keep my private and work life separate" is not a good defence of fragmentation. By your logic, we should encourage every single email provider/software vendor/project to use their own subtly different protocol, and require the use of their own client software.
You dont have to merge anything. I'm sure you have multiple email accounts for work and personal use don't you?
also, this only works in Chrome and on mobile, which is really messed up considering that Firefox is also a bleeding edge browser.
But I agree... more apps need to factor in if you are moving or not before placing calls or messages. I wish there was a way to say, "I only want music and maps when I drive..." on my phone and have it kill the connection and updates for everything else.
It overlays a nice "car UI" that's much larger and easier to not only see but also hit while driving, and basically only has phone, maps, and music.
It hides all other notifications, it "silences" other sounds, and there's a setting to optionally run the app once you connect to a specific bluetooth device.
I'm pretty happy with it.
It's hands down the best Android phone I've ever owned. From the build quality, speed, features, and usability it just fucking nails it in every way.
If you don't want people to call you outside the office, why not just tell them not to call you outside the office? Or use the "do not disturb" setting. Or ask whoever runs your slack account to disable calling altogether...
What they are saying is that you can use regular emoji reactions while a video call.
Might be acceptable overhead.
This is because libnss effectively has to (by definition of how /etc/nsswitch.conf works) be able to `dlopen` arbitrary files you don't know about, so statically linking it has no meaning or breaks that (you pick!).
For this reason, it's painful-to-difficult to bundle glibc with a program, and it WILL break some networking configuration options if you do it, which is probably worse than messing up a feature on an ancient linux no one should be using :)
The right solution to this, which for some dumb reason they don't want to do, is ship a different version of slack depending on your (distro, glibc) combo. For old RHEL and old Ubuntu, they just need to ship a version that is built against those old glibc versions.
It's trivial if they just open source their application and ask Redhat and Canonical to maintain packages of them and provide sufficient motivation (read money) to convince them to also package them for these old distros.
I don't know why the no-brainer idea of forcing redhat/canonical (who are experts on this glibc stuff and making debs and rpms in general) to maintain the slack packages for those distros hasn't occurred to them
WebRTC requires GCC >= 4.9, which doesn't ship on RHEL or old Ubuntu, and upgrading to it would also upgrade the built glibc, which defeats the point.
Edit: reading my message back I came off as impolite, sorry - genuinely curious, I've had the same breakage myself, and we started using Skype in lieu.
Off-topic: The guy's beard looks like a Snapchat filter haha.
Does video calling work in Slack's web client?
Sorry I didn't mean for this to be divisive or rude. I wasn't aware this was a common observation. I'm not trying to be negative or incriminate the product. I use and enjoy slack every day.
IRC was (and still IS) good. Slack is basically a modern way to view and utilize the same basic system. It also made it very easy for developers to integrate components (whereas IRC you'd have to search out some way to do such integrations) - and with the "special" UX that they control they could add things like button actions on messages.
A client like Slack for IRC with some of the newer IRC RFCs could potentially work just as well - as long as the UX and push notifications etc were nailed.
Slack is "just IRC" as much as vim is "just ed."
In my opinion Slack does something that is often very undervalues and easily overlooked, it is like the opposite of a death my a thousand cuts - superiority by a thousand minor improvements.
When taken individually or even in handfuls none of the features are that impressive, but cumulatively it creates a much better product. This was very apparent to me at least when I switched from HipChat to Slack. Just reading features or looking at screenshots they are nearly identical, yet with actual use Slack seems like a significant step up.
So yes IRC is to Slack, as the Ford Model T is to a Mercedes S-Class.
The brilliant bit is that you can set up your own homeserver which holds all your chat logs, can authenticate against whatever you like (internal username/password, LDAP, or even CAS single sign-on), and allows you to communicate with people and rooms on other homeservers without having to manually connect, create a dozen different accounts, etc.
I think right now, 50% of users are on the matrix.org homeserver and 50% are on their own homeservers. And the upside of everyone being on a homeserver is that everyone essentially has their own bouncer by default - no more having to set up ZNC on some random VPS on a user-by-user basis, you can always message anyone and they'll get your message whenever they reconnect.
Because of its federated model, you can also use it to communicate with other companies and customers as well as internal communications - something Slack/etc aren't really chasing after.
[0] https://matrix.org [1] https://riot.im
XMPP can support all the other things you've mentioned.
There's something to learn from this - there's likely a "right amount" of anarchy, some goldilock zone where people can still be creative and unburdened but not so much that things become fractured, fragmented, and incoherent.
I think you mean the other way around.
https://github.com/rawdigits/wee-slack
It's more featureful than the native Slack IRC gateway.
Good luck handling 3000 concurrent buffers in slack, or even adding basic features like OTR.
One example deficiency is message ordering. In Slack, messages ordering sometimes changes sometimes after I have received two messages, that are then ordered differently. Is this an example of “eventual consistency” in the wild?
Another deficiency of Slack that definitely is more “inspired” by IRC than anything else is the reconnection handling. If you ever have used IRC, Slack and XMPP on a train (or any other spotty connection), you may have noticed that IRC (or Slack) can time out without you noticing immediately, while with XMPP temporary network problems are usually handled automatically by modern clients.
The difference in both cases lies in stream management – if each message has a sequence number (as it has in XMPP with XEP-0198), endpoints can definitely establish a) an ordering and b) what the last message received was. This eliminates any manual replay. Slack does not do this, apparently, even though unexpected network termination happens frequently.
A third defiency of Slack that makes it look like IRC is the notable absense of metadata fields. While in XMPP you can have a vCard, the Slack documentation contains this gem, indicating Slack developers themselves abuse the last name field to convey information such as not being in the office:
> We ask that everyone displays first and last names in Slack, so we can use the last name field to alert coworkers when they are out of the office, on extended leave, or sick for the day.
Source: https://slackhq.com/slack-101-onboarding-247454704155#11aa