Re: 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ecasound-list