Re: [ecasound] torture-testing -z:nodb scenarios

Hi,

On Sat, 19 May 2012, linux media 4 wrote:

> I've seen many post here about enabling/disabling double buffering and
> I'm still confused about what can go wrong with -z:nodb set.

a real-time audio program needs to process audio at a fixed rate. With
JACK, this is set by the driver period size, let's call it P. At every
iteration, jackd calls to ecasound to get/provide samples and ecasound has
time P to process everything.

If ecasound has any disk objects, and -z:nodb is set, ecasound will access
read/write system calls _directly_ from its audio thread. From a design
perspective this is highly problematic as there are no guarantees how much
a single disk operation may take time, and whether it finishes by P.

Factors that contribute to the non-determinism of disk seeks:
   - physics: on magnetic drives, due seek times and fragmentation,
     access times depend on where the data is
   - multiple layers of buffering: glibc does first level of buffering,
     kernel has its own buffering, all modern hardware add a significant
     layer of buffering
         - e.g. filesystems matter, XFS may be better for streaming big
             files, but it's somewhat hard to measure these (especially
           w.r.t latencies, max througput is always easier)
   - concurrent use: while CPU and memory can be locked via standard POSIX
     APIs, there are no standard APIs (for applications) to allocated
     fixed i/o bandwidh
         - classical case is starting a full system backup, "find /" and
           running a kernel compilation, while using ecasound.. one
            should not get _any_ xruns even in this case
         - note: there are admin tools to traffic shape i/o bandwidth, but
           there are no standard application interfaces to use these
   - ...

So in the end, as an application, -z:db is the only way to perform
reliable audio streaming from/to files, using portable APIs.

Now ecasound may work flawlessly even with -z:nodb, but this is always
system and use-case specific. So while this may be good enough in some
cases, I'd still strongly recommend defaulting to -z:db when targeting the
general case (versus a single, specific tested system).

PS I do agree that compared to available i/o bandwidth nowadays,
    audio flows are fairly small streams, and relatively speaking
    are becoming even tinier. However, latency is more problematic,
    and I wouldn't trust even big i/o bandwidth extra capacity to
    cover for latency spikes. Things like SSDs of course change
    the game, but e.g. with SSDs, writes are still an issue (due to
    complicated wearing algorithms and what not on these drives).

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Sat May 26 12:15:02 2012