server option questions

[Klaus Schulz-2]

Hi folks.

I am running 2.7.0 git.

1. I was wondering if an  "echo -e "quit\r\n" | nc -w1 localhost 2868" is be supposed to kill the process.
   It is just working in interactive mode as I expected, but  not in server mode.

2. Stop is rather a "pause" as I see it!? Is there a real "Stop" going back to position 0?

3. What's the difference between  engine-halt and stop? 

4. What happened to the "eadb" option?



THX Klaus

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Kai Vehmanen]

Hello,

On Tue, 29 Sep 2009, Klaus Schulz wrote:

> 1. I was wondering if an  "echo -e "quit\r\n" | nc -w1 localhost 2868" is be supposed to kill
> the process.
>    It is just working in interactive mode as I expected, but  not in server mode.

hmm, that's a good question. In current implementation, it just terminates
the remote client connection, but not the server process itself. I'm not
sure if this should be changed... any insights?

> 2. Stop is rather a "pause" as I see it!? Is there a real "Stop" going
> back to position 0?

Yes, stop is like a tape recorder stop: tape stops rolling, state is
preserved and tape is not ejected (so it's still ready for immediate use).

If you want to go to position zero and start again, "stop" and "setpos 0"
will do the trick.

> 3. What's the difference between  engine-halt and stop? 

The former halts and exits the engine thread. To continue the tape
recorder metaphor, 'engine-halt' would be like ejecting the tape and
powering off the tape recorder. The tape (=ecasound chainsetup) can be
edited with other tools.

Hopefully not too many people need to bother with 'engine-halt' and
'engine-launch', and their semantics, but in some cases they are needed.
For instance when using JACK, 'engine-launch' registers ecasound with the
JACK server while 'engine-halt' tears down the connection. This is
important especially when syncing to JACK transport state ("stop" in
ecasound may be overridden by "start" in some other JACK application). By
disconnecting from the engine (with "engine-halt"), this can be
temporarily avoided.

But yeah, these are not really intended for wider use. For most
use-scenarios, plain "start" and "stop" should be sufficient.

> I am running 2.7.0 git.
[...]
> 4. What happened to the "eadb" option?

It's still there (e.g. "-eadb:3"), and there have been no changes
to it recently (since April to be precise).
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Joel Roth-2]

On Tue, Sep 29, 2009 at 10:08:52PM +0300, Kai Vehmanen wrote:
> On Tue, 29 Sep 2009, Klaus Schulz wrote:
>
>> 1. I was wondering if an  "echo -e "quit\r\n" | nc -w1 localhost 2868" is be supposed to kill
>> the process.
>>    It is just working in interactive mode as I expected, but  not in server mode.
>
> hmm, that's a good question. In current implementation, it just
> terminates the remote client connection, but not the server process
> itself. I'm not sure if this should be changed... any insights?

Why should the client have the authority to terminate the
server's existence? If the client needs to, he can
do so explicitly, i.e. 'killall ecasound'.

My $0.02.

Regards,

--
Joel Roth

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Klaus Schulz-2]

Hello Kai.

On Tue, Sep 29, 2009 at 9:08 PM, Kai Vehmanen <kvehmanen@...> wrote:

Hello,

On Tue, 29 Sep 2009, Klaus Schulz wrote:

1. I was wondering if an  "echo -e "quit\r\n" | nc -w1 localhost 2868" is be supposed to kill
the process.
   It is just working in interactive mode as I expected, but  not in server mode.

hmm, that's a good question. In current implementation, it just terminates the remote client connection, but not the server process itself. I'm not sure if this should be changed... any insights?

1. The issue I have with this. If I want to setup a new process from remote  for working with a new track I have to kill the ecasound process manually.
   It would be much nicer and easier to do that through the server option.
2. It is somewhat inconsistent to interactive
3. It is not described properly

 

2. Stop is rather a "pause" as I see it!? Is there a real "Stop" going back to position 0?

Yes, stop is like a tape recorder stop: tape stops rolling, state is preserved and tape is not ejected (so it's still ready for immediate use).

If you want to go to position zero and start again, "stop" and "setpos 0" will do the trick.

Good to know. That seems to be the way it is.

 

3. What's the difference between  engine-halt and stop? 

The former halts and exits the engine thread. To continue the tape recorder metaphor, 'engine-halt' would be like ejecting the tape and powering off the tape recorder. The tape (=ecasound chainsetup) can be edited with other tools.

Hopefully not too many people need to bother with 'engine-halt' and 'engine-launch', and their semantics, but in some cases they are needed. For instance when using JACK, 'engine-launch' registers ecasound with the JACK server while 'engine-halt' tears down the connection. This is important especially when syncing to JACK transport state ("stop" in ecasound may be overridden by "start" in some other JACK application). By disconnecting from the engine (with "engine-halt"), this can be temporarily avoided.

But yeah, these are not really intended for wider use. For most use-scenarios, plain "start" and "stop" should be sufficient.

I am running 2.7.0 git.

[...]

4. What happened to the "eadb" option?

It's still there (e.g. "-eadb:3"), and there have been no changes to it recently (since April to be precise).

OK. Just tried it.  It still works. It's not in the man-pages though.   Tricky: If we talk about "gain" as a function you need to enter a negative db value to attenuate, which is the number one use-case . This can lead to problems ( See your example). Entering a +12db is done easily and will generate a quite a bit of clipping not only in your ears.. Of course I know that the user should know what he is doing.


THX Klaus



------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Joel Roth-2]

On Wed, Sep 30, 2009 at 09:07:58AM +0200, Klaus Schulz wrote:

> Hello Kai.
>
> On Tue, Sep 29, 2009 at 9:08 PM, Kai Vehmanen <kvehmanen@...> wrote:
>
> > Hello,
> >
> > On Tue, 29 Sep 2009, Klaus Schulz wrote:
> >
> >  1. I was wondering if an  "echo -e "quit\r\n" | nc -w1 localhost 2868" is
> >> be supposed to kill
> >> the process.
> >>    It is just working in interactive mode as I expected, but  not in
> >> server mode.
> >>
> >
> > hmm, that's a good question. In current implementation, it just terminates
> > the remote client connection, but not the server process itself. I'm not
> > sure if this should be changed... any insights?
> >
> >
>
> 1. The issue I have with this. If I want to setup a new process from remote
> for working with a new track I have to kill the ecasound process manually.
>    It would be much nicer and easier to do that through the server option.
> 2. It is somewhat inconsistent to interactive
> 3. It is not described properly

I could get along with either way, however I have some
responses.

Regarding (1) I understand that you might want to have a new
Ecasound process to be sure that all your initializations
are fresh.

OTOH, Ecasound's initializations seem clean enough.

Has anyone reported memory leaks for long running instances?
Isn't 'cs-disconnect' sufficient to start from the
beginning?

Regarding (2) The idea of a server is to have a long-lived
process, so such a difference is not so odd.

(3) Of course the difference should be documented. But as a
reason... well understand you are running the bleeding edge.  :-)
 
Regards,

--
Joel Roth

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Kai Vehmanen]

Hi,

On Wed, 30 Sep 2009, Klaus Schulz wrote:

>> hmm, that's a good question. In current implementation, it just
>> terminates the remote client connection, but not the server process
>
> 1. The issue I have with this. If I want to setup a new process from remote  for working with
> a new track I have to kill the ecasound process manually.
>    It would be much nicer and easier to do that through the server option.

yes, I can see the usefulness of this. Although terminating ecasound with
a SIGTERM sent to the process is a clean way as well. You'll anyways get
the PID when you start the ecasound server instance, so it should be
fairly straighforward to use it to terminate the process as well.

> 2. It is somewhat inconsistent to interactive
> 3. It is not described properly

these are good points. I now updated ecasound-iam(1) documentation to
explain the behaviour in more detail.

[-eadb]
> OK. Just tried it.  It still works. It's not in the man-pages though.  
> Tricky: If we talk

Hmm, are you sure you have the git manpages installed? I just checked
and the git sources for ecasound(1) do mention -eadb.

> about "gain" as a function you need to enter a negative db value to
> attenuate, which is the number one use-case . This can lead to problems
> ( See your example). Entering a +12db is done easily and will generate a
> quite a bit of clipping not only in your ears.. Of course I know that
> the user should know what he is doing.

That's true and I now added more text to ecasound(1) to describe the
behaviour of -eadb as well.

What do others say about this? Personally, I'm not sure whether
attenuation is the number use-case. Plus the chainop is called "amplify"
so that suggests that the default behaviour is to amplify. But then again,
I'm fine with using linear scale as well, so maybe I'm not best person to
comment on this...
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list