mirror of
https://gitlab.freedesktop.org/pipewire/pipewire
synced 2024-10-14 11:53:16 +00:00
doc: fix typos
Signed-off-by: Siwon Kang <siwon.kang@daimler.com>
This commit is contained in:
parent
e59c4675a7
commit
f7b22b934c
|
@ -44,7 +44,7 @@ Upon connecting to a server, it will broadcast its state. Clients
|
|||
should listen for these state changes and cache them. There is no
|
||||
need (or mechanism) to query the state of the server.
|
||||
|
||||
The server also have a registry object that, when listening to,
|
||||
The server also has a registry object that, when listening to,
|
||||
will broadcast the presence of global objects and any changes in
|
||||
their state.
|
||||
|
||||
|
@ -129,7 +129,7 @@ life cycle management.
|
|||
|
||||
A proxy to a PipeWire registry object. It emits events about the
|
||||
available objects on the server and can be used to bind to those
|
||||
objects in order call methods or receive events from them.
|
||||
objects in order to call methods or receive events from them.
|
||||
|
||||
### `struct pw_module`
|
||||
|
||||
|
@ -193,7 +193,7 @@ do the connection for the client and then hands the connection socket
|
|||
to the client.
|
||||
|
||||
All objects in PipeWire have per client permission bits, currently
|
||||
READ, WRITE, EXECUTE and METADATA. A client can not see an objects
|
||||
READ, WRITE, EXECUTE and METADATA. A client can not see an object
|
||||
unless it has READ permissions. Similarly, a client can only execute
|
||||
methods on an object when the EXECUTE bit is set and to modify the
|
||||
state of an object, the client needs WRITE permissions.
|
||||
|
|
|
@ -20,7 +20,7 @@ The framework is used to build a modular daemon that can be configured to:
|
|||
## Motivation
|
||||
|
||||
Linux has no unified framework for exchanging multimedia content between
|
||||
applications or even devices. Im most cases, developers realized that
|
||||
applications or even devices. In most cases, developers realized that
|
||||
a user-space daemon is needed to make this possible:
|
||||
|
||||
* For video content, we typically rely on the compositor to render our
|
||||
|
@ -33,7 +33,7 @@ a user-space daemon is needed to make this possible:
|
|||
|
||||
None of these solutions (with perhaps to some extend Wayland), however,
|
||||
were designed to support the security features that are required when
|
||||
daeling with flatpaks or other containerized applications. PipeWire
|
||||
dealing with flatpaks or other containerized applications. PipeWire
|
||||
aims to solve this problem and provides a unified framework to run both
|
||||
consumer and Pro audio as well as video capture and processing in a
|
||||
secure way.
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# PipeWire Tutorial
|
||||
|
||||
Welcome to the PipeWire tutorial. The goal is to learn to
|
||||
Welcome to the PipeWire tutorial. The goal is to learn
|
||||
PipeWire API step-by-step with simple short examples.
|
||||
|
||||
1) Getting started ([tutorial 1](tutorial1.md)).
|
||||
|
|
|
@ -155,7 +155,7 @@ and a callback + data.
|
|||
&data);
|
||||
```
|
||||
|
||||
We using `pw_stream_new_simple()` but there is also a `pw_stream_new()` that
|
||||
We are using `pw_stream_new_simple()` but there is also a `pw_stream_new()` that
|
||||
takes an existing `struct pw_core` as the first argument and that requires you
|
||||
to add the event handle manually, for more control. The `pw_stream_new_simple()`
|
||||
is, as the name implies, easier to use because it creates a `struct pw_context`
|
||||
|
@ -225,7 +225,7 @@ Now we're ready to connect the stream and run the main loop:
|
|||
pw_main_loop_run(data.loop);
|
||||
```
|
||||
|
||||
To connect we specify that we have an `PW_DIRECTION_OUTPUT` stream. `PW_ID_ANY`
|
||||
To connect we specify that we have a `PW_DIRECTION_OUTPUT` stream. `PW_ID_ANY`
|
||||
means that we are ok with conneting to any consumer. Next we set some flags:
|
||||
|
||||
* `PW_STREAM_FLAG_AUTOCONNECT` automatically connect this stream. This instructs
|
||||
|
@ -242,7 +242,7 @@ And last we pass the extra parameters for our stream. Here we only have the
|
|||
allowed formats (`SPA_PARAM_EnumFormat`).
|
||||
|
||||
Running the mainloop will then start processing and will result in our
|
||||
`process` callback to be called. Let have a look at that function now.
|
||||
`process` callback to be called. Let's have a look at that function now.
|
||||
|
||||
The main program flow of the process function is:
|
||||
|
||||
|
|
|
@ -178,7 +178,7 @@ static const struct pw_stream_events stream_events = {
|
|||
};
|
||||
```
|
||||
|
||||
Because we are a capture stream and we can accept a wide range of different
|
||||
Because we capture a stream of a wide range of different
|
||||
video formats and resolutions, we have to describe our accepted formats in
|
||||
a different way:
|
||||
|
||||
|
@ -262,7 +262,7 @@ Now we're ready to connect the stream and run the main loop:
|
|||
pw_main_loop_run(data.loop);
|
||||
```
|
||||
|
||||
To connect we specify that we have an `PW_DIRECTION_INPUT` stream. `PW_ID_ANY`
|
||||
To connect we specify that we have a `PW_DIRECTION_INPUT` stream. `PW_ID_ANY`
|
||||
means that we are ok with connecting to any producer. We also allow the user
|
||||
to pass an optional target id.
|
||||
|
||||
|
@ -280,7 +280,7 @@ negotiated between our stream and the camera. This is always something that
|
|||
is compatible with what we enumerated in the EnumFormat param when we
|
||||
connected.
|
||||
|
||||
Let's take a look a how we can parse the format in the `param_changed`
|
||||
Let's take a look at how we can parse the format in the `param_changed`
|
||||
event:
|
||||
|
||||
```c
|
||||
|
@ -296,7 +296,7 @@ First check if there is a param. A NULL param means that it is cleared. The id
|
|||
of the param tells you what param it is. We are only interested in Format
|
||||
param (`SPA_PARAM_Format`).
|
||||
|
||||
We can parse the media type and subtype as follows and ensure that it is
|
||||
We can parse the media type and subtype as below and ensure that it is
|
||||
of the right type. In our example this will always be true but when your
|
||||
EnumFormat contains different media types or subtypes, this is how you can
|
||||
parse them:
|
||||
|
|
|
@ -173,7 +173,7 @@ We're also quitting the mainloop after we get the info to nicely stop
|
|||
our tutorial application.
|
||||
|
||||
When we stop the application, don't forget to destroy all proxies that
|
||||
you created or they will be leaked:
|
||||
you created. Otherwise, they will be leaked:
|
||||
|
||||
```c
|
||||
/* ... */
|
||||
|
|
Loading…
Reference in a new issue