Subject: Re: [ecasound] -z:db
From: Kai Vehmanen (k@eca.cx)
Date: Wed Dec 06 2000 - 19:12:22 EET
On Sat, 2 Dec 2000, S. Massy wrote:
>> With the current code, you will just get one "overrun!" message, and if
>> you get this, well you're done. ;)
> Must it be a debug version of ecasound to get this message? I use a
> normal version but with debugging messages turned fully on.
The overrun/underrun messages coming from -z:db code are sent directly
to strerr, and they are always fatal (ecasound exits at once if
xrun occurs).
> Anyway, I think you have made it, Kai: I just spent half an hour or so
> listening to mp3's with ecasound while running bonnie++ (HD
> benchmarking) in another console and got NO underrun nor any other
> complain! I started with a buffersize of 1024 and then got so bold as
This is great to hear! At the moment, the -z:db known bugs list
completely empty, so I think it's ready every day use. One thing
that has to be decided, is whether to enable -z:db by default. There's
already a "default-to-double-buffering" option in ~/.ecasoundrc, but it
defaults to "false". Also I must add code to automatically disable -z:db
if there are no realtime objects in the chainsetup (no sense in wasting
memory if there are no realtime requirements).
But, but, this is a tricky question. On the other hand, -z:db does eat a
lot of memory (default is 100000 * frame-size * num-of-tracks; one
CD-quality track requires 400kB of memory). And secondly, the code
is more complex (potentially more error-prone and inefficient). But on
the other hand, people expect to get dropout free performance even
without specifying any special arguments.
> only interruption I got was when loading my packages list in dselect;
> but I suspect they use SCHED_FIFO there because every time I use it
> any streaming goes amiss. (I got a sound interruption but no underrun
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...
> 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
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.
-- . 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>.
This archive was generated by hypermail 2b28 : Wed Dec 06 2000 - 20:04:45 EET