commit 0bdc46e322773a359e5d45c0b00e1cfc32e373e9
Author: Eduardo Mayorga <mayorga(a)fedoraproject.org>
Date: Sat Feb 1 17:31:33 2014 +0100
Grammar improvements in Chapter 2
en-US/Sound_Servers.xml | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
---
diff --git a/en-US/Sound_Servers.xml b/en-US/Sound_Servers.xml
index c082b79..2755f34 100644
--- a/en-US/Sound_Servers.xml
+++ b/en-US/Sound_Servers.xml
@@ -7,13 +7,13 @@
<chapter id="chap-Musicians_Guide-How_Computers_Deal_with_Hardware">
<title>Software for Sound Cards</title>
<para> <!-- TODO: this description could use an extensive re-working, possibly
with a graphical example -->
- One of the techniques consistently used in computer science is abstraction.
Abstraction is the process of creating a generic model for something (or some things) that
are actually unique. The "driver" for a hardware device in a computer is one
form of dealing with abstraction: the computer's software interacts with all sound
cards in a similar way, and it is the driver which translates the universal instructions
given by the software into specific instructions for operating that hardware device.
Consider this real-world comparison: you know how to operate doors because of abstracted
instructions. You don't know how to open and close every door that exists, but from
the ones that you do know how to operate, your brain automatically creates abstracted
instructions, like "turn the handle," and "push the door," which apply
with all or most doors. When you see a new door, you have certain expectations about how
it works, based on the abstract behaviour of doors, and you qu
ickly figure out how to operate that specific door with a simple visual inspection. The
principle is the same with computer hardware drivers: since the computer already knows how
to operate "sound cards," it just needs a few simple instructions (the driver)
in order to know how to operate any particular sound card.
+ One of the techniques consistently used in computer science is abstraction.
Abstraction is the process of creating a generic model for something (or some things) that
are actually unique. The "driver" for a hardware device in a computer is one
form of dealing with abstraction: the computer's software interacts with all sound
cards in a similar way, and it is the driver which translates the universal instructions
given by the software into specific instructions for operating that hardware device.
Consider this real-world comparison: you know how to operate doors because of abstracted
instructions. You don't know how to open and close every door that exists, but from
the ones that you do know how to operate, your brain automatically creates abstracted
instructions, like "turn the handle," and "push the door," which apply
with all or most doors. When you see a new door, you have certain expectations about how
it works, based on the abstract behavior of doors, and you qui
ckly figure out how to operate that specific door with a simple visual inspection. The
principle is the same with computer hardware drivers: since the computer already knows how
to operate "sound cards," it just needs a few simple instructions (the driver)
in order to know how to operate any particular sound card.
</para>
<section id="sect-Musicians_Guide-Sound_Servers-ALSA">
<title>How Linux Deals with Audio Hardware</title>
<para>
- In Linux, the core of the operating system provides hardware drivers for most audio
hardware. The hardware drivers, and the instructions that other software can use to
connect to those drivers, are collectively called "ALSA," which stands for
"Advanced Linux Sound Architecture." ALSA is the most direct way that software
applications can interact with audio and MIDI hardware, and it used to be the most common
way. However, in order to include all of the features that a software application might
want to use, ALSA is quite complex, and can be error-prone. For this and many other
reasons, another level of abstraction is normally used, and this makes it easier for
software applications to take advantage of the features they need.
+ In Linux, the core of the operating system provides hardware drivers for most audio
hardware. The hardware drivers, and the instructions that other software can use to
connect to those drivers, are collectively called "ALSA," which stands for
"Advanced Linux Sound Architecture." ALSA is the most direct way that software
applications can interact with audio and MIDI hardware, and it used to be the most common
way. However, in order to include all the features that a software application might want
to use, ALSA is quite complex, and can be error-prone. For this and many other reasons,
another level of abstraction is normally used, and this makes it easier for software
applications to take advantage of the features they need.
</para>
</section>
@@ -93,7 +93,7 @@
<section id="sect-Musicians_Guide-Using_QjackCtl">
<title>Using <application>QjackCtl</application></title>
<para>
- The <application>QjackCtl</application> application offers many more
features and configuration options. The patch bay is a notable feature, which lets users
save configurations of the "Connections" window, and restore them later, to help
avoid the lengthy set-up time that might be required in complicated routing and
multiplexing situations.
+ The <application>QjackCtl</application> application offers many more
features and configuration options. The patch bay is a notable feature, which lets users
save configurations of the "Connections" window, and restore them later, to help
avoid the lengthy setup time that might be required in complicated routing and
multiplexing situations.
</para>
<para>
For more information on <application>QjackCtl</application>, refer to
<citetitle>Jack Audio Connection Kit (64studio)</citetitle> at <ulink
url="http://www.64studio.com/manual/audio/jack" />.