Re: afSeekFrames bug?

Jim,
I just added a regression test for seeking, and I have not encountered
any problems similar to the one you describe.

In order to investigate further, it would be helpful if you could provide
me with your test cases.

Michael

On Wed, Aug 20, 2003 at 10:04:26AM -0600, Jim Ramsay wrote:
> Please be patient, this may take a moment to explain.
> 
> I am running this on a brand-new IBM machine running an old caldera linux
> with a 2.2.16 kernel.  I cannot upgrade this kernel, I don't have any
> control over the OS on this particular machine.  I downloaded and compiled
> version 0.2.3 of the audiofile library using gcc 2.95.2, and it appears to
> have gone smoothly.
> 
> I'm trying to use libaudiofile to obtain data from a WAV file and loop when
> I get to the eof For testing purposes, I've created a series of wav files at
> different bit resolutions, all with the same number of samples.  Let's take,
> for example, one with 10 24-bit samples, ranging from 0x010203 through
> 0x01020c in sequence.
> 
> I open the wav file and get no errors.  The number of channels is 2, and I
> set up my virtual sample format to be TWOSCOMP and 32-bit.
> 
> Then run a routine requesting 30 samples.  Basically, the code should be
> have in this manner:
> 
> - Get 10 samples (5 frames) from the wav file, in order.  It does this
> correctly.  I get:
>   0x01020300
>   0x01020400
>   0x01020500
>   0x01020600
>   0x01020700
>   0x01020800
>   0x01020900
>   0x01020a00
>   0x01020b00
>   0x01020c00
> - Realize that EOF has been reached without reading all 30 samples and do
> afSeekFrames( file, AF_DEFAULT_TRACK, 0 ).  It seems to do this correctly,
> as afTellFrames returns 0 after the seek.
> - Get 10 more samples (5 more frames) from the wav file, in order.  I expect
> to get the same 10 I got last read.  Instead I get:
>   0x01020800
>   0x01020900
>   0x01020a00
>   0x01020b00
>   0x01020c00
>   0x00000000
>   0x00000000
>   0x00000000
>   0x00000000
>   0x00000000
>   It appears that the seek only went back half-way in the file and started
> reading at the 5th sample (half-way through the 3rd frame), reading 5 frames
> (filling the not-found samples with 0), then realizing that the file only
> had 5 frames (10 samples) in it, and returning.
> - The next seek also apparently happens correctly, and afTellFrames returns
> 0.
> - The next get returns 10 samples, all 0x00000000
> 
> I have tried replacing the call to afSeekFrames with closing and re-opening
> the file, but there is no difference.  The second read still starts halfway
> through the file.
> 
> Has anyone experienced this, or does anyone know how I can fix it?
> 
> Jim Ramsay