[roll] Roll fuchsia [usb][audio] Increase packet queue depth from 3 -> 6

USB Isochronous transfers have to be made available to the controller
a minimum distance ahead of the USB frame in order for the HW to be
able to pick up the data in time.  This value is encoded in the IST
field of the HCSPARAMS2 register in the XHCI controller, and can range
anywhere between 0 and 7 frames (eg; milliseconds).

This value is not currently being made available to USB device
drivers, making it functionally impossible to plan their buffering
requirements for maintaining an isochronous stream.  This needs to be
addressed, but not right now.  This is just a short term mitigation;
the expectation is that as the USB bus driver API evolves, this
functionality will be added.

At any rate; the advice given in section 4.11.2.5 is that isochronous
transfers be in place no less than 1 + IST frames ahead of the frame
clock.  On Atlas, the IST requirement is 4 microframes, so the
suggested lead time requirement (for this specific HW) is 1.5 mSec.

The USB HW scheduler can schedule an isochronous transfer anywhere in
the frame's time slot.  This means that it might be up to 1 mSec after
the frame starts before the job is done and the USB controller
interrupt fires.  Right now, the USB audio driver queues new packets
in response to old ones coming back because of the completion
interrupt firing.

So, when we queue 3 packets at startup, we are 3 mSec ahead
of the presentation schedule.  _But_, we have a 1.5 mSec lead time
requirement, and depending on when the completion interrupt fires, it
end up being an extra mSec behind on queueing the next packet (even if
scheduling is perfect and zero overhead).  So, in the worst case, we
might be only 500uSec ahead of the suggested lead time, and only 1.5
mSec ahead of the hard requirement of the Atlas hardware.

Adding 3 payloads to the queue increases minimum audio latency by 3
mSec, but it also shifts these requirements from [0.5, 1.5] mSec out to
[3.5, 4.5] mSec, which hopefully will be more stable overall.

Note:  This is _not_ the best way to be doing this.  There are not a
lot of good reasons right now why the USB audio driver should need
such strict timing.  If the USB bus driver supported direct DMA, where
a VMO could be shared with the driver and pre-pinned by the
controller (so the system was zero-copy), it would be possible for the
USB audio driver to queue the ring-buffer schedule literally seconds
in advance; waking up only to top off this schedule perhaps once every
500mSec with no significant real-time requirements.

Original-Bug: 102058
Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/708522
Original-Revision: 8c7a36ef3c5c74974c4cdf848423bca8316220c4
GitOrigin-RevId: adf653021b58cddd987e33d1681f277ed10ba9d1
Change-Id: I7fbced3b95085cf958839b12ef45c895541a7bfa