Re: Garbage at end of playback: ecasound or alsa broken?

Hi Knut,

Knut, if you want a copy of testout.wav, I don't see why
you are using the soundcard as an input, except maybe
as a source for extra silence. If so, that may not
be the best solution.

When a setup has inputs from soundcard and WAV file, there
is some adjustment to synchronize them. It is called the
'multitrack mode', and is a default. That could partly
explain your unexpected results.

'man ecasound' says:

'-z:multitrack' and 'z:nomultitrack'  can  be used to force
ecasound to enable or disable multitrack-mode. In rare
cases you  may  want  to  explicitly specify  the  recording
offset with '-z:multitrack,offset-in-samples'. The offset
is the amount of samples skipped when recording from
real-time  inputs.

What about using input from the null device?

ecasound -t:2 -f:16,2,44100 -a:1 -i testin.wav -a:2 -i null -a:1,2 -o testout.wav

Cheers,

Joel
               
Knut Petersen wrote:
> Hi everybody!
> 
> ======================================================================
> Summary: A very short period (about 45ms) garbage is played at the end of every playback.
> ======================================================================
> 
> Hardware
> ========
> mobo: AOpen i915GMm-hfs
> cpu: Pentium-M
> ram: 2GB
> intel hda, realtek codec
> rme digi96/pad
> onboard intel hda, realtek alc880
> 
> Software
> =======
> opensuse 12.3
> linux kernel 3.10.1, 3.11-rc1
> ecasound, git ab6a9c3be5440b05f2c9eb240ee0d42578379f8d
> 
> 
> Steps to reproduce the problem:
> =========================
> 
> 1: generate test file
> ===============
> Start audacity, generate  a 44.1 khz stereo track,
> one second audio, start 400 Hz, end 4000Hz,
> start amplitude 0.5, end amplitude 1.0
> export to testin.wav as 16bit wav
> 
> 2: playback test file and record it
> =========================
> Setup soundcards and cabling, execute
> "ecasound -t 2 -f:16,2,44100 -a:1 -i testin.wav -o alsahw,0,0  -a:2 -i alsahw,0,0 -o testout.wav"
> 
> 
> 3:Expected result:
> ==============
> testout.wav should hold a proper recording of testin.wav, padded with silence at the end.
> 
> 4: my result
> =========
> testout.wav
> 1 - starts with about 90 Samples of silence (not nice, how can I avoid that?)
> 2 - continues with 1 second of properly recorded audio (expected)
> 3 - continues with about 1982 samples of audio (0,045s) (unexpected, severly broken)
>       The garbage audio is part of the original audio, starting at about 26xxHz, ending at about 28xx Hz
> 4 - continues with silence to the end of the file (expected)
> 
> Discussion
> =========
> The same problem exists if I record rme96 to rme96, hda to rme96 or hda to hda.
> So it´s probably not a problem of the rme96 or hda alsa drivers.
> 
> Is this problem known? Can anybody confirm the problem with different hardware?
> Should I blame alsa or ecasound? Any ideas?
> 
> cu,
>   Knut
> 
> 
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Ecasound-list mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ecasound-list

-- 
Joel Roth
  


------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Ecasound-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ecasound-list