Re: vorbis decoder stuffs

furthermore,   the file handle stuff is nothing more than a hack for all 
the other decoders added sometime later from their initial creation.  It 
is something that Has to be removed.  Especially before work on 
minimizing the use of locks such that zinf is not crashable by races can 
continue.  My latest ogg vorbis decoder is much closer to the "standard" 
decoder look.  I've also determined exactly why seeking doesn't work in 
it.  i should have time wednesday and thursday to move my BeginRead code 
arond the BeginWrite code so that the sequence of pausing and clearing 
the subsystems works correctly and doesn't introduce a garbage pcm 
buffer to the output plugin. I've actually simplified the plugin and 
since i have it much in the format of the other plugins seeking works if 
you time when you seek correctly, all that remains is moving the read 
methods to the correct place to get it working 100% of the time.

I could shove code in the InitDecoder and DecodeWork methods into 
separate private functions like the other decoders do but it's not 
really necessary.  In the end my decoder works the way an lmc for zinf 
Should work minus seeking at the moment.  The other decoders are corrupt 
and need to be fixed. And in the case of the vorbis plugin, 
libvorbisfile requires the File as far as i know to decode and this is 
simply not acceptable in zinf.

Ed Sweetman wrote:
> Kristian Kvilekval wrote:
> 
>>
>> Ed,   I have committed your makefile and lmc changes.
>>
>> I don't even feel comfortable trying your patches to the vorbis decoder
>> at the moment. I am having a hard time believing this is the right
>> direction to take the vorbis decoder.    I, for one, prefer the clarity
>> of the old decoder.    I think more work needs to be done to understand
>> *why* the current(old) decoder fails on fast track switching. Was it a
>> race condition in the vorbis lib that you were working around?
>> Can you pinpoint the code that causes the race?
> 
> 
> Even if i fixed the old decoder so that it could fast track (which is 
> possible i think), the old decoder depended on access to filehandles. 
> This breaks interface design.  It's not acceptable even if it worked 
> completely and this is true of all the decoders.  Why have subsystems at 
> all if we're not going to adhere to them.
> 
> 
>>
>>
>> On Mon, 2003-03-31 at 14:59, Ed Sweetman wrote:
>>
>>> The problem i'm having with seeking is that with vorbis files when i 
>>> execute the seek command like all the other plugins do with their 
>>> changeposition method the next BeginRead method call always returns 
>>> NoDataAvail.  This occurs whenever changePosition method is called 
>>> even when there is no code in the method.  That means that either we 
>>> do something different if we have the vorbis lmc loaded in the player 
>>> code (wouldn't put zinf passed a dirty hack like that) or the 
>>> structure of the beginRead's writes, endReads,writes need to be in a 
>>> certain arrangement for shit to work.
>>>
>>> Again, fun stuff.  At least i know i can remove all the extra 
>>> conditional checks and boolean variables and extra lock.
>>>
>>> anyone with any ideas of why changePosition calls cause this problem 
>>> would be appreciated.  I'll be working on it some more.
>>>
>

-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/