Skip to content

GitLab

P
pipewire

TODO

Last edited by Wim Taymans
Page history

This is a list of things left to do:

Core

  • DLL on audio devices

    • This would generate a rate compared to either the system clock or against the current graph driver. This value can be used to adjust the rate of the device (if supported) or drive a resampler (in DSP or client or..). (DONE)

  • Add resampler in DSP

    • To adapt the device sample rate to the graph rate (DONE)
    • variable rate to implement clock slaving (DONE)

  • Latency

    • the plan is to do full latency compensation. This means letting ports report their latency ranges and then configuring a latency offset in each link. With some mmap tricks we can make the buffer memory like a ringbuffer and change the read offsets to implement latency.

  • Monitor ports

    • possibly just with ports on the DSP nodes. We can simply pass the mixed data from the input ports. (DONE)

  • Device ID

    • Generate and remember unique device ids. We will have to do with what we have because alsa (or the hardware in general) does not always give us a unique identifier. Probably keep a database of UUID mapped to device properties then do a best effort finding the device with the same properties. This might fail when multiple of the same devices come and go but we might tie the previous UUID to the port it was plugged in to make it somewhat deterministic.

  • Device reservation

    • with DBus to make sure we play nice when jack wants to run. The idea is that when JACK takes away one of our sinks/sources we replace them in PipeWire with jack clients. Apps would keep on running and we would still have our secure frontend to sandboxed apps and all the desktop policy integration. (DONE)

  • Per node async

    • Make it possible to run some nodes async to avoid them stalling the graph. Mostly for sandboxed clients that we don't trust.

  • Device topology/device management/UCM

    • expose simple API on devices to expose a graph of the internal device with options to modify some aspects. Should be flexible enough to handle complex cameras as well. Modifying the topology graph will create/remove device nodes on demand. Some hardware (on mobile) can provide multiple devices that are mixed in hardware and that can be configured with different latencies.
    • modifying the topology would also be a way to implicitly select a UCM profile
    • When running a source/sink as JACK client, we could use the topology API to control the internal jack graph.
    • jack sensing, notify manager of jack plug/unplug and let the session manager change profiles if needed. This is currently implemented by using the PulseAudio card config code.

  • Code quality, misc improvements

    • The graph handling can be simplified and optimized, move the activation client side to avoid context switch to server. (DONE)
    • unit tests for various bits (WIP)
    • Rework port buffer configuration. Output ports always allocate before the tee, Input ports use buffers on the port mixer. (DONE)
    • Port formats must be the same on the tee/mixer, we don't want to do conversion in mixer/tee (DONE)

Streams

  • Calculate amount of buffering in audioconvert to get more accurate timings on clients (DONE)
  • Peaks resampler for easy monitoring (DONE)
  • More profiles, Dolby PLII, for example
  • audioconvert optimization, mostly using passthrough when possible. (DONE)
  • think about running the async part outside of the real-time thread, resampling and conversion might be more expensive and might overflow our budget.

Session Manager

  • Implement reference session manager (WIP)
  • Implement nice event-based helper object to implement sessions (WIP)

Services daemon

  • Move old relevant PulseAudio modules here
    • Streaming RTP (using GStreamer?)
    • Tunnel
    • DBUS

Bluetooth

  • A2DP source (DONE)
  • HSP/HFP (WIP)
  • Possibly implement externally to keep encoders/decoders out of core (DONE)

Combine sink/source

  • Add a node that simply takes N inputs and passes them on to N outputs, basically making one nodes that feeds M DSP sinks/source. Mark this as a new combined sink/source for use in applications. With the automatic clock slaving in each DSP, this should just work.

Filters

  • Echo cancellation. Need to be careful to run the expensive code in a separate thread as to not stall the graph.
  • Equalizer. Perhaps some LADSPA or LV2 will do. LV2 might be problematic because it requires a shared hashtable for types that can be hard to implement in a real-time thread safe way over multiple processes...