Talk:Full Rate

	Telecommunication portal This article is within the scope of WikiProject Telecommunications, a collaborative effort to improve the coverage of Telecommunications on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.TelecommunicationsWikipedia:WikiProject TelecommunicationsTemplate:WikiProject TelecommunicationsTelecommunications articles
???	This article has not yet received a rating on the project's importance scale.

Comments

Hang on a minute... OK... so... does the encoder start streaming out encoded data / the decoder start sending audio to the output system even as their respective inputs are still running partway through the active frame, rather than receiving a whole frame's worth of input and then working on it whilst the next one starts to spool?

With the blocks being 20ms long (and as that's 20ms both of incoming and outgoing audio, which must be at a constant rate, rather than data which can be burst transmitted many times faster, there's no opportunity for shortening it), and the "frame" structure being presumably important for packetising the data with forward/backwards prediction and maybe a header including global gain, etc, I can't see how the overall latency e.g. between someone snapping their fingers right next to a phone mouthpiece, and someone else having that short sharp sound being sent into their ear by a receiver pressed up against it, could be anything less than 40ms. IE 20ms to encode, all whilst the data is incoming, instantaneous postprocessing and transmission, then 20ms to decode with instantaneous output.

With a reasonable encode/decode and transmission delay (say 4ms of post-receipt processing and streaming in/out each end for 20ms of data, on top of anything done during reception - ~48kHz equivalent - and 2ms for transmission delay (circuitry, a few hundred kms of direct and retransmission via towers), then wouldn't that be an end-to-end run of about 50ms?

A 1/20th second delay doesn't sound too heinous - feedback would still be more of a reverb mode than echoing, and if the person you're talking to is any more than about 15 metres away, the sound will still travel faster over the phone network than through the air between you, and it's decidedly less than typical thinking/breath-taking time so it wouldn't cause "satellite delay" type difficulties in conversation. In fact, they could probably get away with 60 to 100ms (120?) before things got a bit iffy... 193.63.174.211 (talk) 09:08, 16 October 2013 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Full Rate. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

Added archive https://web.archive.org/web/20090908233955/http://www.winamp.com/plugins/details/142107 to http://www.winamp.com/plugins/details/142107

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 19:29, 8 October 2017 (UTC)[reply]