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

List:       kde-multimedia
Subject:    Re: mpeglib import
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-07-11 18:42:01
[Download RAW message or body]

   Hi!

On Fri, Jul 07, 2000 at 02:05:23PM +0200, Martin Vogt wrote:
> On Fri, Jul 07, 2000 at 12:42:36AM +0200, Stefan Westerfeld wrote:
> > On Thu, Jul 06, 2000 at 03:23:38PM +0200, Martin Vogt wrote:
> > > Then we can have a big buffer as default, and maybe if
> > > a game connects we can make it less.
> > > Can we add a "prefereedBuffersize" call when connecting to artsd?
> > > changing it on runtime?
> > 
> > It is very hard to implement, as inside artsd, there are lots of ringbuffers
> > which are allocated specifically adapted to the requested latency. Besides,
> > most of the streaming applications orient themselves on the latency, so all
> > apps would dynamically need to change their streaming strategy, too.
> 
> I dont think its hard to implement. If the user sets in
> the configuration dialog "big Buffer" simply adjust the buffer
> on the soundcard.
> No need to inform the modules about this.
> Ok you might get wrong latency in the modules but a user who
> notice then has to restart arts.
>
> [...]
>
> If mp3 is not working "good enough" as default, nobody will
> use arts anyway. [...]

Okay, I am looking a bit deeper into this, now. But in any case, dynamically
adjusting latency will *sometimes* lead to an audible plop.

What *sometimes* is, depends on two things:

=> BUFFERING:

If you use the current strategy to access /dev/dsp, you need to close and
reopen the device every time you change the latency. This is because the
ioctl-call can only be done directly after open.

There is one other way, which is always use big fragmentcount/fragmentsize
settings on the device, and only partially fill it, but I need to test out
how reliable this is. (Okay: memory mapping might be also an option).

=> USER INTERACTION:

Using the current strategy, playing would get broken by changing latency
dynamically, which is really bad (if you are listening to your mp3 collection,
and start quake which would dynamically change latency, you'll get a click,
which is ugly).

Using the other strategy, only full duplex would get broken, which is
unavoidable during a latency change.



Well, I'll see if I can get some runtime-latency-change implemented properly.
I don't think doing it automatically by the server is a good idea, as it will
create audible plops in some situations, but having a latency slider in
artscontrol would certainly make the decision less grave.

On the other hand, I am still investigating a safe realtime set program, which
is IMHO the only way to *guarantee* that there are no dropouts, while with
a latency of 370 ms (seems to be the maximum on my soungcard), you can only
*hope* that there are none.

Btw, use artsd -F 16 -S 4096 for maximum latency, anything else will not do
more, at least not on my soundcard.

   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]