Re: Loop notification
Re: Loop notification
- Subject: Re: Loop notification
- From: "Andreas Falkenhahn" <email@hidden>
- Date: Tue, 16 Oct 2007 22:18:45 +0200
On 16.10.2007 at 12:23 Mark Pauley wrote:
>Whoops, I see what you're saying... My suggestion only solves the low-
>overhead pinging of the main-thread.
>
>You would also need to determine how many packets into the current
>pull you are on the MP3 side. What happens if you just return a short
>packet-count and set a flag when your feeder hits the end? Then you
>can check for the flag when the converter returns a short count and
>signal the source on the main runloop at that point, right? You may
>even be able to reset the feeder and pull the remaining number of
>packets to satisfy the render request at that point.
>Otherwise you would then reset the feeder's state and go back to
>pulling as normal until you hit the end in the feeder again.
Well, I thought about something like this, too, but I'm not sure if it
could lead to a short glitch in the sound output under bad
circumstances.
Let's imagine the following situation: The feeder thread determines
that there is only ONE packet of the current cycle left to render before
doing the loop. With uncompressed audio like WAV PCM data it could
even be only one *frame* of audio data that's left to render before the loop.
So in this worst case scenario my ACComplexFillBuffer() would return
with a buffer of 8 bytes (16 bit PCM stereo) that contains one frame of
PCM audio data and takes 1/44100 of a second to play. So CoreAudio
would have to call the render proc *immediately* again to get new data
to render but that time is probably not enough to get new data because
the previous render operation took only 1/44100 of a second to play.
That's why I think this suggestion does probably not work and could
lead to glitches in play back, but I didn't put it to the test. It just seems
likely to me that the audio will glitch...
Andreas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden