Ed Sweetman | 1 Apr 14:39
Favicon

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
(Continue reading)

Robert Hart | 1 Apr 14:51
Picon
Picon
Favicon

Re: vorbis decoder stuffs

Ed,

Do you still intend for there to be a zinf3 written from scratch? or are
you happy to stick with the existing code-base for the time-being? I
presume you have moved away from that idea.

just curious.

Rob

--

-- 

      o o o o ~~  ~~ ~                                      _____
   o     _____         ________________ ________________ ___|_=_|_()__
 .][_mm__|[]| ,===___ ||              | |              | |          |
>(_______|__|_|______]_|              |_|              |_|          |_|
_/oo-OOOO-oo' !oo!!oo!=`!o!o!----!o!o!'=`!o!o!----!o!o!'=`!o!o--o!o!'
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

-------------------------------------------------------
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/
Ed Sweetman | 1 Apr 16:52
Favicon

Re: vorbis decoder stuffs

Robert Hart wrote:
> Ed,
> 
> Do you still intend for there to be a zinf3 written from scratch? or are
> you happy to stick with the existing code-base for the time-being? I
> presume you have moved away from that idea.
> 
> just curious.
> 
> Rob
> 
> 

to make a rewrite possible i need further experience in all the parts of 
zinf, hence the work on zinf.  To put a conservative estimate on how 
much of the current zinf i know would be 75% or more.  With the only 
major things i'm lacking being the theming of the main gtk ui and the 
procedural expectations of certain current actions (because they're not 
documented and sometimes it's hard to tell if something is meant to do 
what it's doing or if it's a bug and working by chance) Other than that 
i've been in every single file in zinf and know how most of the things 
work.

I have changed my mind about just wanting to eventually abandon zinf 
2.x, I think it can be perfected given it's architecture, it just 
requires the motivation to do so and the will power to not fall back on 
hacks.  If you look at my todo list, my 2.3.x is where i'll be happy 
with the state of zinf.  When i can bring zinf to that point i'll be 
ready to rewrite it. In the meantime i am still working on parts of the 
rewrite, certain objects i plan to use that are streamlined and 
(Continue reading)


Gmane