Subject: Re: [ecasound] Moving from v1.9dev5 to v2.0.1 -> performance goes down
From: Teppo Peltonen (tpeltone@cc.hut.fi)
Date: Sat Jul 28 2001 - 11:47:06 EEST
Kai Vehmanen <k@eca.cx> writes:
Hello Kai and thanks for the reply,
> On 27 Jul 2001, Teppo Peltonen wrote:
>
> I'd bet my money on -z:intbuf/-z:nointbuf. In 1.9dev6, -z:nointbuf was
> made the default (was -z:intbuf before).
Hmm... this is a confusing thing. I decided to ignore the -z:nointbuf
totally for now, because it didn't make things better. Let's see, my
.ecasoundrc says
default-to-internal-buffering = false
So, wouldn't that mean that internal buffering is disabled, same as
-z:nointbuf?
However, this doesn't seem to be the case. If I add the -z:nointbuf
parameter, I get a lot of snap, cracle'n pop.
I'll add the output here, just to make this clear. The first one is
ok, the second one isn't.
(eca-audio-objects) Audio object "/dev/dsp", mode "read".
(audio-io) Format: s16_le, channels 2, srate 44100, interleaved.
- [ Chainsetup/Enabling audio outputs ] ------------------------------------
[teppo@ahven work]$ ecasound -r -z:db -b:256 -z:intbuf -i:/dev/dsp -o:/dev/dsp
****************************************************************************
* ecasound v1.9dev5 (C) 1997-2001 Kai Vehmanen *
****************************************************************************
(eca-session) Raised-priority mode enabled. (prio:50)
(eca-session) Memory locked!
(eca-chainsetup) Using double-buffer of 100000 sample frames.
(eca-chainsetup) Setting buffersize to (samples) 256.
(eca-chainsetup) Enabling extra buffering on realtime devices.
- [ Chainsetup/Enabling audio inputs ] -------------------------------------
(eca-audio-objects) Audio object "/dev/dsp", mode "read".
(audio-io) Format: s16_le, channels 2, srate 44100, interleaved.
- [ Chainsetup/Enabling audio outputs ] ------------------------------------
(eca-audio-objects) Audio object "/dev/dsp", mode "write".
(audio-io) Format: s16_le, channels 2, srate 44100, interleaved.
- [ Engine/Init - mixmode "simple" ] ---------------------------------------
Using realtime-scheduling (SCHED_FIFO).
(eca-main) Prefilling i/o buffers.
- [ Engine/Exiting ] -------------------------------------------------------
[teppo@ahven work]$ ecasound -r -z:db -b:256 -z:nointbuf -i:/dev/dsp -o:/dev/dsp
****************************************************************************
* ecasound v1.9dev5 (C) 1997-2001 Kai Vehmanen *
****************************************************************************
(eca-session) Raised-priority mode enabled. (prio:50)
(eca-session) Memory locked!
(eca-chainsetup) Using double-buffer of 100000 sample frames.
(eca-chainsetup) Setting buffersize to (samples) 256.
(eca-chainsetup) Disabling extra buffering on realtime devices.
- [ Chainsetup/Enabling audio inputs ] -------------------------------------
(eca-audio-objects) Audio object "/dev/dsp", mode "read".
(audio-io) Format: s16_le, channels 2, srate 44100, interleaved.
- [ Chainsetup/Enabling audio outputs ] ------------------------------------
(eca-audio-objects) Audio object "/dev/dsp", mode "write".
(audio-io) Format: s16_le, channels 2, srate 44100, interleaved.
- [ Engine/Init - mixmode "simple" ] ---------------------------------------
Using realtime-scheduling (SCHED_FIFO).
(eca-main) Prefilling i/o buffers.
- [ Engine/Exiting ] -------------------------------------------------------
[teppo@ahven work]$
> One thing to note is that "-b:128 -z:intbuf" might actually result
> in longer latency times than "-b:1024 -z:nointbuf".
Yes and then there is the -z:db which sometimes seems to make the
initial latency longer but maybe keeps things better in sync for
longer recordings...
> So there are quite a few variables. The most difficult part in
> tuning these is that different use-cases have different needs. For
Sigh, yes I know, and it's very time consuming to experiment. However,
I'm really happy I can do this using ecasound and not some really mind
twisting GUI application maybe on another OS. ;-)
> is why choosing between -z:intbuf/-z:nointbuf is so difficult. It's
> always a compromise.
Yep, and it's really hard to make objective observations with your
ears and brains... On a good (bad?) day a 40ms latency might go with
almost unnoticed. Then, another day comes and everything sounds broken
if there is an extra 20ms between the input and output.
Thank you very much for this information. I have to try more
later. Now I think I'll go out and get some sun. Haven't had too many
sunny days here this summer, well... ;-)))
> Hmm, this needs to be investigated. Can you send me an example .ewf file?
Sure, I can append the ewf file right here, but I'm not sure you can
do anything with it... I'm mean that the looping sounds ok, but when
you play it with a related wave file, which has been recorded live
using the loop file as a rythm track, then the error cumulates and
things sound horribly off-sync after a minute or so.
start-position = 0.500000
source = drums/150.wav
length = 6.374989
looping = true
I might upload some sound files on my WWW pages later, if
interested. Not sure if I got the space, though.
Teppo
---- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Sat Jul 28 2001 - 11:46:17 EEST