Subject: Re: [ecasound] -z:db
From: S. Massy (theanaloguekid@tak.net.dhis.org)
Date: Thu Dec 07 2000 - 08:13:25 EET
On Wed, 06 Dec 2000, Kai Vehmanen wrote:
>
> Hmm, all SCHED_FIFO (and SCHED_RR) processes have a static priority
> between 0 and 99. If there are multiple rt-scheduled processes active, one
> with the highest priority gets to run. Ecasound defaults to 50, but you
> can change this by giving a parameter to -r (-r:99 for max priority). You
> can also increase the db-size (for instance -z:db,200000). But
> underruns/overruns are possible even if you are using -z:db and ecasound
> is the only rt-process. If this happens, you should make sure you disks
> are tuned (hdparm, and with 2.4.x kernels, elvtune), try running a
> lowlatency-patched kernel, etc, etc...
The priority control thing is good to know. I want to emphasize that ecasound was not running SCHED_FIFO while running the test I mentioned.
Tuning hard drives is definitely a good idea, it is what made the greatest difference for me, a much greater difference even than applying LL patches... (Especially enabling DMA in the kernel "changed my life")
>
> > Only thing I wish now was better is real time I/O. I have problems
> > with OSS emulation (static blast and slight lag) and I have
> > overrun/underrun problems with ALSA devices (coming at irregular
> > times for no reason). These problems are only present with ecasound;
> > but as ecasound uses the sound card's capabilities more extensively
> > that your regular mp3 player it is not really surprising. If this
>
> As mentioned earlier, the first problem is driver related. But the xrun
> problem is another thing. Are you sure you are not suffering from xruns
> when running other apps? As far as I know, only a few other apps report
> about xruns, while most just ignore them. And using /dev/dsp (native OSS
Well, it's often grave droupouts: sometimes I even have to stop and restart the playback for it to go away.
> or emulated), it's not even possible for an app to detect them.
>
> Anyway, I have too noticed some weird xrun behaviour using the latest ALSA
> drivers. When using ALSA devices in native mode, I easily get xruns, but
> with the same drivers (and under similar circumstances), OSS emulation
> works flawlessly. Now it's possible that they perform equally well, but
> under OSS-emulation xruns are just ignore. A small xrun is not audible,
> but if the device is stopped after an xrun (even if it's soon started
> again), you'll hear even the smallests xruns.
Yeah, that the same driver would behave differently with OSS emulation and native ALSA devices is really strange: that's why I thought the "ALSA native" problem was ecasound related.
>
> --
> . http://www.eca.cx ... [ audio software for linux ] /\ .
> . http://www.eca.cx/aivastus ... [ aivastus net radio ] /\ .
>
>
> --
> To unsubscribe send message 'unsubscribe' in the body of the
> message to <ecasound-list-request@wakkanet.fi>.
>
-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Thu Dec 07 2000 - 08:15:02 EET