Commit 4b47412e authored by moto's avatar moto Committed by Facebook GitHub Bot
Browse files

Fix typos and remove comments (#2270)

Summary:
Follo-up on post-commit review from https://github.com/pytorch/audio/issues/2202

Pull Request resolved: https://github.com/pytorch/audio/pull/2270

Reviewed By: hwangjeff

Differential Revision: D34793460

Pulled By: mthrok

fbshipit-source-id: 039ddeca015fc77b89c571820b7ef2b0857f5723
parent 8a885191
......@@ -51,7 +51,7 @@ on laptop.
#
# We use ``ffmpeg`` command for this. ``ffmpeg`` abstracts away the
# difference of underlying hardware implementations, but the expected
# value for ``format`` vary across OS and each ``format`` defines
# value for ``format`` varies across OS and each ``format`` defines
# different syntax for ``src``.
#
# The details of supported ``format`` values and ``src`` syntax can
......@@ -108,17 +108,17 @@ on laptop.
# 3. Data acquisition
# -------------------
#
# Streaming audio from microphone requires to properly time acquiring
# data form hardware. Failing to do so indtorduces discontinuity in
# Streaming audio from microphone input requires properly timing data
# acquisition. Failing to do so may introduce discontinuities in the
# data stream.
#
# For this reason, we will run the data acquisition in a subprocess.
#
# Firstly, we create a helper function that encupsulates the whole
# Firstly, we create a helper function that encapsulates the whole
# process executed in the subprocess.
#
# This function initializes the streaming API, acquire data then
# put it in a queue, which the main process is watching.
# This function initializes the streaming API, acquires data then
# puts it in a queue, which the main process is watching.
#
import torch
......@@ -154,12 +154,13 @@ def stream(q, format, src, segment_length, sample_rate):
# The notable difference from the non-device streaming is that,
# we provide ``timeout`` and ``backoff`` parameters to ``stream`` method.
#
# When acquiring data, if the rate of acquisition request is faster
# than what hardware can prepare the data, then the underlying implementation
# reports special error code, and expects client code to retry.
# When acquiring data, if the rate of acquisition requests is higher
# than that at which the hardware can prepare the data, then
# the underlying implementation reports special error code, and expects
# client code to retry.
#
# Precise timing is the key for smooth streaming. Reporting this error
# from low level implementation to all the way back to Python layer,
# from low-level implementation all the way back to Python layer,
# before retrying adds undesired overhead.
# For this reason, the retry behavior is implemented in C++ layer, and
# ``timeout`` and ``backoff`` parameters allow client code to control the
......@@ -177,7 +178,7 @@ def stream(q, format, src, segment_length, sample_rate):
# If ``backoff`` value is too large, then the data stream is discontinuous.
# The resulting audio sounds sped up.
# If ``backoff`` value is too small or zero, the audio stream is fine,
# but the data acquisitoin process enters busy-waiting state, and
# but the data acquisition process enters busy-waiting state, and
# this increases the CPU consumption.
#
......@@ -187,7 +188,7 @@ def stream(q, format, src, segment_length, sample_rate):
#
# The next step is to create components required for inference.
#
# The is the same process as
# This is the same process as
# `Online ASR with Emformer RNN-T <./online_asr_tutorial.html>`__.
#
......@@ -212,7 +213,7 @@ class Pipeline:
self.hypothesis = None
def infer(self, segment: torch.Tensor) -> str:
"""Peform streaming inference"""
"""Perform streaming inference"""
features, length = self.feature_extractor(segment)
hypos, self.state = self.decoder.infer(
features, length, self.beam_width, state=self.state, hypothesis=self.hypothesis
......@@ -252,7 +253,7 @@ class ContextCacher:
# 5. The main process
# -------------------
#
# The execution flow of the main process is as follow
# The execution flow of the main process is as follows:
#
# 1. Initialize the inference pipeline.
# 2. Launch data acquisition subprocess.
......
......@@ -265,16 +265,11 @@ int Streamer::process_packet_block(double timeout, double backoff) {
if (dead_line < std::chrono::steady_clock::now()) {
return ret;
}
// ffmpeg sleeps 10 milli seconds if the read happens in a separate thread
// FYI: ffmpeg sleeps 10 milli seconds if the read happens in a separate
// thread
// https://github.com/FFmpeg/FFmpeg/blob/b0f8dbb0cacc45a19f18c043afc706d7d26bef74/fftools/ffmpeg.c#L3952
// https://github.com/FFmpeg/FFmpeg/blob/b0f8dbb0cacc45a19f18c043afc706d7d26bef74/fftools/ffmpeg.c#L4542
//
// But it does not seem to sleep when running in single thread.
// Empirically we observed that the streaming result is worse with sleep.
// busy-waiting is not a recommended way to resolve this, but after simple
// testing, there wasn't a noticible difference in CPU utility. So we do not
// sleep here.
//
std::this_thread::sleep_for(sleep);
}
}
......
......@@ -423,7 +423,7 @@ class Streamer:
def process_packet(self, timeout: Optional[float] = None, backoff: float = 10.0) -> int:
"""Read the source media and process one packet.
If a packet is read successfuly, then the data in the packet will
If a packet is read successfully, then the data in the packet will
be decoded and passed to corresponding output stream processors.
If the packet belongs to a source stream that is not connected to
......@@ -461,10 +461,10 @@ class Streamer:
backoff (float, optional): Time to wait before retrying in milli seconds.
This optioin is effective only when `timeout` is effective. (not ``None``)
This option is effective only when `timeout` is effective. (not ``None``)
When `timeout` is effective, this `backoff` controls how long the function
should wait before retry-ing. Default: ``10.0``.
should wait before retrying. Default: ``10.0``.
Returns:
int:
......@@ -531,7 +531,7 @@ class Streamer:
Returns:
Iterator[Tuple[Optional[torch.Tensor], ...]]:
Iterator that yields a tuple of chunks that correpond to the output
Iterator that yields a tuple of chunks that correspond to the output
streams defined by client code.
If an output stream is exhausted, then the chunk Tensor is substituted
with ``None``.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment