No they won’t.
Many years ago I designed a printer buffer… Conceptually it’s a circular buffer…
A simple little computer that reads data in from a serial port, stuffs it into memory on one end and spools it out to a much slower printer on the other end. Typically this would receive 19,200 baud data hold about 2 megabytes and spool it out to a 4800 baud printer. You know the buffer is full when the “next in” pointer is one less than the “current position” pointer… you know it’s empty when the “current position” pointer is one less than the “next in” pointer. Round and round until it’s all printed (or played).
(It was a bit more complex than that, having multiple inputs… but that is how the buffering worked)
So, lets assume this sequence…
USB DATA —> USB RECEIVER —> MEMORY BUFFER —> DAC —> AUDIO OUT—>
You would have to receive that data at USB speeds until the memory buffer starts filling… say 100 bytes or so. Now your software releases the DAC to begin sampling at it’s set sample rate. You have music right out of the gate, no delays. Now since the buffer is going to fill faster than it empties you need to keep track of where the new data is going with a memory pointer (NI) and watch that NI never overruns the DAC’s position (CP) when the buffer is full. Once the buffer memory is full you stop the incoming data and let the DAC run around the buffer until it comes up behind the NI by some value and restart the data transfer. Round and round.
Circular buffers are easy enough to program… CP = (CP & BufSize) + 1; … it will run around in circles inside the defined buffer size moving one position on each call.
With proper logic the actual clock speeds are unimportant … just so you are preventing collisions such as overwriting data that isn’t played yet or running out of stuff to play.
This BTW is how DirectX and other streaming software actually dispenses the decoded PCM data from memory to USB.