30 Jan
2018
30 Jan
'18
1:06 p.m.
On Tue, January 30, 2018 20:35, Chris Caudle wrote:
On Tue, January 30, 2018 12:46 pm, Christian Affolter
wrote:
indeed, very strange
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 used a hand-crafted non-released player that can do it. it's just
playing the 48k file as if it would be 12k. any resampler could do it. it
was not distorted but i could hear the 's' is degraded. it could be 7.5
bit or something. very strange.