It's a attached. It's one second of A220 mono at 44100hz. <br><br>Also attached is the source for an example that will show the problem. I had to run it on my iPhone so its a .mm. Also, you'll have to add A220.ogg to the top level of you're .app and then recompile it to make the code signature process happy.<br>
<br>ov_read calls _fetch_and_process_packet which will call vorbis_synthesis_blockin after making sure oldsamples == 0. vorbis_synthesis_blockin updates<br>
v->pcm_returned to 0 and v->pcm_current to 1024.<br><br>Now, vorbis_synthesis_pcmout will always return 1024.<br><br>Thanks,<br>Kwasi<br><br><div class="gmail_quote">
On Wed, Dec 15, 2010 at 5:53 AM, <span dir="ltr"><<a href="mailto:xiphmont@xiph.org" target="_blank">xiphmont@xiph.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div>On Wed, Dec 15, 2010 at 3:20 AM, Kwasi Mensah <<a href="mailto:kwasi.mensah@gmail.com" target="_blank">kwasi.mensah@gmail.com</a>> wrote:<br>
> Hey guys,<br>
><br>
> I'm using Tremor cl 17618. vorbis_synthesis_blockin is doing some type of<br>
> overlap adding that I think is pushing ov_pcm_tell to be greater than<br>
> ov_pcm_total when reading the last bit of audio data from an ogg file. This<br>
> causes a later call I make to ov_pcm_seek fail. Is this by design? Should I<br>
> just fix my call to ov_pcm_seek to take this into account?<br>
<br>
</div></div>That is not by design; tell and total should agree (and do on the test<br>
cases I have here). Could you perhaps send me the file causing<br>
trouble?<br>
<br>
Monty<br>
</blockquote></div><br>