[nama] Re: Playback stops too soon

  • From: Joel Roth <joelz@xxxxxxxxx>
  • To: nama@xxxxxxxxxxxxx
  • Date: Mon, 23 Apr 2012 23:32:42 -1000

On Mon, Apr 23, 2012 at 06:13:44PM -0400, S. Massy wrote:
> Hello,
> 
> I'm running both nama and ecasound from git. Working today, I noticed
> that projects stop playing back some seconds before the end. The
> particular project I'm working on at the moment insists on stopping
> exactly 11 seconds before the end, while others will stop sooner or
> later, or even some time tracks are stopping individually. At first I thought
> it might be ecasound, but playing a saved chainsetup with cs-save-as
> doesn't exhibit these symptoms. Can anybody else reproduce this?

Individual tracks stopping is *weird*, especially
considering how Ecasound runs. However a fade-out
could cause it to *appear* to have stopped.

I didn't try a project, but had a look at the code. 

There are two reasons that Nama can stop the engine
before it completes the run.

One of them, limit_processing_time(), is called during
start_transport(). It sets up a timer to stop
processing, but doesn't appear to be used much.
(I've commented it out and pushed the patch.)

The other thing that happens is that Nama polls 
the Ecasound engine status. On receiving 'finished'
or 'error' status, Nama prints the current
position and status, sends the 'stop' command, clears
any timers, and resets the transport position
to the beginning.

> Btw, when saving a chainsetup from within nama using cs-save-as, the
> audio objects are defined with e.g -f:f32_le,2,44100 even though the
> actual samplerate I use is 48000, and one needs to mass-replace for the
> chain-setup file to load in ecasound.

Probably Ecasound gets this value from ecasoundrc or 
its internal default.

I believe Ecasound will override this setting for *inputs*
based on the audio format reported by the WAV file header.

Solutions could be: (1) set default-audio-format in
ecasoundrc, (2) patch Nama to issue cs-set-audio-format
with the correct default during engine setup,
(3) patch Nama so that the chain setup explicitly sets
the audio format for every input and output object.

This issue has come up a number of times. Should
Nama's behavior (even for a command such as cs-save-as) 
be influenced by settings in ecasoundrc?

Regards,

 
> Cheers,
> S.M.
> -- 
> 

-- 
Joel Roth

Other related posts: