Re: [ecasound] found some bugs in latest development versions

New Message Reply Date view Thread view Subject view Author view Other groups

Subject: Re: [ecasound] found some bugs in latest development versions
From: Kai Vehmanen (
Date: Wed Apr 26 2000 - 05:54:33 EEST

On Mon, 24 Apr 2000, Jeremy Hall wrote:

> maybe what I need to do is write a separate application for what I am
> trying to do. What AM I trying to do you might ask?
> difficult to do all this typing. For network use, they want timed
> events. (like news insert on top of the hour) they want me to respond to
> 25HZ tones, for example. They want NO dead air, and if it DOES appear,
> currently it requires lots of typing and many commands to restore
> now let's say that 1 is playing a song that will end in 5 seconds. I need
> to queue the next song on 2 so that it is ready for when I want to start
> 2, not a predetermined event (like ewf)

I'd say this would be best handled in a separate application. The
current console-mode ecasound is a really low-level and generic
interface. Because of this, it's not extremely user-friendly and it's
not very robust (=protection against invalid ia-mode commands).

My idea has been that it should be relatively easy to build more
task-specific user-interfaces on top of the generic interfaces.
Qtecasound, ecawave and gteca are already written this way.

> 1: if one accidentally specifies a -i argument, but argument is not a
> valid file for some reason, ecasound dumps core.

Yup, currently it's up to the caller to check file validity. I'll
try to add some safety checks to this.

> 2: if one uses -kl on a nonexistant argument, ecasound dumps core, for
> example

Same as above. I'll try to add checks for this, too.

> 4: it would be nice if we could have a "audition" mode, one way to do this
> would be to use two versions of ecasound, with two inputs, one being te
> "live" signal and another being a monitor signal. the output is the

This is something that should definitely be done in a separate, higher
level user-interface.

> 5: I am not certain how to make ecasound add a new input gracefully, then
> manually start this input. I don't want to continuously add new channels,
> but I do want to be able to switch the input to a new file.

Yep, as I said in my previous message, ecasound expects inputs to be
related (->operating inputs and outputs separately is not possible).
These things should be done using multiple ecasound instances.

> 6: have the ability to enable a "last-resort" input. This would be if
> something goes wrong, and an input source just stops for some reason. If

Same as above.

> (within reason), I just catted all of them into a large file. ecasound
> played 5 of the songs, then stopped at the end of one of them, where one

Can you play this catted file with mpg123?

Kai Vehmanen <> ---------------- CS, University of Turku .
 . audio software for linux ... 		 .
 . armchair-tunes mp3/wav/ra .. .

-- To unsubscribe send message 'unsubscribe' in the body of the message to <>.

New Message Reply Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Apr 26 2000 - 06:06:01 EEST