I'm not sure what you mean in this context by "non-reference". Doesn't it depend on the design of the client? Are you saying that, inherently, all dlna solutions are always inferior to USB?
Well, yes and no.
First, DLNA is just a set of some guidelines, sets of protocols to use for certain operations, a single name for which a device can be "certified", a nice label on a device. These are AFAIK not freely available and can evolve over time, changing some protocols for other ones.
Last time I measured a device, it used RTSP messages with RTP/RTCP for the actual stream itself. The
RTP RFC mentions sender reports (SR) and receiver reports (RR), but those don't seem to provide any way to control the replay rate on the server. In fact, the "Congestion Control" section mentions the "inelasticity" more closely.
To be honest, I don't know whether there's an implementation that utilizes the RR messages to throttle the server down (or speed it up), maybe such implementation extends the field definitions as per section 6.4.3, maybe the extension is specified somewhere in the DLNA guidelines, or maybe not.
This only highlights the issue at hand - streaming protocols with so much abstraction and related control channels (think RTSP) are simply too much disconnected from what the source is and often presume it's an existing stream of a given rate, which cannot be slowed down or sped up (although there's a RTSP message type for that, but it's meant for user control, ie. 2x speed for funny voices).
Also, due to its network nature and also due to the fact that DLNA presumes any related media to be streamed through the same path (ie. video alongside audio), there is going to be decent buffering, at least few tens of milliseconds, likely more given bigger RTT (I believe RTSP/RTP has a detection for that). Not counting overhead of underlying protocols (ie. ARP cache invalidation events on L2).
In the end, all of this is huge, HUGE overhead over what USB does so efficiently and natively. Given its very fast device response times, the buffer can be much smaller, which allows you to ie. watch a youtube video on the screen and play the music/sounds via the "sound card" with nearly perfect "lip sync". (It also has its advantages when recording / tracking.)
So is DLNA inferior to USB? That really depends on the use case. From the point of view of a "typical" hifi user, who presses the play button and goes away to sit in a comfortable armchair, probably not so much. The other use cases really depend on whether DLNA somehow implements the USB-like "feedback" channel - if not, it's basically equivalent to Adaptive USB. My bet goes this way - if I've learned anything from cheap chinese SoCs, it's that they always go for the least effort solution. (Looking at you, Broadcom, how dare you not support TLS1.0!).
Jiri