Yeah, right?! I had the exact same thought when I saw this. Okay, video... that's cool. But, we've been waiting for the ScreenHero purchase to turn into Slack screen sharing for ages.
You probably already know but until they finish the integration you can sign up for a screenhero account from Slack. I'm not sure if you need a paid account or what tier you'd need but it's definitely available on ours.
My team uses Screenhero on a daily basis because it's the only screen sharing software we've found that lets us all point (and drive) without having to wait turns or specifically request control. Unfortunately, it has a host of issues and we end up having to restart our daily meeting call several times each day because of them.
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.
Slack calls are built on webRTC, and actually it isn't too bad adding screen sharing functionality with webRTC. I wrote a blog post on this recently. And actually, with the Screen Hero team on board, should be even way simpler for them.
We started using screenhero (paid) before the slack takeover, but were using paid-for slack too so nothing changed for us. The integration is fairly weak, you can launch a screenhero session from within chat but tbh I tend to use screenhero's own UI instead. Still the best tool I've used for remote pairing.
I was thinking the same, and actually looked into it after seeing this headline.
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.
Exactly i came to comment the same thing. Lynx sucks. Takes a hell lot of time to reconnect. Can't believe the product is maintained by top developers.
Slack uses WebRTC, and browsers are (understandably) picky about letting websites capture the users screen. It involves having each user install an extension and/or getting on global whitelists. And Safari and mobile browsers are basically impossible.
Has anyone else noticed how pristine the audio quality of a Slack call sounds? I wonder how they optimized it. My company's voip, and Lync, and Skype all fail to deliver the same kind of call quality. I've only noticed / admired better call quality when making a call within Cisco to another employee.
I don't use video much but I hope they've done as good of a job as they did with audio.
Slack audio calling is using webRTC tech. On Chrome, you can check out statistics and configuration for how they set up the call by going to chrome://webrtc-internals
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.
> A lot of older VOIP tech used compression that severely limited the frequency response.
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.
Probably a wide band or at least mid-band codec. One thing I learned working with VOIP is people perceive quality based on what they have been using recently, which for most people is the absolutely horribly stepped on audio of skype, cheap voip, or the cellphone network. Carriers have pretty much let their baseline audio quality go to \\\\ because no one cares anymore. (Remember the Sprint pin-drop campaign?) Now, when you give somebody a wide band high quality audio connection they are blown away.
Yeah, every once in a while when my wife calls me, we get what I'm assuming is an LTE voice call and the audio is great (AT&T HD voice, I believe). Outside of that, it is amazing how bad the call quality can be. You really notice it when listening to hold music. It is like the audio version of one of those old jpegs that looks like it has been recompressed each time the email was forwarded.
Their dropped packet handling is far far better than Skypes as well - in a dodgy wifi situation linq and skype are all but unusable while slack is crisp.
It's probably because you have not heard it often enough to just not think about it. If I were to describe a sound as being rectangle, it just doesn't make sense and I have to think about it and try to interpret it. The extra effort in trying to decode the meaning is just annoying. In contrast, you've probably heard the phrase sharp sound. It's equally as technically meaningless as crisp sound, but you probably get it and aren't annoyed by it.
I think you are spot on. If they described the call as clear or sharp, I'd be fine. Crisp seems out of place even though it does convey a similar meaning.
Not sure why it bothers you. Is English your first language? This kind of thing is often difficult for non-native speakers.
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)
I'm not entirely certain - I use it to describe the opposite of "dull/distorted" sound, kind of a synonym of "fresh". I really have no idea where I picked it up, other than I grew up on the west coast.
Slack's audio quality is on par with GoToMeeting, I think.
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.)
I cry a little inside everytime I see that someone at work has scheduled a conference call using our terrible, terrible, expensive, 8x8 conference calling line instead of using the GotoMeeting audio. Especially when we are also already using the GotoMeeting for screensharing.
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.
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.
No to mention the pristine UX of the "call failed" screens. Ugh. I love Slack, don't get me wrong, but the calls fail to connect about 50% of the time for me when I'm connected to my work VPN. Work VPN seems fast for everything else, just Slack calls crap out while using it... I don't have the same problems with Skype or Google Hangouts -- opened tickets with Slack and was told, "Don't use a VPN with our service..." Uh... cool, right, will get on changing my work policy around this. =P
Speak of the devil... couldn't get a single Slack voice or video call to work all day due to VPN issues... we all have to use a VPN... and it just flat out doesn't work when you connect to one. Not one call all day. So... we just used Google Hangouts.
I'm not sure what codec those products use, but I wouldn't be surprised if Slack went for Opus. Seems like it's the most popular choice these days, with little competition. (Discord also uses Opus.)
Since high quality, near-lossless 48kHz mono audio can be encoded at about 96kbps, which is much lower than most users' upload/download bandwidth, why do providers even think about going under this bitrate? For example, Skype is ~30kbps and frequently sounds overly-bandlimited and garbled, so why doesn't their algorithm just use only three times this amount? Is it an issue with latency, or just keeping down their server costs?
As weird as this is, every time I've done a slack audio call, I only he's audio from my right speaker on my MacBook Pro. It's like the eliminated the whole left channel. Sane behavior on multiple computers as well.
It's not that he's grumpy. It's that almost all phone calls terminate to or originate from the traditional Publicly Switched Telephone Network, which does not support HD audio and—for long-established historical reasons unlikely to change—uses a 3.1 KHz bearer frequency response range.
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.
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?
Because if you're calling someone you expect them to say hello. It's not that easy to explain to a user that the call they just placed was dropped and they're really now answering a call.
I can't stand Skype's sign in/closing experience. Linking my original Skype account with a Microsoft email definitely broke something. Also why do I have to tell it to exit in 3 different ways to get it to finally exit for real!?
We constantly have problems with Slack audio calls, they seem not to be stable even over very stable internet and wifi. I wonder if being in Europe is a factor
This is the last thing we require before moving our team over from hangouts (which is the only thing we use even though we pay for the whole g-suite).
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.
We were using many of the gsuite features previously, and just over time moved off one by one.
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).
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.
fragmentation carries some negative connotation, but in this context it's a great simple way to maintain some division between your communities. my skype account gets given out to customers and various random people i need to connect to at work. video calls with co-workers happen using hangouts. whatsapp is for family.
i don't really want to merge all of those contact pools into a single app.
If we used standard/open IM/AV call protocols (lets say XMPP, and XMPP Jingle) you would just have two accounts, just like you have a personal and a work email address.
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.
bad enough that I can be reached after work via slack and get calls while I'm on a commute (which is never compensated for aside from general salary), it'll have video?
also, this only works in Chrome and on mobile, which is really messed up considering that Firefox is also a bleeding edge browser.
I get that not everyone will use or like this feature, but to complain about it existing?
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...
Just set your Do Not Disturb hours... you won't get the calls.
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.
The new android-auto app for your phone can do exactly this.
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.
One small question here. With their "Instant emoji reactions" looks like they are doing server side shape recognition, so Slack video-calls are not P2P (i.e. if I'm calling my colleague in my office the streams are going to the Slack servers before going back)?
Anyone try this yet and compare it to Hangouts on a poor connection? I'm constantly dealing with colleagues in another office where the internet connection is sub-par.
If you're using RHEL, you've got a version of GLIBC that's too old, we're trying to figure out what to do about this without asking users to install a bunch of crazy stuff
Got any info on what "too old" means here, I thought that glibc was supposed to claim ABI compatibility pretty broadly, or is there some specific regression/bug you're working around?
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.
I know dynamically linking to libraries is the Linux way, but wouldn't just bundling the correct version of glibc with the Slack app solve the problem? Sure, the app gets bigger, but a missing feature is worse than that, I would imagine.
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
Almost for as long as I can remember, there have been problems with Linux and glibc (across different distros especially). What is actually the cause of this? Recurring ABI incompatibilities?
I had two colleagues suddenly have the chat text field filled with Chinese characters and emojis today so they were told to clean their pcs. Different environments and location but both using slack... heard of this ?
Note that Chinese characters are the vast majority of characters, so (at least from your description) my guess would be "random bytes being interpreted as Unicode" instead of "Chinese hackers who like using emoji". If it's only Chinese characters and emoji, that's different.
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.
Wow quick to the low effort Slack is just IRC comment.
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 one thing that I liked (and still like) about IRC is its federated server model. Maybe I need to do more research, but I guess I am assuming that slack is a for-profit company with private servers that they own somewhere that everyone uses ... or am I totally off?
If you're looking for "a better IRC" while still not tying your communications to a single data silo, Matrix[0] with the Riot[1] client is currently the best experience.
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.
While XMPP is wonderful in theory, in practice, it's very difficult to assume that any given set of client+server can support anything, especially once you're talking to people on other servers. Even things like the features allowing messages to be delivered to multiple clients, rather than only one, are rarely implemented according to the standard. Matrix has a reference server and client which supports the entire protocol, so any other implementation will hopefully wind up implementing at least the majority of it, or won't be used.
XMPP hasn't really played out to its promises. Pity, it's such a great set of technology.
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.
Sure, IRC might be the Ford Model T if you are using it with netcat and manually PONGing the server. But compared to a proper IRC client Slack really feels more like an E-Class.
Good luck handling 3000 concurrent buffers in slack, or even adding basic features like OTR.
In my opinion IRC is superior to Slack, so I really don't understand this argument. (You're assuming Slack is an improvement on IRC, when in fact it's a completely different platform.)
I personally think that Slack has been heavily inspired by IRC and it can be seen by its feature set and failure modes – where it more resembles IRC than any other messaging solution I am aware of that came after it (importantly, Slack engineers did apparently not learn from XMPP).
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.
IRC, minus a bunch of technical nonsense nobody who is busy will bother to understand or manage (mode flags, server vs network channels, out-of-band post-hoc client-to-client features, netsplits), with good stories for multi-device (single, consistent cross platform experience) and offline (messages are queued/marked as read server side, in a way consistent across devices) and bots (anyone can add an integration in a few minutes, instead of delegating to a developer to add some code to the latest pet bot which soaks up maintenance effort like a sponge) management (managed, easy access control, no services bolted on as an afterthought) and file sharing (files stored server side, every client and user supports the feature, file can be sent when user's client is offline, doesn't have to figure out how to forward some ports or something) presence (consistent single feature instead of someone maybe implementing away status or an away nickname) identity (nicks === users) and so, so much more.
Indeed. I'm the seemingly rare creature who was able and willing to jump through all the IRC hoops but can still understand the people who maybe can't but certainly won't.
I dunno, I get people on IRC all the time using web clients, there aren't many hoops to jump through to get on it. You don't even have to register either.
Yeah, sure if you just want to send and receive text synchronously from a public channel, each feature past that point and you have to break open your computing history book and learn some arcane incantations.
That's mostly what Slack is and why people like it.
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.
IRC is a pain, yes. I made a C library to talk to IRC servers about (oh god) 15 years ago that I then put a perl wrapper around ... it provided a notification engine like the slack notifications I see today. But I had to cull all the hacker in me from 15 years ago to get it working right ... not an easy thing at all.
Not sure what you want to say with that statement. Slack has a ton more features than IRC, so until IRC catches up and is easy to maintain I couldn't care less what Slack is written in.
