[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pygame] Timing...

It sounds like what you really need is direct access to the sound buffer, so when you want to add sounds you throw it on the queue and you don't have to worry a whole lot about it.

I don't think you're gonna get this with the current release of SDL/pygame.  You ought to consider finding yourself a.. more mature cross-platform sound library (or not cross-platform perhaps).  You could just do it in raw mm or directsound, it probably wouldn't take a whole lot of hacking with win32all and Numeric to come up with a with a way to do it like that..  you might not even need to write any extensions, but I don't have enough experience with python's dll/com support to say definitively either way.


On Fri, Jul 27, 2001 at 01:57:14PM -0700, Michael Robin wrote:
> -----Original Message-----
> > Unless I'm missing something, I don't know why threading would help.
> > In this case, things will be even worse than calling per frame, because
> > you're spinning
> > 100% of whatever the CPU can muster for this thread, virtually grinding
> the
> > game to a halt.
> - No.. that is not how threads work. The CPU will divide it's power to your
> Well, I do know how threads work :)
> (Blame me and friends for writing the win3.1 multimedia apis - though
> unfortunatly
> I didn't get to design most of them...)
> - sound thread and the main thread (if your thread loop is working with a
> small
> - delay of say 20ms or so you will hardly notice speed changes in your main
> thread)
> Yup, I agree, that's why I mentioned using a sleep w/your threads in my
> reply.
> > Adding a time.sleep(ms_wait) would be an option to give the game some
> > ticks - but in any case you
> > still need to wait for get_busy to return false, at which time it's too
> late
> > for a sample to appear again in time. (Even a done event would suffer the
> > same problem,
> > but at least take no CPU during the play.)
> -It would be perfect if you'd know the time of your samples.. but I guess
> w/o
> -knowing that you will either have to check for it ending all of the time
> -(thus taking up all processing power) or accept a small delay. If you could
> -find out the time for your sample tho you could start the next one after an
> -appropriate delay
> When I said "sample" I meant literally one sample point, i.e., one ADC
> value.
> I think you're use is a wave segment. My mistake for not being more clear.
> > I suppose I'm too picky comming from a speech background - if you're
> > just doing sound f/x or you're willing to have the thing sound like most
> > telephony IVR
> > systems, these schemes should be okay if you have enough CPU to spare.
> -I'm not familiar with speech in pygame (nor in any other app actually)..
> but
> -I also wouldn't ever want to time my sounds in a ms range.. Usually it is
> -more than enough to play one sound after the other with a small delay.. but
> -if you can't work w/ that restriction I gotta admit I won't be a lot of
> help
> -to you.
> That's the thing - I'm not trying to time the sounds at all - I just
> want it to come out all in one piece...
> > Why don't you simply use threading for this?
> > Some more risky brain code (building on pete's code):
> -Please avoid using that code from my last mail.. it was totally pointless
> -as it missed the loop in def update. Of course you will have to keep the
> -thread alive by looping the get_busy call.
> No prob - You're braver than me - I don't even try posting code off the cuff
> (unless it's really late :) )
> I'll probably do soemthing like this anyway, unless it turns out to be a
> problem.
> thanks,
> m
pygame mailing list