[alsa-devel] Garbage at end of playback: ecasound or alsa broken?
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
Hi,
On Sat, 20 Jul 2013, Knut Petersen wrote:
Summary: A very short period (about 45ms) garbage is played at the end of every playback.
[...]
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"
this usage triggers multitrack recording mode in ecasound (ecasound will try to align recording of testin.wav to playout of testout.wav), and the symptoms sound like an issue with this mechanism.
I couldn't reproduce this with my setup (ice1712), so could you retry the test with "-z:notintbuf"? If the problem still persists, can you send me (may be large, so please send offline) logs when run with "-dd"?
participants (2)
-
Kai Vehmanen
-
Knut Petersen