<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 30, 2018 at 8:35 PM, Chris Caudle <span dir="ltr"><<a href="mailto:chris@chriscaudle.org" target="_blank">chris@chriscaudle.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, January 30, 2018 12:46 pm, Christian Affolter wrote:<br>
> What I also observed is the fact, that capturing 10 seconds<br>
> (jack_capture -d 10 ...) directly from the "-d alsa" jackd takes around<br>
> 40 seconds (real 0m40.457s) vs. 10 seconds (as one would expect) with<br>
> the "-d dummy" jackd (real 0m10.339s)<br>
<br>
</span>That is very strange, the test-arecord.wav and test-jack_capture.wav files<br>
are the same size, the file captured with jack is not 4 times larger.<br>
<br>
Does that CentOS machine have any attached audio hardware?  If so you<br>
could use the alsa_out plugin to play the captured audio, for example<br>
through a USB audio interface, and if that audio path is OK maybe just<br>
jack_rec or jack_capture is causing the problem.  I'm not sure what other<br>
capture programs can run headless and capture from jack, NAMA perhaps?<br>
Actually I just checked and NAMA uses ecasound as the backend, just use<br>
ecasound directly, it has jack support.<br>
<br>
How did you get the file to play back at 12kHz?  Could you tell if it was<br>
really distorted like the capture was mis-packing the original data,<br>
taking a 32 bit input word, putting just 16 bits of that into the first<br>
half of a 32 bit word...that only accounts for 2x time, not 4x, and is<br>
really a stretch, I don't see how an error that egregious could slip<br>
through jack or jack_capture.  Very strange.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>I think we probably can rule out errors in jackrec or jack_capture now.</div><div>jack_capture not only reports all underruns, but it also fills underruns</div><div>with empty samples, so it should never produce shorter audio files.</div><div>It seems more likely like jack doesn't call the process callback as</div><div>often as it should.</div><div><br></div><div><br></div></div></div></div>