<HTML>
<HEAD>
<TITLE>DeviceConfig</TITLE>
</HEAD>
<BODY BGCOLOR="#ffffff">
<p>
<A HREF="hier.html"> view hierachy</A>
<p>
<H2> Introduction</H2>


This directory contains outputdevices, like /dev/dsp or
timerdevices or something else.
<p>
What does this mean: devices?
<p>
You already know the term "device driver" for hardware. The devices
in this directory are software devices. 
This means that they are entered by a seperate thread. The thread
delivers "deviceConfig" data to the device. The device transform
the data into some other data. (eg: alters PCM data for another
volume) and then delivers the changed data to the connected
listeners.
(Yes you can cascade devices to "trees".)
This is a powerfull approach. A single device offers little functionallity,
but the advantage is that you can build more complex devices
out of these simple ones.

<p>
Ideas for other devices:
<pre>
* NetDevice (Stream PCM data to XDisplay with soundserver)
* More Plattform devices (sun,hp,...)(currently only Linux :)
* Analyser devices (spectrum analyser,.....really needed)
* Mutilcast devices (takes input from one device and streams it to n other
  devices (eg: the output is streamed to /dev/dsp and to a NetDevice)
  (This could implement a "radio" service)
* Filterdevices (eg:Equalizer, downsampling of stream (for netradio?))
* Mix devices (take input from n devices and mix them to one)
* Fixed Block device. A device which garanties that the Streambuffer
  has a known size, or is the last (eof) part
* Hm. Realtime device? A threaded device which does nothing more
  than write. The back thread must only fill the buffer of the
  realtime device. If this buffer is full the back thread blocks
  as well.(Audiodevices can derive from such a device, one possibility
  to get rid of the nasty "stops" under heavy load.

* A "poll" device. A device which blocks the back thread until
  it is read. This would allow a bitwise stepping through
  the stream and minimizes the danger that the thread makes
  something "nasty".

* A "window" device. This device is like the block device but
  only that it does not block. This device is usefull if
  a controlling GUI wants to have eg: The spectrum analyser
  data and is not so concerned that this is _really_ the
  data which is currently played.

* A pipe device. Its like a multicast device with only one
  slot for an output device. The pipe Device has the nice method 
  pipe(). This transfers data from the inputdevice to the output
  device
  This makes it easy for a GUI to poll the last valid data.(see EXAMPLE)

* Switch devices
  - n device are connected but only i<n are allowed to "write through" to 
    the connected other devices.  
more?

volunteers ?


* null device :)
* file device. Writes pcm data to a .wav file
* protocol devices. write pcm data to kaudioserver(does kaudioserver
  can read it?)/ rplay protokoll (sun)
* general analyser devices. If you record a tape with different
  mp3 files they mostly have different db values. (one is
  extremly loud the other not) A device should analyse all
  the files in your playlist an generate a value for
  each file (outscale faktor,...) When you record your files
  on tape the player can set a volume value for every mp3
  and they all have the same db value.
</pre>
<A HREF="hier.html"> view hierachy</A>


</BODY></HTML>


  
  
   





