Re: [ecasound] new ecasound jack plugin

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [ecasound] new ecasound jack plugin
From: S. Massy (theanaloguekid_AT_tak.net.dhis.org)
Date: Tue Jan 08 2002 - 03:38:00 EET


On Sat, 22 Dec 2001, Kai Vehmanen <k_AT_eca.cx> wrote:

> On Sat, 22 Dec 2001, Jeremy Hall wrote:
>
> > whatever it is, it seems to be an ecasound feature--it has existed for
> > MONTHS and has made ecasound quite unusable for long sessions. Ardour
Glad to know I'm not alone...
>
> Now how come ecasound works fine here, absolutely no problems, both with
> ALSA 0.9.x and OSS? And if it really is soundcard specific, that makes
> fixing the problem quite a bit harder as I only have my ens1371 to play
> with.
True...

But the good news is that I just enjoyed two hours of non-garbled rt
processing with ecasound using the jack plugin... So I guess there's
hope... :)

Perhaps one thing you'd like to know is that whenever you try to connect
to jackd unsuccessfully (for instance if you've not specified the proper
buffer size to ecasound) an xrun is triggered...
>
> > does not have this problem. Perhaps it is that ardour's handling of IO is
> > different than the way the library functions do things--he directly
> > manipulates the mmap'd memory where as we read from the alsa lib
> > functions.
That's what I thought myself; at least ardour and jack that use the
mmaped areas way work fine while the read/write way ecasound uses seems
to cause problems, but it'd need to be tested with other apps as well to
really be proven true...
>
> Another possibility is that ardour use ALSA's hw-sync to start processing,
> while ecasound doesn't. On the other hand, this can still be
> card-specific.
As the nature of the problem isn't all that clear it's hard to tell; I'd
bet my money on a syncronization problem...
- Happens without any xrun occuring.
- Goes away if device is reset.
>
> > I'd say whomever is the clock master should run with a higher
> > priority. In the case of jack v ecasound, I'd say jack should run with a
> > higher priority.
>
>
> But it's good to remember that Jack is a synchronized system. When jackd
> passes the control (token) to ecasound's Jack client, it will not run
> until it gets the token back. So in other words they won't run at the same
> time. This on the other also means that giving a higher priority to jackd
> shouldn't hurt much either.
>
> --
> http://www.eca.cx
> Audio software for Linux!
>
> --
> To unsubscribe send message 'unsubscribe' in the body of the
> message to <ecasound-list-request_AT_wakkanet.fi>.
>

--
To unsubscribe send message 'unsubscribe' in the body of the
message to <ecasound-list-request_AT_wakkanet.fi>.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Jan 08 2002 - 03:28:55 EET