[Jack-Devel] Capture problems with jack2 on Axia-Alsa device

[Kjetil Matheussen]

On Tue, Jan 30, 2018 at 8:35 PM, Chris Caudle <chris at chriscaudle.org> wrote:

> On Tue, January 30, 2018 12:46 pm, Christian Affolter wrote:
> > 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.
>
>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.linuxaudio.org/archives/jackaudio/attachments/20180130/ff7f2f5f/attachment.html>