At Sun, 22 Feb 2009 07:54:10 -0600,
Patricio Paez wrote:
>
>
> Signed-off-by: Patricio Paez <pp@xxxxxxxxx>
Applied. Thanks!
Takashi
>
> diff --git a/src/seq/seq.c b/src/seq/seq.c
> index feb9733..7b777a1 100644
> --- a/src/seq/seq.c
> +++ b/src/seq/seq.c
> @@ -30,7 +30,7 @@
>
> /*! \page seq Sequencer interface
>
> -\section seq_general Genral
> +\section seq_general General
>
> The ALSA sequencer interface is designed to deliver the MIDI-like
> events between clients/ports.
> @@ -76,10 +76,10 @@ A client can have one or more <i>ports</i> to communicate between other
> clients. A port is corresponding to the MIDI port in the case of MIDI device,
> but in general it is nothing but the access point between other clients.
> Each port may have capability flags, which specify the read/write
> -accessbility and subscription permissions of the port.
> +accessibility and subscription permissions of the port.
> For creation of a port, call #snd_seq_create_port()
> -with the appropirate port attribute specified in #snd_seq_port_info_t
> -reocrd.
> +with the appropriate port attribute specified in #snd_seq_port_info_t
> +record.
>
> For creating a port for the normal use, there is a helper function
> #snd_seq_create_simple_port(). An example with this function is like below.
> @@ -102,7 +102,7 @@ Here, input and output mean
> input (read) from other clients and output (write) to others, respectively.
> Since memory pool of each client is independent from others,
> it avoids such a situation that a client eats the whole events pool
> -and interfere other clients' responce.
> +and interfere other clients' response.
>
> The all scheduled output events or input events from dispatcher are stored
> on these pools until delivered to other clients or extracted to user space.
> @@ -171,7 +171,7 @@ the MIDI events like program, velocity or chorus effects.
> This application can accept arbitrary MIDI input
> and send to arbitrary port, just like a Unix pipe application using
> stdin and stdout files.
> -We can even connect several filter applictions which work individually
> +We can even connect several filter applications which work individually
> in order to process the MIDI events.
> Subscription can be used for this purpose.
> The connection between ports can be done also by the "third" client.
> @@ -199,7 +199,7 @@ All the sequencer events are stored in a sequencer event record,
> #snd_seq_event_t type.
> Application can send and receive these event records to/from other
> clients via sequencer.
> -An event has several stroage types according to its usage.
> +An event has several storage types according to its usage.
> For example, a SYSEX message is stored on the variable length event,
> and a large synth sample data is delivered using a user-space data pointer.
>
> @@ -227,7 +227,7 @@ The type field contains the type of the event
> (1 byte).
> The flags field consists of bit flags which
> describe several conditions of the event (1 byte).
> -It includes the time-stamp mode, data storage type, and scheduling prority.
> +It includes the time-stamp mode, data storage type, and scheduling priority.
> The tag field is an arbitrary tag.
> This tag can used for removing a distinct event from the event queue
> via #snd_seq_remove_events().
> @@ -240,7 +240,7 @@ The data field is a union of event data.
> An event can be delivered either on scheduled or direct dispatch mode.
> On the scheduling mode, an event is once stored on the priority queue
> and delivered later (or even immediately) to the destination,
> -whereas on the direct disatch mode, an event is passed to the destination
> +whereas on the direct dispatch mode, an event is passed to the destination
> without any queue.
>
> For a scheduled delivery, a queue to process the event must exist.
> @@ -284,7 +284,7 @@ The time stored in an event record is a union of these two different
> time values.
>
> Note that the time format used for real time events is very similar to
> -timeval struct used for unix system time.
> +timeval struct used for Unix system time.
> The absurd resolution of the timestamps allows us to perform very accurate
> conversions between songposition and real time. Round-off errors can be
> neglected.
> @@ -299,7 +299,7 @@ counted from the moment when the queue started.
> An client that relies on these relative timestamps is the MIDI input port.
> As each sequencer queue has it's own clock the only way to deliver events at
> the right time is by using the relative timestamp format. When the event
> -arrives at the queue it is normalised to absolute format.
> +arrives at the queue it is normalized to absolute format.
>
> The timestamp format is specified in the flag bitfield masked by
> #SND_SEQ_TIME_STAMP_MASK.
> @@ -320,7 +320,7 @@ fill the port id of source.port and
> both client and port of dest field.
>
> If an existing address is set to the destination,
> -the event is simplly delivered to it.
> +the event is simply delivered to it.
> When #SND_SEQ_ADDRESS_SUBSCRIBERS is set to the destination client id,
> the event is delivered to all the clients connected to the source port.
>
> @@ -346,7 +346,7 @@ an announcement is sent to subscribers from this port.
>
> Some events like SYSEX message, however, need larger data space
> than the standard data.
> -For such events, ALSA sequencer provides seveal different data storage types.
> +For such events, ALSA sequencer provides several different data storage types.
> The data type is specified in the flag bits masked by #SND_SEQ_EVENT_LENGTH_MASK.
> The following data types are available:
>
> @@ -359,7 +359,7 @@ A macro #snd_seq_ev_set_fixed() is provided to set this type.
> \par Variable length data
> SYSEX or a returned error use this type.
> The actual data is stored on an extra allocated space.
> -On sequecer kernel, the whole extra-data is duplicated, so that the event
> +On sequencer kernel, the whole extra-data is duplicated, so that the event
> can be scheduled on queue.
> The data contains only the length and the
> pointer of extra-data.
> @@ -430,7 +430,7 @@ Note that PPQ cannot be changed while the queue is running.
> It must be set before the queue is started.
>
> On the other hand, in the case of <i>realtime</i> queue, the
> -time resolution is fixed to nanosecononds. There is, however,
> +time resolution is fixed to nanoseconds. There is, however,
> a parameter to change the speed of this queue, called <i>skew</i>.
> You can make the queue faster or slower by setting the skew value
> bigger or smaller. In the API, the skew is defined by two values,
> @@ -488,7 +488,7 @@ special settings.
> In the above example, the tempo is changed immediately after
> the buffer is flushed by #snd_seq_drain_output() call.
> You can schedule the event in a certain queue so that the tempo
> -change happes at the scheduled time, too.
> +change happens at the scheduled time, too.
>
> \subsection seq_ev_start Starting and stopping a queue
>
> @@ -515,7 +515,7 @@ Each ALSA port can have capability flags.
> The most basic capability flags are
> #SND_SEQ_PORT_CAP_READ and #SND_SEQ_PORT_CAP_WRITE.
> The former means that the port allows to send events to other ports,
> -whereas the latter capability menas
> +whereas the latter capability means
> that the port allows to receive events from other ports.
> You may have noticed that meanings of \c READ and \c WRITE
> are permissions of the port from the viewpoint of other ports.
> @@ -536,7 +536,7 @@ Obviously, these flags have no influence
> if \c READ or \c WRITE> capability is not set.
>
> Note that these flags are not necessary if the client subscribes itself
> -to the spcified port.
> +to the specified port.
> For example, when a port makes READ subscription
> to MIDI input port, this port must have #SND_SEQ_PORT_CAP_WRITE capability,
> but no #SND_SEQ_PORT_CAP_SUBS_WRITE capability is required.
> @@ -610,7 +610,7 @@ if #SND_SEQ_PORT_CAP_NO_EXPORT capability is set in either sender or receiver po
>
> Assume MIDI input port = 64:0, application port = 128:0, and
> queue for timestamp = 1 with real-time stamp.
> -The application port must have capabilty #SND_SEQ_PORT_CAP_WRITE.
> +The application port must have capability #SND_SEQ_PORT_CAP_WRITE.
> \code
> void capture_keyboard(snd_seq_t *seq)
> {
> @@ -633,7 +633,7 @@ void capture_keyboard(snd_seq_t *seq)
> \subsection seq_subs_ex_out Output to MIDI device
>
> Assume MIDI output port = 65:1 and application port = 128:0.
> -The application port must have capabilty #SND_SEQ_PORT_CAP_READ.
> +The application port must have capability #SND_SEQ_PORT_CAP_READ.
> \code
> void subscribe_output(snd_seq_t *seq)
> {
> @@ -790,7 +790,7 @@ void event_filter(snd_seq_t *seq, snd_seq_event_t *ev)
> /**
> * \brief get identifier of sequencer handle
> * \param seq sequencer handle
> - * \return ascii identifier of sequencer handle
> + * \return ASCII identifier of sequencer handle
> *
> * Returns the ASCII identifier of the given sequencer handle. It's the same
> * identifier specified in snd_seq_open().
> @@ -1610,7 +1610,7 @@ void snd_seq_client_info_event_filter_del(snd_seq_client_info_t *info, int event
> * \param event_type event type to be checked
> * \return 1 if the event type is present, 0 otherwise
> *
> - * Test if the event type is in the filter bitamp of this client_info container.
> + * Test if the event type is in the filter bitmap of this client_info container.
> *
> * \sa snd_seq_get_client_info(),
> * snd_seq_set_client_info(),
> diff --git a/src/seq/seqmid.c b/src/seq/seqmid.c
> index 3b0960d..86a4970 100644
> --- a/src/seq/seqmid.c
> +++ b/src/seq/seqmid.c
> @@ -317,7 +317,7 @@ int snd_seq_set_client_pool_input(snd_seq_t *seq, size_t size)
> * \param seq sequencer handle
> * \return 0 on success or negative error code
> *
> - * So far, this works ideically like #snd_seq_drop_output().
> + * So far, this works identically like #snd_seq_drop_output().
> */
> int snd_seq_reset_pool_output(snd_seq_t *seq)
> {
> @@ -329,7 +329,7 @@ int snd_seq_reset_pool_output(snd_seq_t *seq)
> * \param seq sequencer handle
> * \return 0 on success or negative error code
> *
> - * So far, this works ideically like #snd_seq_drop_input().
> + * So far, this works identically like #snd_seq_drop_input().
> */
> int snd_seq_reset_pool_input(snd_seq_t *seq)
> {
> --
> 1.5.6.3
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@xxxxxxxxxxxxxxxx
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
