Hmmm, my immediate guess is that audio data is being "lost in transit".

The original software sends audio data over TCP which is "reliable". tRio on the other hand uses "unreliable" UDP to either multicast or broadcast the data (depending on the send-method setting in trio.xml). This allows it to send the data only once (to all the players) rather than send it to each player (over TCP) in turn - thus saving bandwidth.

The disadvantage is that UPD does not guarantee delivery. On a normal "hard-wired" network, the odd chunk of audio data does go missing from time to time. When this happens the players will ask for it to be resent, but if doesn't arrive in time you will experience skipping and playback might stop altogether.

My guess is that many more chunks are being lost on your wireless setup and the resend mechanism is not coping. You can confirm this by looking for resend requests on a network trace. The data part of these packets start with a
4 byte length field followed by hex 16 (decimal 22).


A few things to try:

1. Try changing the send-method to "broadcast" in trio.xml. Make sure that the broadcast-address is right for your network when doing this (the 1st 3 parts of your Rio's address plus ".255").

2. Try changing the send-method to "unicast" in trio.xml. This will knacker sync'd playback, I'm curious to see if you still get skipping in non-sync'd playback.

3. See if there is a firmware update for your router which covers this. BUT ONLY IF YOU KNOW WHAT YOU ARE DOING AND DO SO AT YOUR OWN RISK.

If all this fails, I'll have to have a look at implementing a new send-method="tcp". Right now I'm very busy on getting v0.1.3 ready though, so it won't be tomorrow - sorry.

Cheers
Paul