Subject: Re: [ecasound] EDI Proposal
From: Kai Vehmanen (k_AT_eca.cx)
Date: Fri Dec 21 2001 - 07:37:24 EET
On Thu, 6 Dec 2001, S. Massy wrote:
> I'd like to propose a big EDI: To rewrite the alsa3 stuff in its most
> part if not from scratch.
Basicly yes, but I don't fully agree with your reasoning.
The problem with ecasound's current ALSA code as I see it is that it is
messy. The same code has gone through endless small changes to adapt to
the latest and greatest ALSA development APIs, and this shows.
> Ok, so that's something rather big (at least if done with a bit of
> thought behind it.). The main reason that I see is that the current
> implementation is a port of the alsa2 stuff that was made in the days of
> 0.6 and then patched up as alsa's API evolved; this is bound to
> create bugs for a start and then it also makes it so that ecasound
> doesn't take advantage of the most recent features introduced in the 0.9
> series. Already some oddities and deficiencies are appearing like the
This I don't buy, at least not without proof. :) Most of the
plugin code is related to ecasound's internal logic and to setting
the ALSA configuration. The actual code that handles audio i/o is
only a few pages. Ecasound uses the ALSA pcm read/write API and it is very
well documented. Unlike the newer mmap() style pcm API, semantics of the
read/write API are well-known. So it's _very_ unlikely to find bugs in the
implementation.
> low samplerate bug which is a bit annoying. The current implementation
> works fine in most cases still, at least for me, it seems to bring bad
> drawbacks: I can't do fullduplex operations (like fx processing) for
> more than ten or fifteen minutes before the sound starts degrading
> significantly, a problem which isn't present at all with ardour.
> (BTW, last time I checked ardour was using the mmapped areas scheme to talk
> with alsa... and let's not forget the ctl interface.)
It's also possible that the lowlevel soundcard drivers have bugs which
cause problems to the upper levels. One specific scenario is that certain
use patterns (ie. read/write or mmap, use of stream start/stop, etc)
trigger problems in the lowlevel drivers. In real world this means that
app X works fine with driver Y using API Z, while app X2 has problems with
driver Y using API Z2.
Your case might fit this description, where X=ardour, X2=ecasound,
Z=mmap and Z2=read/write.
Of course if all cards worked better with ardour, I'd start to be
suspicious. But as it is, full-duplex works brilliantly with my ens1371
and latest ecasound and ALSA versions. I've recorded a _lot_ of material
lately and with zero problems.
On the other hand, with the same ALSA drivers and ens1371, I've had
problems of garbled audio with JACK, which again is using the mmap() API
just like ardour.
-- 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>.
This archive was generated by hypermail 2b28 : Fri Dec 21 2001 - 07:29:33 EET