Richard, Thanks so much for replying.
I think I got it into the state where the 6.3.1 server thought the 2.8 client was a previous generation of client. I did not upgrade Server and Client in an orderly sequence. I think I tried to install and run the 1.12 Softsqueeze client under 6.3.1, and when no sound came out, I went to 2.8, and back to 1.12 a couple times, and then to 2.3 that finally worked. But by then something inside some config file or database somewhere thought we were running both an old and new Softsqueeze client. You may have an easier time approaching the bug by bench checking the code with the question: "Why would a server send 2.3 images to a 2.8 client?" What should probably happen is the FAQ should get an update to tell people, "If you get this font doubling, here is how you un-confuse the server." It occurrs to me that this bug would not have happened if there were comprehensive uninstaller that wipes out all the old state so that in the unlikely need to go to a previous version of client or server, it could be done cleanly. Forgive my not doing the additional work to identify what wrong update order definitively creates the problem. Tell you what-- If you do the uninstaller that will well and truly clean EVERYTHING out, I'll try and find the minimal sequence of wrong moves to confuse the server and give you and exact "repeat-by". ---- I think I found the MacOS caveat you refer to: http://softsqueeze.sourceforge.net/sync.html But I don't interpret: > On OSX you may get a small delay in playback. The latest version of Java released by Apple is Java 1.4.2. This version of Java has a small audio latency. Tiger is meant to include Java 5.0 for OSX , but I do not yet know if the javasound implementation had been improved. as you more strongly state in your reply: > Also sync will never work correctly on OSX due to a bug/feature in Apple's Java implementation[.] I'm not experiencing a constant and consistent delay between the hardware and the software playback. Instead I get: With 5.4.0/1.12 sync within one second. With 6.2.3/2.8 sync variable with one or the other leading or lagging by as much as FIVE WHOLE seconds. Having done a bit of protocol work myself it seems odd to me that the SlimServer time sync protocol fails to be able to measure latency. Two round-trip protocol transactions would be needed: "Tell me your fine grained clock time," to understand the offset between the server clock and the client clock. "Tell me when this specially marked block of sound actually comes OUT of the buffers and goes to the audio," to understand the system latency. If the protocol had these two transactions, many kinds of software and hardware solutions could co-exist. (Naturally you'd need to remember to be clever and add HALF the delta when you get big offsets from the previously measured latency so you don't oscilate, but that too is well understood in doing signal tracking.) If the ability to measure latency is limited, you add a per-device manual offset. Unfortunately, I think there's something else going on with my setup. Something that should minimize latency is instead maximixing it over time. ---- Ok. I'm going to tell you what hardware I'm using. I expect that as soon as I do, you'll not want to talk to me any more, because indeed I'm using an unsupported configuration. As a senior analyst programmer and software development project manager of long tenure, I appreciate that you have to focus on the subset of what you can control, and try not to be distracted by unsupported configurations. That said, I believe that there is STILL value to spending some time understanding and perhaps working through failures in unsupported configurations. Ok, here goes. I hope you'll still talk to me. I'm using Roku's sketchy SlimServer emulation on their SoundBridge hardware. What can I say? I picked the wrong hardware vendor. If you can bring yourself to keep talking to me, I'd like to understand these two questions: 1. What must SlimServer do to make its open protocol actually allow vendors beyond SlimDevices to have reliable sync? 2. What must Roku do to comply with that protocol? If we end our discussion at "That's not supported, good bye," then we've taken the easy way out, and given in to the situation where only the one proprietary vendor knows the secrets to kludge a function together well enough to pretend it is real. Sync can be real, and open if we share our experience and work together. Bottom line: Why does ancient 5.4.0/1.1.2 sync better with sketchy Roku than wonderful new 6.3.1/2.8? At the moment I'm 64 songs into a random mix. (I've been running this mix for a few hours, starting it after the server said it was done scanning my music cllection.) The SoundBridge played everything 5 seconds sooner than the Softsqueeze. At the end of song 64, after a 30 second pause the SoundBridge began playing song 65 two seconds sooner than the SoftSqueeze. With the old server and client, it NEVER got this far out of sync. -- wcattey ------------------------------------------------------------------------ wcattey's Profile: http://forums.slimdevices.com/member.php?userid=7506 View this thread: http://forums.slimdevices.com/showthread.php?t=24413 _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/beta
