Exactly. Most audio/video protocols are based on UDP. More they are real-time, more they use fast protocols which cannot permit to make any check.
TCP/IP controls correctness of every packet and the order in which packets are received. Every x packets, an "OK" packets is sent back to the origin, stating trasmission is ok, delete old packets in buffers and to go on with new packets. Otherwise a "request" to retransmit is sent back is a packet is faulty or missing. All this is expensive and heavily compromizing for the quality requested to a simply phone call. This dialog is between the origin and the end point, crossing all intermediate routers/switches and any communication equipment.
UDP instead does not control any packet, does not control any flow. If a packet is missing or faulty, it's simply gone. It's better to skip it instead of requesting it again.
Every commercial transaction, every printer dialog, any USB disk uses the TCP/IP protocols.
The most of audio/video quality communications use UDP protocols.
Just to make it more clear, a packet coming from a whatever source (TIDAL, qobuz, etc) needs at least 25 ms in the best situation, and more than 100ms in a normal situation. So what you are playing is something sent to you a lot of milliseconds before. Using UDP, you receive a constant stream, with a very regular flow. Using TCP/IP you will freeze the sound every X packets, and also when ask to resend a packet. This latter situation is totally unnoticeable in a commercial transaction, but would be a disaster feeding a DAC. Of course you may use very large buffers, but starts to be a file transfer more than a streaming.