Subject: Re: [ecasound] silent failure
From: Maik Musall (lists_AT_musall.de)
Date: Tue Sep 14 2004 - 16:52:11 EEST
Hi Kai,
On Thu, Sep 09, 2004 at 11:11:59PM +0300, Kai Vehmanen wrote:
> > I've got a problem that ecasound fails recording, stops execution
> > immediately but gives no error message and exit code 0, so it's quite
> > difficult to deal with that error.
>
> What version of ecasound and of ALSA? There have been problems with
> certain versins of ALSA, which could lead to errors like this.
Version is 2.3.3, as is current in gentoo. Sorry I didn't mention it
at the first place.
> > ecasound -t:$DURATION -i alsahw,${CARDNR},0 -q -o stdout | buffer |\
> > oggenc -r -Q -q3 -o $FILENAME -
>
> Why use 'buffer' and 'oggenc'. Add suggest to use:
>
> sh> ecasound -t:$DURATION -i alsahw,${CARDNR},0 -o $FILENAME.ogg
>
> ... and put the necessary oggenc options to your ~/ecasound/ecasoundrc.
> See ecasoundrc(5) man page for details.
Yes, I found that, but my script is going to be extended, and there
will be several simultaneous recordings that all may differ in
ogg quality options. I'm recording radio sources, and I plan to
reduce quality and switch to mono on voice-only stuff while
taking high quality on classical music. The final version will
probably generate oggenc options from radio program information.
I understand that's pretty to complicated for ecasoundrc, and
with that differing options the oggenc command line is just
the right place to do what I want. And, I want to keep the
scripting modular so that I could exchange the encoder at any
time or even choose different encoders for different recordings.
I use buffer since sometimes the CPUs are heavily loaded, and that
gives me a few seconds that oggenc may run after.
> Now if it still fails, something will be printed out to the
> terminal. I'd be interested in that info...
It printed just the onle line that a new session was started, and
exited immediately afterwards (sorry, don't have saved the literal
string).
In the meantime I discovered that it all happens only if there's
some sort of race condition in the scripting environment that leads
to two ecasound processes attaching to the same alsa device. When
I put a second pause between two continuous recordings on the same
device, I get a stable recording. Missing that one second is not
that bad, so I'm happy for my application, but the fact remains
that I got an unclean state by starting two ecasound simultaneously
that remained until alsa was restarted, and ecasound didn't have
any exit code other than 0 at any time (which I consider the most
important problem since the error could not be detected
automatically when occurred).
Perhaps you can reproduce the behaviour by just starting two
ecasound recordings on the same audio device? If not, how does
it behave in your installation?
Thanks and Regards
Maik
This archive was generated by hypermail 2b28 : Tue Sep 14 2004 - 16:52:38 EEST