On 21.07.2013 08:25, Joel Roth wrote:
> 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?
For the equivalent of an 8-track tape recorder big buffers at the driver level
are a convenient feature that help to prevent xruns. Live dsp has totally
different needs. But even very big buffers are not harmfull in that case,
you are not required to wait until they are filled ;-) The can be programmed
to generate interrupts every 1.33 msec ....
> 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.
Joel, this setup is a pure test setup. Itīs definitely a bug when a
44100 samples playback is expected and a 44100 samples
playback is done immediately followed by a playback of about 1982
samples that had a been played already in the past.
cu,
knut
------------------------------------------------------------------------------
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!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Mon Jul 22 00:15:02 2013
This archive was generated by hypermail 2.1.8 : Mon Jul 22 2013 - 00:15:02 EEST