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