Ticket #8 (closed enhancement: fixed)

Opened 17 years ago

Last modified 16 years ago

persistent storage of devices

Reported by: ppalmers Assigned to: wagi
Priority: major Milestone: FFADO 2.0
Component: Version:
Keywords: Cc:
The device the bug applies to:

Description

Add a persistent storage to keep track of the devices know in the system. This should also allow for a faster discovery.

Proposed discovery sequence

  1. Read configrom from the node
    • get GUID from configrom
  2. Detect node type
    • find and create correct AvDevice? (= probe())
  3. Detect node configuration
    • request some sort of ID from the device that is unique for every possible configuration of the device. e.g. 1 => 44.1k, 2 => 48k, ... . I propose a 32 bit integer, and the exact meaning/ calculation is up to the AvDevice? implementation. This restricts the necessary operations in the AvDevice? to the minimal set necessary to identify a unique configuration.
  4. Check if the GUID + config ID combination is present in the persistent storage
    1. if it is not:
      • do device discovery as usual
      • request config ID from AvDevice?
      • serialize the AvDevice? and save it under the GUID + config ID combination
      • proceed as before
    2. if it is:
      • deserialize the config under the GUID + config ID combination into the AvDevice?
      • proceed as before

Change History

06/04/07 14:16:56 changed by wagi

  • owner set to wagi.
  • status changed from new to assigned.
  • device_name changed.

Point 3:

Unfortunately, using just the sampling rate as identifier isn't enough. The problem is that depending on the sync source/mode the number of channels can change, e.g. SPDIF enabled/disabled. I'm still not sure how to solve this problem. Maybe one possible solution is to load a cached model and test for changes in the model. This should be still faster than a complete rebuild of the model.

11/25/07 13:10:05 changed by wagi

  • status changed from assigned to closed.
  • resolution set to fixed.