Hi!

On Tue, Sep 07, 1999 at 10:26:38PM +0200, Martin Vogt wrote:
> ok here the new results, with the "example_mixer_nosat.arts" 
> This looks better :)
> But still it uses :
> 
> 19288 m_vogt    15   0  6512 6512  3464 R       0 21.4 10.3   0:10 artsserver.b
> 19297 m_vogt     8   0  1044 1044   824 R       0  3.6  1.6   0:00 top
>  
> 20 % of my cpu, when nothing is played (!).

Well, yes - I think I need to implement a "power saving" function or
something like that, which does disable unused components of a flow
graph. I will probably work on a special low CPU usage only audio
server set of structures/modules, which should bring down the CPU load
quite a bit further.

By the way: standard mixing behaviour... what would be good here? I know
that you would feel better if calling artsmp3 just started playing,
without any further user interaction. I also know you want dynamically
added mixer channels (instead of statically configured ones).

So the question arises: how loud shall the first mp3 be played? 100%?
50%? What should happen if 16 bit are not enough to do all the output?
Clipping? Saturation filter?

Anybody knows how esd handles this?

> Ok, now I start artsmp3:
> 
> 19288 m_vogt    14   0  6808 6808  3468 R       0 26.5 10.7   0:26 artsserver.b
> 19311 m_vogt     6   0   960  960   748 S       0 14.3  1.5   0:03 mpg123
> 19312 m_vogt     1   0  3816 3816  2904 S       0  3.6  6.0   0:01 artscat
> 
> But still clicks. (which makes it more or less unusable to play mp3s)
> 
> The buffer in this new windows goes never under ca. 75%.
> Maybe you send too small samples to the server?

The offending function you all (Coolo and you and whoeverelse) are
complaining about is (src/synthesizer/sound-linux.c):

int sound_realtime(int audio_fd, int pbsize)
{
    int arg =  0x70008;  // (pbsize-1)+0x40000;
 
    if (ioctl(audio_fd, SNDCTL_DSP_SETFRAGMENT, &arg))
    {
        perror("sound_realtime\n");
        return(1);
    }
    return(0);
}                                                                               

This sets the output parameters of aRts to 7 Fragments of 2^8 = 256 bytes.
This means, that after 1792 Bytes, a buffer underrun will necessarily
occur. Of course, for audio server usage we can discuss this value. For
realtime effect processing or midi stuff, it guarantees the excellent
latency value of

10.1000 ms (1792/(2*2*44100)*1000)

as upper boundary, while in normal operation having something like

1.4 ms - 2.8 ms (1-2 Fragments) latency.

However, I will include options to make this tunable in the next aRts
release, so then you can see for yourself. However, for any KDE installation
I would nevertheless recommend using realtime rights, since it is the
only way you can make guarantees about "non-clicking" sound reproduction.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-