Subject: Re: [ecasound] pyeca
From: smoerk (smoerk_AT_gmx.de)
Date: Mon Dec 02 2002 - 02:27:02 EET
Hello Kai,
when I use jack as output it only happens with jackd running in
non-realtime mode, but not very often. With jackd in realtime mode it
never happend, but I can reproduce this behaviour with alsa output
(running ecasound as root).
**** alsa_pcm: xrun of at least 26.163 msecs
lines. but I'm not really sure if this only happens with jack. I think I
tried it yesterday with alsa output, but I cannot reproduce it now...
Kai Vehmanen wrote:
> On Sat, 30 Nov 2002, smoerk wrote:
>
>
>>I experienced one problem with pyeca. It seems that ecasound or pyeca is
>>not fast enough to catch every EIAM command, it just ignores them. Is
>>there a workaround to make sure that every EIAM command is handled by
>>ecasound?
>
>
> Actually this should not happen. Commands are sent in order to the
> ecasound engine and the engine never skips any incoming commands. Also,
> the ECI command() function does not return until the command is actually
> processed (ie. the return value always matches the last issued command).
> If other situations occurs, then it's most probably a bug.
>
> Hmm. I tested your example and it seemed to work ok here.
> You could try inserting a "e.command("cop-status"); print e.last_string()"
> to the inner loop of ecastest.py to see what is actually happening.
>
>
>># ./ecatest.py
>>Chain operator status: ### Chain operator status (chainsetup
>>'play_chainsetup') ###
>>Chain "1":
>> 1. Amplify: [1] amp-% 97.00
>>Chain "2":
>> 1. Amplify: [1] amp-% 0.00
>>Chain "3":
>> 1. Amplify: [1] amp-% 0.00
>
>
> When I ran the tests, all operators had a final amp-% of 0.00...
>
This archive was generated by hypermail 2b28 : Mon Dec 02 2002 - 02:22:42 EET