1. Timelines / Milestones ?
    1. Halibut: (~June 8th)
      1. sessionmanager with udev detection
      2. appfw/security portal  w/ smack / named sockets
      3. volume controls
      4. input w/o buffer
      5. ? bluetooth ?
      6. config api evolution in parallel
    2. Icefish:  (~Nov 22nd)
      1. sessionmanager with config IF and unicens support
      2. bluetooth
      3. policy plugin
      4. input path for voice w/ buffer available
      5. device↔device link (KF radio)
  2. What needs to be ported, who and when ?
  3. Discussion on Architecture and Requirements

Notes during the meeting:


  • Topics to discuss:
    • Architecture discussion
      • specialized HW
      • special controls
      • Sound from remote devices
        • tcp/ip
        • can connect


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


Summary #1:

  • 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.


Issues:

  • 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:

  • API's
  • configuration
  • gateway&security
  • pipewire specific issues
  • bluetooth
  • device↔device streams  (e.g. KF radio)
  • capture, capture mixing, wakeword processing,












  • No labels