Hello All

I installed tRio today. I am running WinXP on a Via mini-ITX board with an 800 MHz processor and 256 Mb of RAM in my music server. It's hooked to a Linksys BEFW11S4 wireless router. My bedroom receiver is hard wired and my living room receiver is linked with a Linksys WET 11. I was using the Rio audio manager v1.4 software and both receivers performed flawlessly through the firewall and with 64 bit WEP enabled.

Today, after setting up and running tRio, I experienced drop-outs in the audio stream in the bedroom and almost no playability in the living room. The problem was even more pronounced when I synchronized the players. They would both start out fine together and within 5 minutes the living room player would stop playing followed soon after by the bedroom player.

I am using static IPs for all of my networked equipment. I disabled DHCP in both the router and my music server. I have all of the latest drivers and software versions installed in my equipment. I tried using the living room player with the firewall software disabled and with WEP disabled, no change. I followed Paul's installation instructions to the letter...

Any ideas?

BTW, I think that tRio is a fantastic client and I really appreciate the work Paul and his partners put into it, I look forward to using it full time in the future once I can get the wireless issues worked out...

Any ideas?

No, but it's interesting that it works for you with Rio Audio Manager. I've got almost exactly the same setup -- BEFW11S4 and WET11, only with Empeg's (unreleased) unix receiver server daemon based on the Rio Central code -- and I get dropouts in songs encoded at more than about 200kbits/s. I haven't figured out what's going on yet -- there should be plenty enough bandwidth. I'll try it with Rio Audio Manager, and then I'll try it with a packet sniffer...

Peter

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

The disadvantage is that UDP does not guarantee delivery.

Which is why all well-written software which uses UDP implements its own packet loss compensation techniques...

its own packet loss compensation techniques

...which might include not doing anything about the lost packets, if they really weren't that important.

To the best of my knowledge, its not the norm to attempt to resend missed packets in a multicast setup.

Because the Receivers are supposed to be hi-fidelity stuff, I thought I'd implement a redimentary "second bite at the apple approach" in tRio. And so if a packet is missed, space is left for it in the buffers, a resend request is sent and if it doesn't arrive in time for the decoder then that's just tough luck.

Normally this works fairly well, but if too many packets are lost, then things come off the rails.

Hey Guys

Thanks for your responses. I have tried changing the broadcast methods but it still hasn't changed anything. I feel that it is dropped packets to the wireless bridge that is the problem as Paul suggests. Funny thing is that my hard wired bedroom receiver will play fine for about an hour and then it slowly starts skipping as well (playing by itself, living room box shut off). I guess it will give me something to work on in the coming weeks, I am really anxious to get my boxes synchronized so I can fill the whole house with tunes.

I have a similar setup, except my Rio is wired, not wireless. I have the exact same behavior and can just about trace it to the Linksys locking up. I'm even watching it reset every 2 minutes via SNMP while tRio plays. Terrible. (btw, I see the same behavior when I move large files across the Linksys).

If I take the Linksys out of the equation and run everything of another switch (a Baystack), everything is fine. tRio works flawlessly. Even if all components are connected to the Baystack, the Linksys still locks up, even though there are no ports in use on it besides upstream.

The only problem is the Linksys is my firewall, I'm not quite ready to cut the tether to the outside world yet. The weird thing is that the regular rio client works okay with the Linksys. My only guess would be the amount of traffic going back and forth between the Receiver and tRio server (client unrelated to mp3s, ie. display updating, menuing, etc.) causing the Linksys to lockup. I'll have to double check and see how much traffic (kbps) goes between the tRio client/server.