patch-2.4.3 linux/drivers/sound/wavfront.c
Next file: linux/drivers/sound/ymfpci.c
Previous file: linux/drivers/sound/via82cxxx_audio.c
Back to the patch index
Back to the overall index
- Lines: 45
- Date:
Fri Mar 2 11:12:11 2001
- Orig file:
v2.4.2/linux/drivers/sound/wavfront.c
- Orig date:
Wed Feb 21 18:20:35 2001
diff -u --recursive --new-file v2.4.2/linux/drivers/sound/wavfront.c linux/drivers/sound/wavfront.c
@@ -94,7 +94,7 @@
#ifdef CONFIG_SMP
#define LOOPS_PER_TICK cpu_data[smp_processor_id()].loops_per_jiffy
#else
-#define LOOPS_PER_TICK loops_per_sec
+#define LOOPS_PER_TICK loops_per_jiffy
#endif
#endif
@@ -693,7 +693,7 @@
/***********************************************************************
WaveFront: data munging
-Things here are wierd. All data written to the board cannot
+Things here are weird. All data written to the board cannot
have its most significant bit set. Any data item with values
potentially > 0x7F (127) must be split across multiple bytes.
@@ -702,7 +702,7 @@
that is represented on the x86 side as an array of bytes. The most
efficient approach to handling both cases seems to be to use 2
different functions for munging and 2 for de-munging. This avoids
-wierd casting and worrying about bit-level offsets.
+weird casting and worrying about bit-level offsets.
**********************************************************************/
@@ -1213,7 +1213,7 @@
shptr = munge_int32 (*((UINT32 *) &header->hdr.s.sampleEndOffset),
shptr, 4);
- /* This one is truly wierd. What kind of wierdo decided that in
+ /* This one is truly weird. What kind of weirdo decided that in
a system dominated by 16 and 32 bit integers, they would use
a just 12 bits ?
*/
@@ -3069,7 +3069,7 @@
This code was developed using DOSEMU. The Turtle Beach SETUPSND
utility was run with I/O tracing in DOSEMU enabled, and a reconstruction
of the port I/O done, using the Yamaha faxback document as a guide
- to add more logic to the code. Its really pretty wierd.
+ to add more logic to the code. Its really pretty weird.
There was an alternative approach of just dumping the whole I/O
sequence as a series of port/value pairs and a simple loop
FUNET's LINUX-ADM group, linux-adm@nic.funet.fi
TCL-scripts by Sam Shen (who was at: slshen@lbl.gov)