)]}'
{
  "commit": "c543098fe6e7fa4fac878293aacddcc45498e073",
  "tree": "5f7e73e5c79feaa7809aff6fb4dd92a9be4f8208",
  "parents": [
    "135caf7795300d8d6654b3ecaf15b8d144f6bf8b"
  ],
  "author": {
    "name": "John Grossman",
    "email": "johngro@fuchsia.infra.roller.google.com",
    "time": "Wed Aug 17 00:24:28 2022 +0000"
  },
  "committer": {
    "name": "Copybara-Service",
    "email": "copybara-worker@google.com",
    "time": "Tue Aug 16 17:26:20 2022 -0700"
  },
  "message": "[roll] Roll fuchsia [usb][audio] Fix a bookkeeping error.\n\nFix issues with the frame number accounting for isochronous audio\npackets in the current usb audio driver.\n\nFirst, this code was not quite correct.\n\n```\nusb_frame_num_ \u003d std::max(\n    usb_frame_num_++,\n    usb_get_current_frame(\u0026parent_.usb_proto()));\nreq-\u003eheader.frame \u003d usb_frame_num_;\n```\n\nIt is attempting to compute the next frame number to apply to a\npacket, but it does not want to fall behind what the USB host\ncontroller reports as the next schedule-able frame number number.  So,\nit is trying to assign `usb_frame_num_` to either the next number in\nthe sequence, or the next schedule-able frame number, whichever is\nlarger.\n\nUnfortunately, it is using the postfix ++ operator.  This is going to\nreturn the pre-incremented value of usb_frame_num_, not the next\nnumber in the sequence.  As a result, it will fail to increment the\nframe numbers at all, until the safe index reported by the host\ncontroller has caught up to the value of usb_frame_num_.  Thereafter,\nthe variable will simply track the value being reported by the host\ncontroller driver.\n\nSo at startup, if the safe-start-index reported by the controller\ndriver is X, we will end up sending our starting packets each with a\nFrame ID of X (presuming that the HW does not advance the frame index\nduring the initial burst).\n\nIf the controller supports the \"Contiguous Frame ID Capability\" (this\nis mandatory for XHCI 1.1 and beyond), this seems like it should cause\nthe controller to skip the second and subsequent packets (declaring\n\"Missed Service Errors\" for each) until we  catch up to a point in the\nstream where the packets are finally tracking the frame index\nregister, and at that point in time, we should be right on the edge of\nunderflow.\n\nOTOH - If CFC is not supported, then this startup issue should work\nout.  If we start to fall behind, however, and end up skipping packets\nin the stream because of this check, that will end up getting us out\nof sync with where we are copying data from the ring buffer being\npopulated by the mixer which can cause its own problems.\n\nFor now, simply fix the increment operation, and do not attempt to\nfloor the value with the safe index reported by the controller.  If we\nstart to fall behind, we will either totally underflow (and will need to\nrestart the stream entirely), or the packets will end up getting\nskipped, but the stream should retain the proper position relative to\nthe ring buffer (assuming CFC \u003d\u003d 1)\n\nOriginal-Bug: 102058\nOriginal-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/707866\nOriginal-Revision: 396a98365c629c221cf1f3fbc2f022f096933ea4\nGitOrigin-RevId: e6f3d78130737b99c9502c7d7f315d19464be5f2\nChange-Id: Ie220809552f27b58cb680a9b327797c1331498fe\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "a9893ad030aa0b4c9fa6c67ccb912237a5b3bcc8",
      "old_mode": 33188,
      "old_path": "stem",
      "new_id": "d8de823bdaa374a51e866d243edc0d3cbe037e66",
      "new_mode": 33188,
      "new_path": "stem"
    }
  ]
}