[nama] Re: Playback stops too soon
- From: "S. Massy" <lists@xxxxxxxxxxxx>
- To: nama@xxxxxxxxxxxxx
- Date: Tue, 24 Apr 2012 13:49:36 -0400
On Mon, Apr 23, 2012 at 11:32:42PM -1000, Joel Roth wrote:
> > 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.
Yes. When I installed ecasound from git, my ecasoundrc got overwritten.
I now have the settings in my $HOME ecasoundrc file to avoid this
happening again.
>
> 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.
(1) works fine but could easily confuse new users (and old ones too!).
(3) seems like overkill but would work just fine, of course. I'd vote
for (2).
It becomes even more important, because the problem I described
(stopping too soon) was also due to a mismatch in sampling rates. A
hunch made me try this quick calculation---
length_in_seconds*44100/48000--- and was gratified that it yielded
exactly the point at which playback would stop. What I suspect is
happening here is that ecasound overrides its default format based on
wave headers, as you described, but fails to update some aspect of its
internal sampling rate, causing a mismatch between where it thinks its
playback head is and where it actually is. I'll report this on
ecasound-list.
>
> 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?
I'd suggest nama explicitly sets as many parameters as it can and rely
as little as it can on ecasound's defaults: otherwise, confusion can
result too easily.
Cheers,
S.M.
Other related posts:
