I would use UDP since it has lower latency. When a packet is lost, UDP carries on with the next packet instead of waiting for the previous packet to be sent. UDP will also reorder packets, since it is just sending blocks of data, not a stream like TCP. You would need to track the packets as you will have to manually sort the order of the incoming data. Normally you establish an acceptable latency, reordering the packets as they come in (as long as they arrive before your artificial latency) and reject those that are older than your established latency. This packet loss/drop will cause gaps in your audio, but you can mitigate it somewhat by sending redundant audio data in each packet. By detecting and tracking packet loss you can establish a 'quality of service' of the connection and reduce/increase the amount of duplicated data sent per packet.
UDP's lower latency with some drop out is preferable, IMHO, as it lets players have closer-to-realtime conversations.
Alternatively, you could consider slowing down your entire game so the voice matches in game events, but that's not going to make round-trip conversations work very well.
As for how you track packet ordering, I think that's a different question, but basically you need to establish some amount of 'acceptable' latency - say 100ms. You buffer up in-coming packets, putting them back in order as they arrive. Once you have 100ms or more of data you start pulling the data off the front, consuming the now in-order packets. Of course there will likely be dropped packets so you would want to either use the redundant data or incorporate an resend system using ACK/NAK, which sounds like re-inventing TCP but the results are more light weight - for example if the 100ms buffer has been consumed, there's no point requesting data that has already been 'played through'. It's the back bone of most reliable-over-UDP protocols used in most realtime networked games for the past couple of decades.