Kai Vehmanen hat gesagt: // Kai Vehmanen wrote:
> ecasound -f:16,2,44100 -i /dev/dsp -o filename.wav
>
> Now I just couldn't resist the temptation. ;) Now if wavrec and other
> simple tools handle the job, why use 'monsters' like ecasound? Well, a
> quick list of what you get by doing the above with ecasound:
>
> - ecasound can provide double-buffering (-z:db)
> - lock-free communication between disk and audio threads (-z:db)
> - support for realtime scheduling (-r)
> - better control over buffering done by soundcard
> drivers (-b:bsize and -z:intbuf + -z:nointbuf)
> - support more other formats than just 16bit/stereo (32bit, multich, ...)
> - support for OSS, various ALSA versions, aRts (C-API), LADPSA, LAAGA, ...
> - support for various file formats other than wav (mp3, ogg, libaudiofile)
> - ...
>
> ... and even with the simple use case above, these options can be useful.
> If for nothing else, then for recording reliability.
Well, first a big THANK YOU for developing ecasound, which I think is one of
the most useful unix tools I found, since "ls -la" ;-)
Now, seriously, I just today found, that one of the mp3-soundfiles,
I record daily in real time, had errors (BTW: This was first time it
ever happend, and I used ecasound for more than a year every day)
Probably high system load caused this (The Realproducer was producing
at the same time "for real").
ecasound was running without "-r", now I changed this to run ecasound with
high priority.
Will -r help, although I can't run a low latency patched kernel, just plain
kernel.org stuff?
Or will I have to play around with the buffer settings?
Thanks,
--
__ __
Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______
/ __// __ /__/ __// // __ \ \/ / __ \\ ___\
/ / / ____/ / / / // ____// /\ \\ ___\\____ \
/_/ /_____/ /_/ /_//_____// / \ \\_____\\_____\
/_/ \_\
