Some ideas for the implementation of PulseAudio features
- rewind, we don't want to do rewinds, we would keep the maximum latency at the render side reasonably low (21.33ms, or 1024 samples at 48KHz) and simply allow this worst-case latency between volume changes or stream switches.
- Mixer API:
We would like to have each physical output path have a separate node, selecting on path would make other paths inactive, possibly using UCM.We're using the exact same pulseaudio code and config files to set up devices and mixers, ports and jack detection. There should not be any difference between PipeWire and PulseAudio on how devices are detected and controlled.
- Work on implementing the relevant modules
Maybe we can use the pulseaudio config files to generate a UCM profile for the card.We use the PulseAudio code to deal with UCM.
- we would want a client replacement library that speaks directly to PipeWire to make existing clients work without changes.
- pulseaudio clients use the pw_stream API and this run format conversions locally. This currently wakes up the client for each period but is more than fast enough because we do buffering in the adapter and don't need to go to the application more often than the requested latency.
- volume/mute control on the stream is done on the local adapter. Also rate changes are handled locally.
- We get precise timing from the server and calculate local buffering in the adapter.
- Config info like default devices, volumes, stream routing is managed with metadata. This makes it possible to control and introspect the state with simple tools like pw-metadata without the need to design complicated APIs. The session manager can easily save metadata to a database as well.
The PulseAudio external services:
We want to move the various pulseaudio modules to a separate service daemon, probably a module in the session manager. This includes:
- Streaming (RTP, possible a good time to rewrite using gstreamer)
- bluetooth handling
- We want to write an echo cancellation node