Re: [ecasound] Garbage at end of playback: ecasound or alsa broken?

From: Joel Roth <joelz@email-addr-hidden>
Date: Sun Jul 21 2013 - 09:25:19 EEST

Knut Petersen wrote:
> On 20.07.2013 20:02, Joel Roth wrote:
> > Hi Knut,
> >
> > Knut, if you want a copy of testout.wav, I don't see why
> > you are using the soundcard as an input, except maybe
> > as a source for extra silence. If so, that may not
> > be the best solution.
> The RME Digi96 / PAD with expansion boards allows up to 8
> channels of 24 bit audio for simultaneous recording and playback,
> but the hardware buffer is small: 42.666 ms. So I modified the
> kernel driver rme96.c to allow (much) bigger buffers to reliably prevent
> buffer underruns / overruns.

Wouldn't a 40ms buffer rule out software monitoring?

> The modified rme96.c does work perfectly with arecord, aplay, and a
> number of other applications, but it breaks audacity as audacity does
> fail to play correctly on non-mmap devices.
> I also tested ecasound, and found the problem described in
> the original post.

I am still curious about whether the problem was with
ecasound or the expectation, as I'm unclear the
precise intent and effect of the routing you chose to use.
It looks like some sort of loopback.

> Recording the output and comparing input/output is simply a test
> that can help to find the necessary multitrack offset but it is also
> very helpful to validate the working of all the software layers involved.

Such thoroughness will surely be rewarded. :-)


> cu,
> Knut Petersen

Joel Roth
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
Ecasound-list mailing list
Received on Sun Jul 21 20:15:01 2013

This archive was generated by hypermail 2.1.8 : Sun Jul 21 2013 - 20:15:01 EEST