General discussion of EcaSound multitrack audio editor

linux media 4 | 20 May 2012 01:00

torture-testing -z:nodb scenarios

Hi,

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.

I've been writing an Front End to Ecasound for about 8 years (and 
therefore running on a regular basis as I test new features). It's a 
'Jack Only' program. So everything I say pertains to Ecasound/Jack.

I'm currently running ecasound v2.8.1 but have not had any unusual 
behavior the whole 8 years of testing my front end with prior versions 
of ecasound with -z:nodb set.

I need to say several things. First, I have the most well tuned system. 
I run Fedora + CCRMA and that addresses just about any issue necessary 
to allow for most well tuned system for audio work. I also run Jack and 
Ecasound in 'Realtime Mode'. Also... the 'Recording Hard Drive' is 
separate so that the only Input/Output is from Ecasound (all System 
Activity happens on the other Hard Drive).

So far, I've not seen anything unusual with normal use. What kinds of 
things could go wrong by using -z:nodb? I would be glad to torture-test 
any scenarios if you can point me to what can go wrong using -z:nodb.

Thanks,
Rocco

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and

(Continue reading)

headers

S. Massy | 20 May 2012 01:49

Re: torture-testing -z:nodb scenarios

On Sat, May 19, 2012 at 04:00:57PM -0700, linux media 4 wrote:
> Hi,
> 
> 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.
> 
> I've been writing an Front End to Ecasound for about 8 years (and 
> therefore running on a regular basis as I test new features). It's a 
> 'Jack Only' program. So everything I say pertains to Ecasound/Jack.
> 
> I'm currently running ecasound v2.8.1 but have not had any unusual 
> behavior the whole 8 years of testing my front end with prior versions 
> of ecasound with -z:nodb set.
> 
> I need to say several things. First, I have the most well tuned system. 
> I run Fedora + CCRMA and that addresses just about any issue necessary 
> to allow for most well tuned system for audio work. I also run Jack and 
> Ecasound in 'Realtime Mode'. Also... the 'Recording Hard Drive' is 
> separate so that the only Input/Output is from Ecasound (all System 
> Activity happens on the other Hard Drive).
> 
> So far, I've not seen anything unusual with normal use. What kinds of 
> things could go wrong by using -z:nodb? I would be glad to torture-test 
> any scenarios if you can point me to what can go wrong using -z:nodb.
Firstly, I think it is unlikely you woould run into trouble using nodb
on a modern system set up as you describe. Double-buffering was added to
ecasound in the early 2000s at a time when hardware (no SATA then) and
software (before a lot of the block layer rework) were a long ways away
from what they are now. At the time, double-buffering was crucial to
offering reliable multi-track performance on Linux. If your number of

(Continue reading)

headers

Kai Vehmanen | 26 May 2012 08:38

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

(Continue reading)

headers

linux media 4 | 21 Jul 2012 21:25

Re: torture-testing -z:nodb scenarios

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.

On 05/25/2012 11:38 PM, Kai Vehmanen wrote:
> a real-time audio program needs to process audio at a fixed rate.
[CUT]
> Factors that contribute to the non-determinism of disk seeks:
[CUT]
> 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).
[CUT]

Thanks for the comprehensive information on this subject.

I will create radio buttons in my program for the User to select from a 
range of buffer sizes. What would be the lowest and highest value I 
would want to use for the first and last button, and what increments do 
you think these buttons should be in?

My goal is to offer the most precise control over double buffering so 
they can get the best performance for their particular setup and usage.

Many thanks for this great software that keeps us motivated to expand.

Rocco

------------------------------------------------------------------------------

(Continue reading)