Kristian Kvilekval | 1 Apr 11:32
Picon
Gravatar

Re: vorbis decoder stuffs


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?

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

Ed Sweetman | 1 Apr 14:08
Favicon

Re: vorbis decoder stuffs

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

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)

Tim Lesher | 3 Apr 05:43

Re: vorbis decoder stuffs

On Sun, Mar 30, 2003 at 12:06:26PM -0500, safe mode wrote:

> I noticed a bunch of win32 commits but no activity on this mailing
> list or the irc channel, communication anyone?

Nothing that hasn't already been discussed; the commits were strictly
undeletions.

> i'm going to have a number of patches backed up that need to be 
> committed, win32 issues or not.

As I've mentioned before, I don't see anything in your current patches
that should cause problems for (and should therefore be help up by)
the win32 port.  If I do, I'll certainly complain. ;-)

--

-- 
Tim Lesher <tim <at> lesher.ws>
http://www.lesher.ws

-------------------------------------------------------
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 | 5 Apr 04:29
Favicon

Re: vorbis decoder stuffs

One would think figuring out why your decoder is running way too fast 
would be pretty straight forward...but that person would be wrong.

I rewrote the  decoder to look much like the wavlmc and xinglmc does. 
In the process i have new issues to deal with so yea...not very fun 
stuff.  I'll be working on it as much as i can.  It is so close to 
working that it hurts and is extremely aggrivating.  In the end though 
the extra responsiveness is worth it :)

-------------------------------------------------------
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/
Matt | 6 Apr 20:55

make issue on Zinf, suse 8.1 with Gcc 3.2

Hi

if /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I.
-I../../config  -D_REENTRANT -I../../base/include
-I../../base/unix/include -I../../lib/utf8 -I../../ui/include
-I../../lmc/include -I../../io/include -I../../lib/utf8/include   -Wall
-Wmissing-prototypes -O -MT charset.lo -MD -MP -MF ".deps/charset.Tpo" \
  -c -o charset.lo `test -f 'charset.c' || echo './'`charset.c; \
then mv ".deps/charset.Tpo" ".deps/charset.Plo"; \
else rm -f ".deps/charset.Tpo"; exit 1; \	
fi
../../libtool: ../../libtool: No such file or directory
make[2]: *** [charset.lo] Error 1
make[2]: Leaving directory `/home/matthew/Source/Zinf/zinf/lib/utf8'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/matthew/Source/Zinf/zinf/lib'
make: *** [all-recursive] Error 1

Already tried --/bindir/usr/bin/

Anything I can try...libtool is certainly installed, looks like Zinf
cannot find it.

This is from a CVS build. Oh does this support EMP from eMusic?

Thanks,

Matt

-------------------------------------------------------
(Continue reading)

Ed Sweetman | 6 Apr 21:26
Favicon

Re: vorbis decoder stuffs

Just wanted to update the current progress of the decoder and clear up 
why i'm spending so much time on a new one while the current one "works".

1. I dont think the callback method of using libvorbisfile is able to be 
protected.  We'd have to force a workaround so the situation doesn't 
occur and that's very very ugly.

2. It doesn't follow the lmc design.  The callback method basically 
hands over control of the plugin to libvorbisfile.  The format of the 
plugin may look the same on the surface, but it doesn't function like 
the wav and xing plugins do.

These are the unreparable issues with using libvorbisfile to do our 
decoding.  There are fixable ones as well in all current plugins.

FILE handles have no place in the lmc's.  They will be removed and with 
it all depending code on them.

There are also global variables in each plugin that have the same name 
as other global variables and such.  This cannot be a good thing.  If 
these variables are used outside of the plugin we will need to make a 
standard way to retrieve their data via method calls to the plugin's 
class, otherwise they will just be private data to each plugin's lmc 
class.

Some of the issues mentioned above are of no fault to the code in 
question. There are architectural issues with zinf that create some of 
these problems and we cant do anything about that without major 
rewrites.  Other players dont have the same issues we're having because 
they dont have the same structural flaws. But the code written for zinf 
(Continue reading)

Ed Sweetman | 6 Apr 21:31
Favicon

Re: make issue on Zinf, suse 8.1 with Gcc 3.2

did you use ./autogen.sh to build the autoconf files in zinf?

i imagine ./configure would have died if you didn't have libtool 
installed.

Matt wrote:
> Hi
> 
> if /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I.
> -I../../config  -D_REENTRANT -I../../base/include
> -I../../base/unix/include -I../../lib/utf8 -I../../ui/include
> -I../../lmc/include -I../../io/include -I../../lib/utf8/include   -Wall
> -Wmissing-prototypes -O -MT charset.lo -MD -MP -MF ".deps/charset.Tpo" \
>   -c -o charset.lo `test -f 'charset.c' || echo './'`charset.c; \
> then mv ".deps/charset.Tpo" ".deps/charset.Plo"; \
> else rm -f ".deps/charset.Tpo"; exit 1; \	
> fi
> ../../libtool: ../../libtool: No such file or directory
> make[2]: *** [charset.lo] Error 1
> make[2]: Leaving directory `/home/matthew/Source/Zinf/zinf/lib/utf8'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/matthew/Source/Zinf/zinf/lib'
> make: *** [all-recursive] Error 1
> 
> Already tried --/bindir/usr/bin/
> 
> Anything I can try...libtool is certainly installed, looks like Zinf
> cannot find it.
> 
> This is from a CVS build. Oh does this support EMP from eMusic?
(Continue reading)


Gmane