Many thanks Alex. I'll check out PyAudio (seems to be a fairly thin wrapper to the PortAudio) and stick with pyglet for visuals (great job by the way).
Incidentally, the reason the lock code is in there for the thread is that I was wondering whether the error was caused by a re-entry into the thread (ie. it was an unsuccessful punt!). For a test case to generate the error, just set the polling period to something very small - 0.00001 gives the error almost every run on my machine. thanks again, Jon On Nov 18, 12:24 pm, "Alex Holkner" <[EMAIL PROTECTED]> wrote: > On Tue, Nov 18, 2008 at 9:47 PM, Jon Peirce <[EMAIL PROTECTED]> wrote: > > Hi all, > > > Not sure if this is related to the timing issues that Alex is already > > looking into. I'm having trouble with sounds on pyglet, particularly with > > trying to run a thread that automatically dispatches events for > > ManagedSoundPlayers. I need to do this rather than simply dispatching events > > in my frame draw loop, because the users of my software sometimes need > > sounds to play without page flipping and sometimes use very brief sounds or > > want very precise onset times (which would seem to need a more frequent > > event dispatch than once per 12ms frame). > > > The following works fine under OS X and python 2.5 (given a different media > > location, obviously) but, under XP python 2.5 (pyglet 1.1.1 or 1.1.2 or svn) > > the sounds are unpredictably broken - sometimes they miss the beginning, > > sometimes the end and sometimes result in an error message (pasted below the > > code). At the polling rate below (every 1ms) the error occurs rarely (once > > every 10 runs or so). If I reduce the polling time further to 0.0001, the > > error message becomes consistent. > > > Can anyone see a problem with my threading code? And/or can anyone explain > > the callproc error message? Could it be related to the timing issues on win > > XP? > > That directsound error should have been fixed in trunk; please send me > a test case if not. > > Regarding your use of threads: I don't quite see the point in the > lock, as only one thread is ever spawned that uses it. The > `dispatch_events` method was deprecated in pyglet 1.1; Player objects > use the clock to refill the audio buffers (which requires you to > either tick the clock or run the event loop). The module-level > dispatch_events only handles ManagedPlayer instances, not the Player > objects you are creating in this example. > > Regarding increased precision: I strongly advise against using > threads; try to construct a run loop that instead calls > dispatch_events on each player directly without sleeping; and use > coroutines (yield) in place of threads and mutexes. Note that this > approach won't work in pyglet 1.2 due its own use of threads (which > won't give you the precision you need either -- I'd consider looking > at alternative libraries at this point, as pyglet doesn't seem to be > what you want). > > Cheers > Alex. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
