At Wed, 10 Dec 2014 12:43:38 -0600, Pierre-Louis Bossart wrote:
- int trigger_tstamp_pending_update; /* trigger timestamp being updated from initial estimate */
This isn't used at all in this patch. I found it being used in the later usb-audio patch. If it's the only place, can't it be rather put locally to usb-audio object instead of the common pcm runtime?
It's not limited to USB. We have upcoming hardware where the trigger_tstamp will only be determined with a delay due to IPC. USB is just an example of a common pattern where the trigger_tstamp will be known for sure after a couple of ms.
Well, the question is whether this *must* be put in the common place. In other words, will this field be referred in the common PCM code? If not, it should be recorded rather locally.
well i wasn't sure of what to do here:
- we can leave the low-lever driver update the trigger_tstamp on its
own, and then this field is not needed at the core level, but the core or the application will not be notified that an update is pending 2. or we use this field to let the core know, and possibly let userspace know that the trigger will be updated shortly. However, I didn't find an existing mechanism to notify userspace that the new trigger_tstamp is dirty and has changed so the use of this field is indeed incomplete for now.
We're extending the status struct in anyway, so can we put a (bit) flag somewhere indicating the behavior?
Takashi