[pulseaudio-discuss] Writing an output module

[Damien DEJEAN]

Hello,

> As your message was waiting moderation and as you asked a question that
> may gather some replies, I've subscribed you to the list. I hope that's
> OK? If it's a problem you can unsubscribe over at:
There's no problem, it's perfect !
>
> Well, overall you'll be writing a "Sink" module. This is an output
> device module and it will likely connect direct to your server.
>
> The sink itself will advertise a fixed sample format and then PA will
> internally handle any input stream remixing when the stream is connected
> to that sink. It is then the sinks responsibility to process the actual
> data. While it's certainly not perfect, this is how e.g. the ROAP sink
> works, so it may be a good idea to look at the structure of that code
> and just replace the RAOP/RTP things with calls to your library.
Ok I will glance at this implementation.
>
> Can I ask what the small sound server is? For small computers
> (especially those run off battery or where power saving is desirable)
> PulseAudio is one of the only systems to do advanced driving of the alsa
> devices using it's timer based scheduling... this approach can save up
> to half a watt in power based on current tests. Why is PulseAudio itself
> not appropriate for these small computers? (it's already used in several
> embedded systems for the reasons of power saving listed above).
In my school, we're using lightweight terminals with XDMCP protocol to 
connect to a server and work on it. These terminal are little machines 
with 800Mhz CPU, 256Mo of RAM a little graphical chip. The embedded 
Linux system is pretty old (linux 2.4, OSS, and an old libc). Nowadays, 
there is only one way to have sound on these TX, it is to use an old 
server developped by students for a video games which worked on the 
server and "displays" sound and pictures on the clients (X terminals). 
So, I rewrote a client library to use with the sound server running on 
these. Then I hope we could install PulseAudio on the server, and send 
directly the sound of one user session directly to the TX.

There is no challenge of power energy consumption, I just try to improve 
the user-friendness of this kind of systems. I try to re-use already 
written code because I don't really want to re-create a full compile 
environnement to be able to compile for these old systems ^^"

Thank you a lot for your answer,

Damien.
> Col
>
>