* The http sender is recommended for public streams that can be played
by any player like mpg123, xmms, itunes, winamp...
- * The dccp sender is experimental and requires kernel support for the
- rather new datagram congestion control protocol.
+ * The dccp sender requires kernel support for the rather new datagram
+ congestion control protocol.
- * The ortp sender is recommended for multicast LAN streaming
+ * The ortp sender is recommended for multicast LAN streaming.
It is possible to activate more than one sender simultaneously.
Its features include
- * attributes: Allow fine-grained audio file selection.
+ * attributes. Allow fine-grained audio file selection.
* image table. For storage of e.g. album cover art.
* mood mode. Audio file selection works by specifying mood
methods involving attributes, pattern matching for file names
- and more. This allows rather sophisticated configurations
- and is explained in more detail in INSTALL.
+ and more. This allows rather sophisticated configurations
+ and is explained in more detail in
+<<
+<a href="README.afs.html"> README.afs </a>
+>>
* rename detection. If files are moved or renamed, afs will
- recognioze them despite of this change.
+ recognize them despite of this change.
Despite of all these features, paraslash is lightweight. The
stripped binary of para_server with all its features compiled in
---------
A command line http/dccp/rtp stream grabber. The http mode of this tool
-can be used to receive date from any http streaming source.
+can be used to receive data from any http streaming source.
-----------
para_filter
-----------
-A filter program that converts from stdin and writes to stdout. It
-is completely independent from the rest of paraslash, so it might be
-useful also for different purposes.
+A filter program that converts from stdin and writes to stdout.
para_filter combines several decoders (mp3, oggvorbis, aac) and a
-volume normalizer New filters can be added easily due to the modular
-design. If more than one filter is specified, the given filters
-are 'piped' together in-memory, i.e. without calling any of the
-read(2)/write(2)/select(2) etc. functions.
+volume normalizer. New filters can be added easily. It is possible
+to "chain" any number of filters, like unix pipes.
+
+para_filter does not depend on other parts of paraslash, so it can
+be used as a stand-alone command line tool for audio decoding.
----------
para_write
The local daemon that collects information from para_server.
-It runs on the client side and connects to para_server. The audio stream is
-read from the network and sent through any of paraslash's filters (decoder,
-volume normalizer). The resulting stream is written to an output plug-in
-(writer), e.g. the alsa writer on linux systems. It is possible to capture the
-stream at any position in the filter chain.
+It runs on the client side and connects to para_server. As soon as
+para_server announces the availability (and the type) of an audio
+stream, para_audiod starts an appropriate receiver, any number of
+filters and a paraslash writer to play the stream. It is possible to
+capture the stream at any position in the filter chain.
-para_audiod starts an appropriate receiver, filter and player as soon as
-para_server announces the availability (and the type) of an audio stream.
-Moreover, it listens on a local socket and sends status information about
-para_server and para_audiod to local clients on request.
+Moreover, para_audiod listens on a local socket and sends status
+information about para_server and para_audiod to local clients on
+request. Access via this local socket may be restricted by using Unix
+socket credentials, if available.
-----------
para_audioc
para_audiod, to receive status info, or to grab the stream at any
point in the filter chain.
-para_audioc (hence para_audiod) is needed by para_gui, para_sdl_gui
-and para_krell, see below.
+para_audioc (hence para_audiod) is needed by para_gui see below.
--------
para_gui
projects / paraslash.git / blobdiff