.
I set it up ahead of time with Free Talk Live tonight to do the first-ever FeenPhone call into a radio show. I’ve been having my co-hosts on the Freedom Feens connect to me via FeenPhone since Christmas, but FeenPhone has not yet been used on a different radio show, until tonight.
.
The file is a little over six minutes of audio culled out of that show. It is, in order:
.
–Me on FeenPhone. Sounds great.
–Dean on Skype. Sounds OK.
–Chris on a land line. Sounds bad.
–Mark on a cell phone. Sound horrible.
.
The audio quality is about average for the Skype call, the land line call and the cell phone. Each is a good example and quite indicative of how they usually sound on radio.
.
Keep in mind this is an MP3 made from an MP3 (GCN archive), so all the callers (Including me on FeenPhone) are slightly degraded from what went out on radio. But they are equally degraded, and this is an excellent example of a side-by-side A/B/C/D comparison of FeenPhone to other common methods of connecting with live radio.
.
–Michael W. Dean
.
Author: Feeny McFeenFace
6 thoughts on “Live radio audio examples: FeenPhone vs. Skype vs. Land Line vs. Cell Phone”
Comments are closed.
The audio quality sounds great!
Because you are promoting FeenPhone as a high quality replacement for existing choices, you may be interested to know that in the telecom industry there have been many user studies done on how various factors influence the Quality of Experience (QoE), and over the years a model (called the E-model) has been developed to estimate user perception taking into consideration several factors including signal-to-noise ratio, the codec used, end-to-end delay, echo, packet loss rate, monotic vs. diotic (headphones), etc. and putting them all on a common scale (called the R-scale).
Wideband audio does significantly improve QoE compared to narrowband. For example, a number of wideband codecs were tested for ITU-T G.113 Amd.1 in 2009 (pre-Opus) and the highest rated wideband codec tested (Embedded logPCM ITU-T G.711.1 mode R3 @ 96 kb/s) rates almost 36 points higher on the R-scale than the standard narrowband codec used on land lines (G.711) under normal conditions.
End-to-end delay also plays a significant role in the E-model. Below 100ms, there is no impact at all on the R-scale, but over 200ms the impact starts to become severe. For example, I plugged in the delay I was hearing on the FTL FeenPhone demo into the E-model, and even in otherwise perfect conditions the delay alone would dock FeenPhone quality over 38 points on the R-scale, enough to fully cancel out any perceived narrowband-to-wideband improvement.
I can’t be sure what is causing all the latency, but assuming the Internet connection has no more than normal latency, and the computers on each end and the mixers and other audio equipment are not adding any significant latency, and the normal Opus packet size of 20ms is used, there shouldn’t be an issue achieving a latency that is in the range that is not noticeable.
The thought that occurred to me was that perhaps your Internet is via satellite, which adds latency that many people find unsatisfactory for real-time communication. However I did the calculation and that would account for less than half of the latency encountered in the demo. But it’s possible that there could also be some significant delay elsewhere, perhaps due to Ian’s equipment or someone connecting using a wireless network.
I read the FeenPhone protocol guide that you posted on the web site, and it looks like all timing and delivery is left to TCP. However TCP’s purpose is guaranteed reliable ordered delivery, without regard to latency. If a packet is lost, that will hold up delivery of all of the following packets until it times out and recognizes that the packet is lost and the lost packet can be retransmitted and is received correctly. That is great for transferring a file, but not so much for real-time communication where low latency is important.
If you are looking to address the latency, this is where I would start investigating. If a packet is lost in real time communication it is much better to not wait for it to be retransmitted, but to instead use PLC (packet loss concealment) or FEC (forward error correction). Opus supports both PLC and FEC. You may want to just use RTP (Real-time Transport Protocol) for audio transmission, as it is specifically designed for real-time communication. RTP is also used instead of TCP for audio and video transmission within WebRTC, SIP, Jingle, and other protocols used for real-time communication.
Other than the end-to-end delay, FeenPhone seems to be performing very well on other factors that affect QoE. Keep up the good work!
Mark,
Good stuff to know.
.
There is latency with FeenPhone. But there is less latency in FeenPhone than you think. You should consider the following and make measurements on a different file before coming to a final conclusion.
.
There is a lot of latency inherent in all the distance-transmission aspects of talk radio. There’s a full two or three seconds before I say something and you hear it on your local radio station. Though that is not going to show up at all in an MP3 of a show recorded locally. But you will hear the latency between the hosts and anyone connecting remotely, with FeenPhone, Skype, a Comrex, or anything.
.
There’s also the amount of time people take to respond. Listen to the British guy on Skype after my FeenPhone call. He was waiting a second or two to respond. Skype does not have a second of latency. It does not even have a half-second in each direction.
.
My latency with that call to FTL is more than usual, because I was trying to be polite and not cut them off (except the one spot I intentionally talked over Ian to show the true-duplex of FeenPhone). There was also a host I don’t know, so I don’t have any vibe with her. I do with Ian and Darryl, but not her. Also, not being able to see 3 people is really hard to guage when it’s ok to respond. I generally think that any live remote media with more than 3 people total is a clusterfark. I say this in the FeenPhone documentation, and recommend against having more than 3 people on any live media via VoIP. Hell, I recommend against more than 3 hosts in the same room.
.
There’s less “wait to respond” “mind latency” in a Feens shows because I’m not worried about offending my co-hosts if I cut them off, it’s my show, not Ian’s show. Plus we have a vibe with each other. Plus we’re used to using FeenPhone. FeenPhone is different than Skype. With Skype, the noise cancellation kills subtle cues that the other person is about to speak, like taking a breath, or starting the beginning of a syllable quietly. This takes some getting used to, because all non-FeenPhone VoIPs have noise cancellation and kill the ability to read those subtle cues. I’d say we’re STILL getting used to it on FeenPhone. It’s not that FeenPhone is crippled and other VoIPs are correct, it’s the other way around. But after years and years of doing daily shows where you can’t hear those cues, then suddenly being able to hear them, it takes some getting used to. Kind of like acclimating to society after being in jail for decades. lol.
.
Listening to a Feens episode live streaming or on radio while we do a show would be a really good indicator of the actual latency. Listening to a podcast of us is not a good indicator, because I have always (even when using Skype) edited out long pauses here and there, probably 20 per show, before posting the file.
.
To really hear FeenPhone’s latency accurately without listening live streaming, you’d need to listen to a GCN archive, as they are not edited and are exactly what we say. There is a latency between the network sending us the music and us sending audio back to us, but that’s not going to affect what you hear in the parts with no music.
.
Plus I’d recommend you listen to an episode with one of my hosts without a lot of mental latency. For instance, Lou is very thoughtful and takes a while to respond, Davi usually doesn’t. He responds more quickly, almost as quickly as I do.
.
Ben stone is thoughtful too, plus he’s on 4G Internet from his RV. Bill Buppert is on Skype still, because he’s Mac only.
.
Here’s an hour of a GCN archive of a show, as it sounded live (minus a little crunching in audio quality from their compressors and the MP3 encoding, but that doesn’t affect time or latency), with a recent Davi and I show with him connecting to me via FeenPhone. THAT is going to be what it really sounds like.
http://podcast.gcnlive.com/podcast/freedomFeens/0128152.mp3
.
I wanted to get a pre-FeenPhone GCN link of a Skype show with Davi, but the way GCN does their older archives doesn’t allow hot linking, plus the ones older than a month are all like 32 k and sound poor. Here’s that same episode on my site:
http://www.freedomfeens.com/_MP3s/2014/11/FF-548_11-19-2014.mp3
.
but keep in mind, some of the longer pauses while thinking will be cut out. But the general back and forth will be as it was.
.
Let me know what you think.
.
As for protocols: We tried UDP, it didn’t sound as good as TCP. There still is a UDP option in the Advanced Features menu on FeenPhone if anyone wants to experiment with it.
.
MWD
Hi Michael,
I understand that it sometimes takes some time to respond to a question. That isn’t what I was using to measure latency. I used the points where you apparently did not realize that someone else had already been talking for several hundred milliseconds and then you started, only to stop mid-sentence a little later apparently after hearing them. Those seemed pretty consistent, and did not make for good radio. In contrast, the interaction of the hosts in Ian’s studio seemed very good. An example is at 3min 45sec in the above clip.
Mark,
You’re right, there is more latency round trip in FeenPhone than would be perfect. I just wanted you to know about those other things first. And we’re using wired connections, not satellite, and we’re wired in our studios, not wireless. Ian uses business-class cable. I have cable but also have DSL, and use DSL for VoIP stuff, since it has less frame loss and jitter. Though Ian is in New Hampshire and I’m in Wyoming, two places that are not known for having the fastest, best Internet in the country.
.
The easiest thing to compare to, and the place most people go, is comparing FeenPhone to Skype. I don’t want to compare it to Skype because it seems to me that Skype’s latency can vary from pretty low to pretty long. I think FeenPhone’s is always about 400 ms round trip. Also Skype sounds bad (and is sounding worse with time) and has drop outs, disconnects, etc. Same is true, of varying degrees, of all other free softphone VoIPs. (and one commercial expensive radio-industry specific VoIP softephone…AND that one drifts out of synch.) FeenPhone stays locked in synch. It may start out with 400 ms round trip, but after doing a show for two hours and then yacking with my co-host off-air for an hour after the show, it’s STILL the exact same latency with no drift, and it’s still the same high quality audio, and still has very few drop outs and no disconnects.
.
This one-minute file with myself and Davi:
http://www.freedomfeens.com/_MP3s/2014/12/FeenPhone-radio_ad-60sec.mp3
.
We’re reading from a written script and both start to read our next line AS SOON as we hear the other person. So it’s a good test, because there’s very little added delay of “thinking what to say next.” The gaps between him and me are 400 ms to 500 ms, I measured it in an editing program. so if we go with the lower (400) and assume the higher (500) has a tenth of a second of “mind delay”, the delay is about 200 ms in each direction.
.
It’s actually workable for me with radio, I barely notice it. Or barely dislike it because FeenPhone sounds so good. I actually do notice it but easily can ignore it. Same seems to be true for other people who do radio and podcasts who have tried FeenPhone.
.
Derrick:
Mark says the answer is UDP, plus some other stuff. I think we’re set on TCP, but is there any way to lower the round-trip latency over TCP without sacrificing audio quality and increasing drop outs?
.
All things considered, I’d take the high audio quality and higher latency we have now over lower audio quality to achieve lower latency. Ian Freeman said the same thing when I was testing the alpha version of FeenPhone with him. And he’s a guy who uses VoIPs to connect co-hosts to his streaming network, LRN.
.
Worms.
MWD
Mark and Derrick: IMPORTANT INFO:
.
I went through a “Davi and Me” Feens episode that was done over Skype, and measured the gaps between us in the editing program. Only checked places we answered back quickly without mulling on it. The gaps were LONGER on average than with FeenPhone. They were 375 ms at lowest, and generally were around 450 – 550 ms.
.
I don’t think FeenPhone has more latency than Skype. But I think what you’re saying is that we’re not competing against Skype in the long run. Though we are in the sense that almost all podcasters, and a lot of radio shows, use Skype to take calls. And many podcasters use Skype for interviews and even for co-hosts in remote locations.
.
I think what you’re saying is we shouldn’t be thinking of our competition as Skype; that we should think of our competition as commercial software (and hardware solutions) like Comrex or commercial corporate hardware / software SIP phones or productivity suites with collaboration VoIP, right?
.
MWD
Hi Michael,
TCP cannot provide consistent low latency; it is simply not designed to do that. I don’t doubt that it will sometimes work. Opus and RTP are both designed for low latency, so the right tools do exist.
There may be an explanation other than latency, but in the FTL clip Danica begins speaking at 3:46.187, and you apparently do not hear her until 3:48.111 when you suddenly stop mid-sentence. I know a few milliseconds of that is reaction time, but regardless of the explanation it is far into the annoying region and not pleasant to listen to.
One possible alternate explanation is clock drift. This happens when one of the clocks in the audio hardware at each end of the connection is slightly slower than the other, so it may be capturing and/or playing back the audio at a slightly slower rate leading to increased delay over time. RTP includes ways to manage this using timestamps and RTCP control messages.