Shortening buffer sizes, in almost any context–not just with AIR–will make dropouts more likely.
We provided the same set of buffer choices in Roon that Devialet provides in AIR for the sake of consistency, but I wouldn’t necessarily expect all sizes to be suitable for all networks. The very small sizes, in particular, seem very aggressive to me.
We default the buffer size to 2s over wifi and 500ms over ethernet. That is based on a balance between stability + responsiveness from our own testing on our own networks which are different from yours. If you prefer a different value, or your network requires a different value to be stable, feel free to change it.
Generally when we see NAK patterns like that, it’s a sign that something is getting overwhelmed or bottlenecked on the Expert side, and that caused the Expert to drop a lot of packets on the floor at once. “NAK” means that the Expert is requesting that Roon re-send packets that were lost. The more alarming thing is not the presence of NAK’s (these are normal), but the high counts associated with them.
Occasionally, there can be other causes for this–1000mbit to 100mbit transitions at network switches are notorious for dropping UDP packets (AIR uses UDP). Buggy switches and bad network cables (both of which are more common than you might think) can also be the culprit.
The “stats” trace has nothing to do with this–it prints every 15 seconds regardless, so it appears next to just about everything often. There is no meaningful resource usage involved in printing those stats, and they happen in a completely independent place from the AIR related code.
Finally, since you didn’t mention it, I have to bring it up 
– please make sure that your Expert firmware is completely updated.
(@support)