In investigating this bug, we have discovered that the player seems to think that the length of the second and third sources queued up is the length of the first source. At the last moment. It only makes the adjustment for this at the last moment though. Our first track was 16 seconds and the second and third are 14.22222. Logging the player.time every .1 secs looks something like this near the transitions:
[snip] 12.8282993197 12.9502040816 13.0155102041 13.137414966 13.2019954649 13.3253514739 13.4516099773 13.5125623583 13.6388208617 13.7629024943 13.8282086168 13.953015873 15.7939229025 15.916553288 0.039909297052 0.103038548753 0.229297052154 0.290975056689 0.416507936508 [snip] On Sun, Nov 8, 2009 at 9:45 PM, ClayRab <[email protected]> wrote: > > Hello everyone, > I seem to be having a problem where the 'time' reported from my Player > jumps ahead about a second and a half just before it transitions to > the next source in the queue. The source is being queue'd up well in > advance. I have tried both static and streaming sources but with no > luck. Since my game depends heavily on synchronizing with my sound, > this is a deal breaker for me. If anyone has insight into what might > be causing this or if anyone can give me some advice I would be very > grateful. > Thanks! > -Clayton Rabenda > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
