[prev in list] [next in list] [prev in thread] [next in thread] 

List:       alsaplayer-devel
Subject:    Re: [Alsaplayer-devel] Re: Additions to the plugin interface
From:       Richard Boulton <richard () tartarus ! org>
Date:       1999-10-04 14:14:58
[Download RAW message or body]

On Fri, Oct 01, 1999 at 09:12:09PM +0200, Andy Lo A Foe wrote:
> > Actually, I'd suggest doing INPUT_CAN_SEEK by setting the frame_seek
> > field to NULL if we can't seek - that removes all risk of the
> > implementation and the flags being out of sync.
> That is how are things are working now, and it works very well.
Ah, good. :)

> > > INPUT_NEED_SMALL_BUF, etc. etc.
> > Not sure what you'd want that for?
> I think I read somewhere in your TODO file that streaming stuff from one
> machine to another introduced considerable latency on the ALSA part
> because of the depth of the internal ringbuffer. The above flag could tell
> the player to allocate a very small ringbuffer. A large ringbuffer is only
> really useful for reverse playback purposes..
Ah, I see.  Though I suppose we could use the absence of ability to seek
to imply this (if you can't seek, you can't do reverse play either...)

I'm sure the flags will be useful for _something_ though. ;-)

> > Is there any reason that the STL isn't used anywhere in alsaplayer so far?
> No not really, but doesn't usage of STL blow up the code substantially?
> I was also using the C++ exception feature in early versions. It worked
> quite well, but the executable was about 200K larger, for no apparant
> reason :)
I don't think that it causes much increase - stripped binary with the new
playlist routines using various lists and other STL things is 139K.
It shouldn't really increase the size much - after all, it's just templates,
not linking against extra libraries.
I tend to think having reliable and maintainable code is well worth a few
extra K in the binary, and the STL makes the code _so_ much easier to write.

Is the size of the binary so important, anyway?  I don't see much advantage
in having a tiny binary, when you have to wait for ages to dynamically
load everything - actually, I was thinking of making a configure
option to compile some or all plugins in fully, for easier debugging, and
for possible faster startup.

> > We could store the plugins in a <vector>, which would dynamically
> > size.  Various other places the code could be made far nicer as a result,
> > too.
> 
> I never used the STL, but this might be a good intro :)
Once you've started, you'll have difficulty avoiding using it.  *grins*
It's the best thing about C++, in my opinion.
Make sure you have a good guide to it though - in my experience, nothing's
much better than Stroupstroup's C++ book (edition 3)

> Dunno, important is that the stuff we use should already be available on a
> standard Linux box at least. Not sure if STL comes with gcc these days.
It does.  At least, STL stuff compiles fine on my vanilla gcc installations.
(both Debian and Redhat)

> Ah cool, so we can have multiple "views" of a single playlist active at
> the same time?
That's the idea - I think we should be aiming for separating as much
user interface stuff from core code as possible, in this sort of way.

I've now (about an hour ago) checked in versions of the playlist stuff
which work quite well - as far as I can see, everything which used to
be there, apart from Saving playlists and Removing items from playlists,
is now working, in the new architecture.

Good luck merging your changes to the CVS - shouldn't be too hard, 
though you'll have to fiddle with the playlist stuff quite a bit to
merge your multiselect mods, since that's effectively been rewritten.

(For reference, the way I'd merge my changes is to:
 a) diff the 0.99.28pre3 release against your latest version
 b) check out the latest CVS version
 c) manually apply the diffs to the CVS version
 d) fiddle with the stuff in PlaylistWindow.cpp so that it works
    with multiple select
 e) check in the changes
)

It's all beginning to be quite cool now, though.
--Richard



[prev in list] [next in list] [prev in thread] [next in thread]