- What are out critical outcomes ?
- What are the most critical areas to document ?
- Discussion on Architecture and Requirements
- Timelines / Milestones ?
- sessionmanager with udev detection
- appfw/security portal
- smack / named sockets
- input path for voice
- ? bluetooth ?
- sessionmanager with config IF and unicens support
- policy plugin
- What needs to be ported, who and when ?
Notes during the meeting:
- Topics to discuss:
- Architecture discussion
- specialized HW
- special controls
- Sound from remote devices
- can connect
- Architecture discussion
Architecture Diagram to start with:https://confluence.automotivelinux.org/pages/resumedraft.action?draftId=9404429&draftShareId=03363209-aee5-4d35-9e96-cd70b5b1ffea&#
session manager able to configure dsp?
one client per each ALSA device in case of hardware mixing
open/ proprietary networkmanager separate!
external (zephyr/autosar) devices reserve/create ressource
Gateway/Portal handling ressource/ACL management. Returning ressource URI (socket or network endpoint) ?
George: original idea is to create and configure the pipewire socket; more discussion needed
Potentially desired mechanism for content protection:
1) client connects using (no / invalid) token
2) service reacts with refusal and ID/Link to authority
3) client connects to authority
4) authority grants token
5) client connects to service w/ new token
6) service checks token with authority
7) authority verifies token
8) access granted
→ similar / equal to oauth/openID mechanism
- In a car we have (proprietary) network managers. The pipewire session manager needs to communicate with these and provide an API.
- Similar for copy protection mechanisms.
- Thus session manager cannot (shouldn't try) to abstract all of these.
- System management might be on external hardware
- Security provided by a gateway/portal that handles ressource managment and authoriztion.
- Need to take HDCP/content protection in mind (e.g. widevine)
TODO: Session Manager first.
- static and/or default config vs dynamic configuration at runtime
- handle device removal
- graph inplemented in HW level
- kernel-based security
- content protection
- role of the gateway
- external authority ?
nodes appearing inside pipewire, representing the devices and the clients
client connected to alsa device through DSP and using a filter plugin in the middle
gateway in session manager ?
hardware device graph, somewhere else in the car
wireplumber internal design
Talking points for WED:
- pipewire specific issues
- device↔device streams (e.g. KF radio)
- capture, capture mixing, wakeword processing,