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

List:       kde-multimedia
Subject:    Re: aRts issues with long files
From:       Charles <charles () altair ! dhs ! org>
Date:       2000-05-28 17:13:49
[Download RAW message or body]

On Sun, 28 May 2000, you wrote:
> Hi!
> 
> On Sat, May 27, 2000 at 11:20:20PM -0700, Charles wrote:
> > I was adding the progress slider to noatun (e.g., getting it to work) and I came
> > up with an odd bug.
> 
> You'll need to patch wavplayobject_impl.cc if you want to test seeking, as it
> currently doesn't support it - shouldn't be too hard, but needs to be done. It
> will not even give you overall time information, read the source to see it.
> 
> > When opening a file (which requires a trick in itself).  Hit the play button. 
> > and my disk starts thrashing. so I kill noatun.  with top, I learn that artsd
> > still is using about 35mb of ram.
> >
> > Take a look at kdemultimedia/noatun/noatun/player.cpp for the evil code (lines
> 
> I also observed this once with big files. I added a fix against the crash now.
> 
> The memory leak should be fixed now, too - the wavs are loaded to a cache,
> which wasn't cleaned up properly until now. Maybe one could make the size
> configurable one day (it is 8192K hardcoded right now), but other than that,
> it should work.
> 
> 
> Regarding the "freeze" that occurs with big files, there is a deeper problem:
> 
> The wav loading code (see CachedWav) loads wavs as a whole - which is, at
> best, a stupid idea, when it comes to large files. The problem you are
> running into is that this will interrupt all other operations, too, which
> makes things even worse.
> 
> If somebody would rewrite the whole wave loading thingy to a bucketwise
> loading/caching instead of a overall loading/caching, then things would
> work a lot nicer. On the other hand, also the resampling code currently
> assumes that you perform resampling operations in one huge memory area,
> and not bucketwise, so this would need to be adapted. This is the reason
> why the artsplug (mpeglib) resampling code looks so ugly, while for
> incoming audio streams (artscat, quake), resampling is simply *not done
> at all*.
Ok, about getting the times.  

Secondly, shouldn't qtmcop provide signals for things such as "playingdone" and
all?  And doesn't yet, noticably, but, well.  I have no point to make here
anyway :)

Can't the file just be mmaped ?  If I'm correct, mmap doesn't actually move
anything into memory, while "emulating" it in memory :)  Seems a good way
to save our archetecture, save memory, and have a increase in performace!

> 
> Any volunteers? 
/me looks around innocently.

> 
>    Cu... Stefan
> -- 
>   -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
>      KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         
> _______________________________________________
> Kde-multimedia mailing list
> Kde-multimedia@master.kde.org
> http://master.kde.org/mailman/listinfo/kde-multimedia
--

Charles - charles@kde.org
_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@master.kde.org
http://master.kde.org/mailman/listinfo/kde-multimedia

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