auracaster/sw_pyalsaaudio
3
0
Fork 0
forked from auracaster/pyalsaaudio
Code Pull Requests Activity

Release 0.10.0

Browse Source
This commit is contained in:
Lars Immisch
2023-04-16 00:08:27 +02:00
parent cbca6be937
commit 6b17f924e4
15 changed files with 1021 additions and 895 deletions
Download Patch File Download Diff File Expand all files Collapse all files

71
terminology.html
View File

@@ -1,18 +1,17 @@
<!DOCTYPE html>
<html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.17.1: http://docutils.sourceforge.net/" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />
<title>PCM Terminology and Concepts &#8212; alsaaudio documentation 0.9.2 documentation</title>
<title>PCM Terminology and Concepts &#8212; alsaaudio documentation 0.10.0 documentation</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css" />
<script data-url_root="./" id="documentation_options" src="_static/documentation_options.js"></script>
<script src="_static/jquery.js"></script>
<script src="_static/underscore.js"></script>
<script src="_static/doctools.js"></script>
<script src="_static/sphinx_highlight.js"></script>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="alsaaudio" href="libalsaaudio.html" />
@@ -34,7 +33,7 @@
<div class="body" role="main">
<section id="pcm-terminology-and-concepts">
<h1>PCM Terminology and Concepts<a class="headerlink" href="#pcm-terminology-and-concepts" title="Permalink to this headline"></a></h1>
<h1>PCM Terminology and Concepts<a class="headerlink" href="#pcm-terminology-and-concepts" title="Permalink to this heading"></a></h1>
<p>In order to use PCM devices it is useful to be familiar with some concepts and
terminology.</p>
<dl>
@@ -49,47 +48,53 @@ they can be big endian byte integers, little endian byte integers, or
floating point numbers.</p>
<p>Musically, the sample size determines the dynamic range. The
dynamic range is the difference between the quietest and the
loudest signal that can be resproduced.</p>
loudest signal that can be reproduced.</p>
</dd>
<dt>Frame</dt><dd><p>A frame consists of exactly one sample per channel. If there is only one
channel (Mono sound) a frame is simply a single sample. If the sound is
stereo, each frame consists of two samples, etc.</p>
</dd>
<dt>Frame size</dt><dd><dl class="simple">
<dt>This is the size in bytes of each frame. This can vary a lot: if each sample</dt><dd><dl class="simple">
<dt>is 8 bits, and we’re handling mono sound, the frame size is one byte.</dt><dd><p>Similarly in 6 channel audio with 64 bit floating point samples, the frame
size is 48 bytes</p>
</dd>
</dl>
</dd>
</dl>
<dt>Frame size</dt><dd><p>This is the size in bytes of each frame. This can vary a lot: if each sample
is 8 bits, and we’re handling mono sound, the frame size is one byte.
For six channel audio with 64 bit floating point samples, the frame size
is 48 bytes.</p>
</dd>
<dt>Rate</dt><dd><p>PCM sound consists of a flow of sound frames. The sound rate controls how
often the current frame is replaced. For example, a rate of 8000 Hz
means that a new frame is played or captured 8000 times per second.</p>
</dd>
<dt>Data rate</dt><dd><p>This is the number of bytes, which must be recorded or provided per
<dt>Data rate</dt><dd><p>This is the number of bytes which must be consumed or provided per
second at a certain frame size and rate.</p>
<p>8000 Hz mono sound with 8 bit (1 byte) samples has a data rate of
8000 * 1 * 1 = 8 kb/s or 64kbit/s. This is typically used for telephony.</p>
<p>At the other end of the scale, 96000 Hz, 6 channel sound with 64
bit (8 bytes) samples has a data rate of 96000 * 6 * 8 = 4608
kb/s (almost 5 MB sound data per second)</p>
kb/s (almost 5 MB sound data per second).</p>
<p>If the data rate requirement is not met, an overrun (on capture) or
underrun (on playback) occurs; the term “xrun” is used to refer to
either event.</p>
</dd>
<dt>Period</dt><dd><p>When the hardware processes data this is done in chunks of frames. The time
interval between each processing (A/D or D/A conversion) is known
as the period.
The size of the period has direct implication on the latency of the
sound input or output. For low-latency the period size should be
very small, while low CPU resource usage would usually demand
larger period sizes. With ALSA, the CPU utilization is not impacted
much by the period size, since the kernel layer buffers multiple
periods internally, so each period generates an interrupt and a
memory copy, but userspace can be slower and read or write multiple
periods at the same time.</p>
</dl>
<dl id="term-period">
<dt>Period</dt><dd><p>The CPU processes sample data in chunks of frames, so-called periods
(also called fragments by some systems). The operating system kernel’s
sample buffer must hold at least two periods (at any given time, one
is processed by the sound hardware, and one by the CPU).</p>
<p>The completion of a <em>period</em> triggers a CPU interrupt, which causes
processing and context switching overhead. Therefore, a smaller period
size causes higher CPU resource usage at a given data rate.</p>
<p>A bigger size of the <em>buffer</em> improves the system’s resilience to xruns.
The buffer being split into a bigger number of smaller periods also does
that, as it allows it to be drained / topped up sooner.</p>
<p>On the other hand, a bigger size of the <em>buffer</em> also increases the
playback latency, that is, the time it takes for a frame from being
sent out by the application to being actually audible.</p>
<p>Similarly, a bigger <em>period</em> size increases the capture latency.</p>
<p>The trade-off between latency, xrun resilience, and resource usage
must be made depending on the application.</p>
</dd>
<dt>Period size</dt><dd><p>This is the size of each period in Hz. <em>Not bytes, but Hz!.</em> In
<a class="reference internal" href="libalsaaudio.html#module-alsaaudio" title="alsaaudio (Linux)"><code class="xref py py-mod docutils literal notranslate"><span class="pre">alsaaudio</span></code></a> the period size is set directly, and it is
<dt>Period size</dt><dd><p>This is the size of each period in frames. <em>Not bytes, but frames!</em>
In <a class="reference internal" href="libalsaaudio.html#module-alsaaudio" title="alsaaudio (Linux)"><code class="xref py py-mod docutils literal notranslate"><span class="pre">alsaaudio</span></code></a> the period size is set directly, and it is
therefore important to understand the significance of this
number. If the period size is configured to for example 32,
each write should contain exactly 32 frames of sound data, and each
@@ -145,7 +150,7 @@ on.</p>
</form>
</div>
</div>
<script>$('#searchbox').show(0);</script>
<script>document.getElementById('searchbox').style.display = "block"</script>
@@ -162,8 +167,8 @@ on.</p>
&copy;2017, Lars Immisch & Casper Wilstrup.
|
Powered by <a href="http://sphinx-doc.org/">Sphinx 4.5.0</a>
&amp; <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.12</a>
Powered by <a href="http://sphinx-doc.org/">Sphinx 6.1.3</a>
&amp; <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.13</a>
|
<a href="_sources/terminology.rst.txt"