tRio and Audio Skipping

I'm using the latest and greatest version of tRio and have enjoyed it tremendously (now with four Rio's hooked up to it!) However, I'm still having some skipping issues. I'm using the HPNA interface and have tried all three different types of TCPIP transmission (broadcast, multicast and unicast) to try and keep the music from skipping.

In this particular file, it's a CBR file, 256 kb/s and it always skips at 46 seconds into the song. Then every 9 seconds after that. When switching back to the "out of the box" solution the songs play fine...

Paul - is this something related to the HPNA overhead talked about very early in your releases? I have really clean phone lines and have had no trouble streaming in sync to all four of my receivers on lower bitrate files (most of mine are encoded VBR). Is there anything else to try to get rid of these skips? Any sort of logging I can turn on to see some errors?

Are there other people running HPNA and running into skipping on high bandwidth files?

Thanks!
_dave

Dave,

This is the 1st I've heard of skipping with a CBR file. But yes, hpna does seem to put more of a load on the processor.

What's probably happening is that the music is being played at faster rate then what it's being decoded. When you press play, tRio waits until it has decoded a good chunk of audio before starting playback. By the sounds of it this buffer is slowing emptying until after 45 seconds the skipping starts.

To confirm this, rename your receiver to "[test]" (via the web front-end or by editing trio.xml). This will produce messages like this in trio console:

ProcessStatus. tune_seq=2 tune_id=930 status=2 sync=0 encoded_buffer=21 decoded_buffer=100 tune_decoded_start=0 curr_decoded_pos=28286176

Take a look at what's happening to the "decode_buffer" value. In the above example it's 100% full - if it reduces to 0 you'll get skipping (not immediately because the audio driver also has a 0.8 second buffer).

I don't know if it'll help, but try setting the "send-method" to "broadcast" and "unicast" and see if it improves things.

Cheers
Paul

Paul,

You were correct...

PlayerStream (/192.168.2.129) - sent Play()
ProcessStatus. tune_seq=7 tune_id=d750 status=1 sync=0 encoded_buffer=36 decode
d_buffer=28 tune_decoded_start=0 curr_decoded_pos=1152
ProcessStatus. tune_seq=7 tune_id=d750 status=2 sync=0 encoded_buffer=36 decode
d_buffer=28 tune_decoded_start=0 curr_decoded_pos=144
ProcessStatus. tune_seq=7 tune_id=d750 status=2 sync=0 encoded_buffer=36 decode
d_buffer=25 tune_decoded_start=0 curr_decoded_pos=882400
ProcessStatus. tune_seq=7 tune_id=d750 status=2 sync=0 encoded_buffer=27 decode
d_buffer=21 tune_decoded_start=0 curr_decoded_pos=1764656
ProcessStatus. tune_seq=7 tune_id=d750 status=2 sync=0 encoded_buffer=36 decode
d_buffer=15 tune_decoded_start=0 curr_decoded_pos=2646832
ProcessStatus. tune_seq=7 tune_id=d750 status=2 sync=0 encoded_buffer=36 decode
d_buffer=9 tune_decoded_start=0 curr_decoded_pos=3528880
ProcessStatus. tune_seq=7 tune_id=d750 status=2 sync=0 encoded_buffer=36 decode
d_buffer=0 tune_decoded_start=0 curr_decoded_pos=4411152
ProcessStatus. tune_seq=7 tune_id=d750 status=2 sync=0 encoded_buffer=36 decode
d_buffer=0 tune_decoded_start=0 curr_decoded_pos=5293200

I'll have to mess around with the different protocals some more...

Thanks for the testing information...

_dave