[musicians-guide] Grammar improvements in Chapter 2

[Eduardo Mayorga Téllez]

commit 0bdc46e322773a359e5d45c0b00e1cfc32e373e9
Author: Eduardo Mayorga <mayorga at 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" />.