From: rjk@greenend.org.uk <>
Date: Sun, 23 Sep 2007 19:19:40 +0000 (+0100)
Subject: doxygen
X-Git-Tag: debian-1_5_99dev8~243^2~13
X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~mdw/git/disorder/commitdiff_plain/795192f4c5b972ddcb3b4bdcba0037567cf9c4c4
doxygen
---
diff --git a/clients/playrtp.c b/clients/playrtp.c
index fb897ce..c6260d9 100644
--- a/clients/playrtp.c
+++ b/clients/playrtp.c
@@ -294,7 +294,7 @@ static const struct option options[] = {
{ 0, 0, 0, 0 }
};
-/** @Brief Return a new packet */
+/** @brief Return a new packet */
static struct packet *new_packet(void) {
struct packet *p;
diff --git a/server/speaker.c b/server/speaker.c
index f97bb69..4b3f7dc 100644
--- a/server/speaker.c
+++ b/server/speaker.c
@@ -25,9 +25,9 @@
* subprocess). It receives connections from decoders via file descriptor
* passing from the main server and plays them in the right order.
*
- * For the ALSA API, 8- and 16- bit
- * stereo and mono are supported, with any sample rate (within the limits that
- * ALSA can deal with.)
+ * @b Encodings. For the ALSA API,
+ * 8- and 16- bit stereo and mono are supported, with any sample rate (within
+ * the limits that ALSA can deal with.)
*
* When communicating with a subprocess, sox is invoked to convert the inbound
@@ -39,12 +39,19 @@
* between versions; the speaker is assumed to be built from the same source
* and run on the same host as the main server.
*
- * This program deliberately does not use the garbage collector even though it
- * might be convenient to do so. This is for two reasons. Firstly some sound
- * APIs use thread threads and we do not want to have to deal with potential
- * interactions between threading and garbage collection. Secondly this
- * process needs to be able to respond quickly and this is not compatible with
- * the collector hanging the program even relatively briefly.
+ * @b Garbage @b Collection. This program deliberately does not use the
+ * garbage collector even though it might be convenient to do so. This is for
+ * two reasons. Firstly some sound APIs use thread threads and we do not want
+ * to have to deal with potential interactions between threading and garbage
+ * collection. Secondly this process needs to be able to respond quickly and
+ * this is not compatible with the collector hanging the program even
+ * relatively briefly.
+ *
+ * @b Units. This program thinks at various times in three different units.
+ * Bytes are obvious. A sample is a single sample on a single channel. A
+ * frame is several samples on different channels at the same point in time.
+ * So (for instance) a 16-bit stereo frame is 4 bytes and consists of a pair of
+ * 2-byte samples.
*/
#include