Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 29 Next »


  1. What are out critical outcomes ?
  2. What are the most critical areas to document ?
  3. Discussion on Architecture and Requirements
  4. Timelines / Milestones ?
  5. 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
        • tcp/ip
        • can connect


Architecture Diagram to start with:


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