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

List:       kde-multimedia
Subject:    Re: aRts issues with long files
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-05-29 9:25:39
[Download RAW message or body]

   Hi!

On Sun, May 28, 2000 at 10:13:49AM -0700, Charles wrote:
> On Sun, 28 May 2000, you wrote:
> > 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*.
> 
> 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 :)

That would be cool. However, qtmcop can only provide functionality that the
underlying mcop stuff supports (it can't emit a signal if it doesn't know when
it should).

And indeed, it would be really good to have this functionality. It's in the
TODO, too, and called

- notifications when attributes change

What I mean is that you should somehow be able to say: notify me when the
"state" attribute of my PlayObject changed. Then you'd get notifications if
it changes from posPlaying to posFinished or to posPaused.

Currently, artscontrol for instance polls the FFT scope and the volume lights,
using a QTimer... :( - and simplesoundserver_impl.cc also uses quite some
timer driven stuff which would be unnecessary then, I guess.

This would be the soft version, e.g. you only get "attribute foo has changed".
The hard version would be to allow

interface PlayObject {
	[...]
signals:
	void finished();
};

in the IDL, or even

interface SeekWidget {
signals:
	void seekClicked(poTime seekTo);
};

where the latter would enable yo to call

  connect(seekWidget,"seekClicked(poTime)",playObject,"seek(poTime)");

However, it looks a bit like reinventing the wheel ... hehe ;) - also note
that in MCOP, we wouldn't need slots, because every interface method can be
invoked dynamically, so you could connect signals to any normal method or
attribute.

> 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!

libaudiofile doesn't support mmap, and we currently do all our I/O using the
functions libaudiofile provides. This has the advantage that we don't need
to bother about how a wav file looks, and get support for exotic stuff like
.au or .aiff for free (although I never tried this, it should be possible).

On the other hand, if you want really really well defined performance, mmap
may not be the thing to use, as using the system cache will never give you
any guarantees whether or not some page is in memory. Implementing your own
granular caching, you can for instance always cache the sample beginnings,
so that you'll have some time to load what is required later (for music
production and things). Also, using open(...,O_DIRECT) for these files will
enforce that the system will not do caching of the same things, so that
you'll effectively only have one cache for the sampling data (although at
this point, we might need to drop libaudiofile, too).

The blockwise resampling code will need to get written in any case, by the
way, because not being able to send data from user apps with 22kHz, although
the sound server plays at 48kHz seems unacceptable. Especially when using
artsdsp, apps will need such things ;)

   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

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