30 Jan
2018
30 Jan
'18
4:35 a.m.
Hi everyone,
capturing from ALSA capture devices via the Jack2 sound server (1.9.12),
results in too high pitched wav files (they are playing "too fast" and
sound like the "chipmunks"). If I run the same capture directly from the
ALSA devices (without Jack involved), everything sounds as expected
without any problems.
Audio examples:
Capture via jackrec: https://filebin.ca/3pyMxBw8cexQ/test-jackrec.wav
Capture via arecord: https://filebin.ca/3pyOPjcKGym5/test-arecord.wav
The device in question is a "virtual" Axia-ALSA (Livewire+) audio device
on CentOS 7 which operates at a sample rate of 48kHz and a bit depth of
either 16 or 32. As far as I can see, the sample rate and format
detection on the Jack side looks correct. I'm therefore looking for some
guidance on how to further debug this, I most certainly missed something
obvious.
I've also tried to play an mp3 file via mpg123 over jack (without the
involvement of the Alsa device) and record it again with jackrec. This
works and sounds correct.
Here is what I've tried and what the environment looks like:
# Capabilities of the Axia-ALSA device
arecord -D hw:0 --dump-hw-params
Recording WAVE 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:0":
--------------------
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S16_LE S32_LE
SUBFORMAT: STD
SAMPLE_BITS: [16 32]
FRAME_BITS: [16 256]
CHANNELS: [1 8]
RATE: 48000
PERIOD_TIME: (41 1365334)
PERIOD_SIZE: [2 65536]
PERIOD_BYTES: [64 131072]
PERIODS: [1 1024]
BUFFER_TIME: (41 1365334)
BUFFER_SIZE: [2 65536]
BUFFER_BYTES: [64 131072]
TICK_TIME: ALL
--------------------
arecord: set_params:1299: Sample format non available
Available formats:
- S16_LE
- S32_LE
# Capture via arecord directly from the ALSA device (without jackd)
# This works as expected and the WAV file sounds fine
arecord -D hw:0 -c 2 -d 10 -r 48000 -f S32_LE -v /tmp/test-arecord.wav
Recording WAVE '/tmp/test-arecord.wav' : Signed 32 bit Little Endian,
Rate 48000 Hz, Stereo
Hardware PCM card 0 'Axia' device 0 subdevice 0
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : S32_LE
subformat : STD
channels : 2
rate : 48000
exact rate : 48000 (48000/1)
msbits : 32
buffer_size : 16384
period_size : 4096
period_time : 85333
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 4096
period_event : 0
start_threshold : 1
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 4611686018427387904
appl_ptr : 0
hw_ptr : 0
# playing arecord wav (via my local notebook's HDA Intel PCH
# device), sounds correct
aplay test-arecord.wav
Playing WAVE 'test-arecord.wav' : Signed 32 bit Little Endian, Rate
48000 Hz, Stereo
# Starting jackd
# Verbose output at: https://pastebin.com/YzHEGSnR
jackd -d alsa -d hw:0
jackdmp 1.9.12
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2017 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
no message buffer overruns
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 20
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init
Acquire audio card Audio0
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback
# Capture via jackrec
# This results in a too high pitched WAV file
# Verbose output at: https://pastebin.com/PCnymKLA
jackrec -f /tmp/test-jackrec.wav -d 10 -b 32 system:capture_1
system:capture_2
# playing jackrec wav (via my local notebook's HDA Intel PCH
# device), sounds incorrect
aplay test-jackrec.wav
Playing WAVE 'test-jackrec.wav' : Signed 32 bit Little Endian, Rate
48000 Hz, Stereo
System environment:
Distribution: CentOS 7.4.1708
Kernel: 3.10.0-693.17.1.el7.x86_64
ALSA Utils: 1.1.3
Jackd: 1.9.12
The jackd was rebuilt from Fedora source RPM to be able to test with the
latest version:
https://build.opensuse.org/package/show/home:radiorabe:audio/jack-audio-con…
Many thanks and best regards
Chris
30 Jan
30 Jan
5:09 a.m.
Hi Chris,
this sounds like a SR mismatch but it's not obvious.
before you debug more, can you try to record with
https://github.com/kmatheussen/jack_capture ?
A simple test is to connect system:capture to system:playback and see if
you get what's expected on your headphone/speakers. You can then go on to
see if jack_capture solves the issue for you.
Greetings
Thomas
On Tue, January 30, 2018 12:35, Christian Affolter wrote:
Hi everyone,
capturing from ALSA capture devices via the Jack2 sound server (1.9.12),
results in too high pitched wav files (they are playing "too fast" and
sound like the "chipmunks"). If I run the same capture directly from the
ALSA devices (without Jack involved), everything sounds as expected
without any problems.
Audio examples:
Capture via jackrec: https://filebin.ca/3pyMxBw8cexQ/test-jackrec.wav
Capture via arecord: https://filebin.ca/3pyOPjcKGym5/test-arecord.wav
The device in question is a "virtual" Axia-ALSA (Livewire+) audio device
on CentOS 7 which operates at a sample rate of 48kHz and a bit depth of
either 16 or 32. As far as I can see, the sample rate and format detection
on the Jack side looks correct. I'm therefore looking for some guidance on
how to further debug this, I most certainly missed something obvious.
I've also tried to play an mp3 file via mpg123 over jack (without the
involvement of the Alsa device) and record it again with jackrec. This
works and sounds correct.
Here is what I've tried and what the environment looks like:
# Capabilities of the Axia-ALSA device
arecord -D hw:0 --dump-hw-params
Recording WAVE 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:0":
--------------------
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S16_LE S32_LE
SUBFORMAT: STD
SAMPLE_BITS: [16 32]
FRAME_BITS: [16 256]
CHANNELS: [1 8]
RATE: 48000
PERIOD_TIME: (41 1365334)
PERIOD_SIZE: [2 65536]
PERIOD_BYTES: [64 131072]
PERIODS: [1 1024]
BUFFER_TIME: (41 1365334)
BUFFER_SIZE: [2 65536]
BUFFER_BYTES: [64 131072]
TICK_TIME: ALL
--------------------
arecord: set_params:1299: Sample format non available
Available formats:
- S16_LE
- S32_LE
# Capture via arecord directly from the ALSA device (without jackd)
# This works as expected and the WAV file sounds fine
arecord -D hw:0 -c 2 -d 10 -r 48000 -f S32_LE -v /tmp/test-arecord.wav
Recording WAVE '/tmp/test-arecord.wav' : Signed 32 bit Little Endian,
Rate 48000 Hz, Stereo
Hardware PCM card 0 'Axia' device 0 subdevice 0
Its setup is:
stream : CAPTURE access : RW_INTERLEAVED format : S32_LE
subformat : STD channels : 2 rate : 48000 exact rate :
48000 (48000/1)
msbits : 32 buffer_size : 16384 period_size : 4096 period_time :
85333
tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min
:
4096
period_event : 0 start_threshold : 1 stop_threshold : 16384
silence_threshold: 0
silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr
: 0
# playing arecord wav (via my local notebook's HDA Intel PCH
# device), sounds correct
aplay test-arecord.wav
Playing WAVE 'test-arecord.wav' : Signed 32 bit Little Endian, Rate
48000 Hz, Stereo
# Starting jackd
# Verbose output at: https://pastebin.com/YzHEGSnR
jackd -d alsa -d hw:0
jackdmp 1.9.12 Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2017 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and you
are welcome to redistribute it under certain conditions; see the file
COPYING for details
no message buffer overruns no message buffer overruns no message buffer
overruns JACK server starting in realtime mode with priority 20
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init Acquire audio card Audio0
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2
periods ALSA: final selected sample format for capture: 32bit integer
little-endian ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer
little-endian ALSA: use 2 periods for playback
# Capture via jackrec
# This results in a too high pitched WAV file
# Verbose output at: https://pastebin.com/PCnymKLA
jackrec -f /tmp/test-jackrec.wav -d 10 -b 32 system:capture_1
system:capture_2
# playing jackrec wav (via my local notebook's HDA Intel PCH
# device), sounds incorrect
aplay test-jackrec.wav
Playing WAVE 'test-jackrec.wav' : Signed 32 bit Little Endian, Rate
48000 Hz, Stereo
System environment:
Distribution: CentOS 7.4.1708
Kernel: 3.10.0-693.17.1.el7.x86_64
ALSA Utils: 1.1.3
Jackd: 1.9.12
The jackd was rebuilt from Fedora source RPM to be able to test with the
latest version:
https://build.opensuse.org/package/show/home:radiorabe:audio/jack-audio-c
onnection-kit
Many thanks and best regards
Chris
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
5:38 a.m.
Hi Thomas,
thanks for your reply.
On 30.01.2018 13:09, Thomas Brand wrote:
Hi Chris,
this sounds like a SR mismatch but it's not obvious.
Yes, most likely.
before you debug more, can you try to record with
https://github.com/kmatheussen/jack_capture ?
This results in the same issue. I've started jack_capture with the
following parameters:
jack_capture -b 32 -c 2 -d 10 -fn /tmp/test-jack_capture.wav \
-p system:capture_1 \
-p system:capture_2
The resulting file:
https://filebin.ca/3pykjU8lo2jO/test-jack_capture.wav
A simple test is to connect system:capture to
system:playback and see if
you get what's expected on your headphone/speakers.
Yes, but unfortunately it's a virtual device running on a headless
server without any speakers attached. The playout would go into the
Livewire+ network where I would have to re-capture it from another system.
You can then go on to
see if jack_capture solves the issue for you.
Greetings
Thomas
Thanks,
Chris
On Tue, January 30, 2018 12:35, Christian Affolter wrote:
Hi everyone,
capturing from ALSA capture devices via the Jack2 sound server (1.9.12),
results in too high pitched wav files (they are playing "too fast" and
sound like the "chipmunks"). If I run the same capture directly from the
ALSA devices (without Jack involved), everything sounds as expected
without any problems.
Audio examples:
Capture via jackrec: https://filebin.ca/3pyMxBw8cexQ/test-jackrec.wav
Capture via arecord: https://filebin.ca/3pyOPjcKGym5/test-arecord.wav
The device in question is a "virtual" Axia-ALSA (Livewire+) audio device
on CentOS 7 which operates at a sample rate of 48kHz and a bit depth of
either 16 or 32. As far as I can see, the sample rate and format detection
on the Jack side looks correct. I'm therefore looking for some guidance on
how to further debug this, I most certainly missed something obvious.
I've also tried to play an mp3 file via mpg123 over jack (without the
involvement of the Alsa device) and record it again with jackrec. This
works and sounds correct.
Here is what I've tried and what the environment looks like:
# Capabilities of the Axia-ALSA device
arecord -D hw:0 --dump-hw-params
Recording WAVE 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:0":
--------------------
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S16_LE S32_LE
SUBFORMAT: STD
SAMPLE_BITS: [16 32]
FRAME_BITS: [16 256]
CHANNELS: [1 8]
RATE: 48000
PERIOD_TIME: (41 1365334)
PERIOD_SIZE: [2 65536]
PERIOD_BYTES: [64 131072]
PERIODS: [1 1024]
BUFFER_TIME: (41 1365334)
BUFFER_SIZE: [2 65536]
BUFFER_BYTES: [64 131072]
TICK_TIME: ALL
--------------------
arecord: set_params:1299: Sample format non available
Available formats:
- S16_LE
- S32_LE
# Capture via arecord directly from the ALSA device (without jackd)
# This works as expected and the WAV file sounds fine
arecord -D hw:0 -c 2 -d 10 -r 48000 -f S32_LE -v /tmp/test-arecord.wav
Recording WAVE '/tmp/test-arecord.wav' : Signed 32 bit Little Endian,
Rate 48000 Hz, Stereo
Hardware PCM card 0 'Axia' device 0 subdevice 0
Its setup is:
stream : CAPTURE access : RW_INTERLEAVED format : S32_LE
subformat : STD channels : 2 rate : 48000 exact rate :
48000 (48000/1)
msbits : 32 buffer_size : 16384 period_size : 4096 period_time :
85333
tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min
:
4096
period_event : 0 start_threshold : 1 stop_threshold : 16384
silence_threshold: 0
silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr
: 0
# playing arecord wav (via my local notebook's HDA Intel PCH
# device), sounds correct
aplay test-arecord.wav
Playing WAVE 'test-arecord.wav' : Signed 32 bit Little Endian, Rate
48000 Hz, Stereo
# Starting jackd
# Verbose output at: https://pastebin.com/YzHEGSnR
jackd -d alsa -d hw:0
jackdmp 1.9.12 Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2017 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and you
are welcome to redistribute it under certain conditions; see the file
COPYING for details
no message buffer overruns no message buffer overruns no message buffer
overruns JACK server starting in realtime mode with priority 20
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init Acquire audio card Audio0
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2
periods ALSA: final selected sample format for capture: 32bit integer
little-endian ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer
little-endian ALSA: use 2 periods for playback
# Capture via jackrec
# This results in a too high pitched WAV file
# Verbose output at: https://pastebin.com/PCnymKLA
jackrec -f /tmp/test-jackrec.wav -d 10 -b 32 system:capture_1
system:capture_2
# playing jackrec wav (via my local notebook's HDA Intel PCH
# device), sounds incorrect
aplay test-jackrec.wav
Playing WAVE 'test-jackrec.wav' : Signed 32 bit Little Endian, Rate
48000 Hz, Stereo
System environment:
Distribution: CentOS 7.4.1708
Kernel: 3.10.0-693.17.1.el7.x86_64
ALSA Utils: 1.1.3
Jackd: 1.9.12
The jackd was rebuilt from Fedora source RPM to be able to test with the
latest version:
https://build.opensuse.org/package/show/home:radiorabe:audio/jack-audio-c
onnection-kit
Many thanks and best regards
Chris
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
6:06 a.m.
On Tue, January 30, 2018 13:37, Christian Affolter wrote:
Hi Thomas,
thanks for your reply.
On 30.01.2018 13:09, Thomas Brand wrote:
you can try to run jack with --verbose, maybe it gives another hint.
you can run jack_bufsize to be absolutely sure it runs at the correct SR.
you can play a file in jack, record that and see if it's ok. if that's the
case, most probably jack is running ok.
the alsa device could be the issue. you could try to start a dummy jack
and add the alsa device with alsa_in to see if it makes a difference.
also make sure that you use a vanilla jack (git clone
https://github.com/jackaudio/jack2/) to rule out any other side-effect.
Hi Chris,
this sounds like a SR mismatch but it's not obvious.
Yes, most likely.
before you debug more, can you try to record
with
https://github.com/kmatheussen/jack_capture ?
This results in the same issue. I've started jack_capture with the
following parameters:
jack_capture -b 32 -c 2 -d 10 -fn /tmp/test-jack_capture.wav \ -p
system:capture_1 \
-p system:capture_2
The resulting file:
https://filebin.ca/3pykjU8lo2jO/test-jack_capture.wav
A simple test is to connect system:capture to
system:playback and see
if you get what's expected on your headphone/speakers.
Yes, but unfortunately it's a virtual device running on a headless
server without any speakers attached. The playout would go into the
Livewire+ network where I would have to re-capture it from another
system.
You can then
go on to
see if jack_capture solves the issue for you.
Greetings
Thomas
Thanks,
Chris
On Tue, January 30, 2018 12:35, Christian Affolter wrote:
Hi everyone,
capturing from ALSA capture devices via the Jack2 sound server
(1.9.12),
results in too high pitched wav files (they are playing "too fast" and
sound like the "chipmunks"). If I run the same capture directly from
the ALSA devices (without Jack involved), everything sounds as
expected without any problems.
Audio examples:
Capture via jackrec: https://filebin.ca/3pyMxBw8cexQ/test-jackrec.wav
Capture via arecord: https://filebin.ca/3pyOPjcKGym5/test-arecord.wav
The device in question is a "virtual" Axia-ALSA (Livewire+) audio
device on CentOS 7 which operates at a sample rate of 48kHz and a bit
depth of either 16 or 32. As far as I can see, the sample rate and
format detection on the Jack side looks correct. I'm therefore looking
for some guidance on how to further debug this, I most certainly
missed something obvious.
I've also tried to play an mp3 file via mpg123 over jack (without the
involvement of the Alsa device) and record it again with jackrec.
This
works and sounds correct.
Here is what I've tried and what the environment looks like:
# Capabilities of the Axia-ALSA device
arecord -D hw:0 --dump-hw-params
Recording WAVE 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:0":
--------------------
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S16_LE S32_LE
SUBFORMAT: STD
SAMPLE_BITS: [16 32]
FRAME_BITS: [16 256]
CHANNELS: [1 8]
RATE: 48000
PERIOD_TIME: (41 1365334)
PERIOD_SIZE: [2 65536]
PERIOD_BYTES: [64 131072]
PERIODS: [1 1024]
BUFFER_TIME: (41 1365334)
BUFFER_SIZE: [2 65536]
BUFFER_BYTES: [64 131072]
TICK_TIME: ALL
--------------------
arecord: set_params:1299: Sample format non available
Available formats:
- S16_LE
- S32_LE
# Capture via arecord directly from the ALSA device (without jackd)
# This works as expected and the WAV file sounds fine
arecord -D hw:0 -c 2 -d 10 -r 48000 -f S32_LE -v /tmp/test-arecord.wav
Recording WAVE '/tmp/test-arecord.wav' : Signed 32 bit Little Endian,
Rate 48000 Hz, Stereo
Hardware PCM card 0 'Axia' device 0 subdevice 0
Its setup is:
stream : CAPTURE access : RW_INTERLEAVED format :
S32_LE
subformat : STD channels : 2 rate : 48000 exact rate
:
48000 (48000/1)
msbits : 32 buffer_size : 16384 period_size : 4096 period_time
:
85333
tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1
avail_min
:
4096
period_event : 0 start_threshold : 1 stop_threshold : 16384
silence_threshold: 0
silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0
hw_ptr : 0
# playing arecord wav (via my local notebook's HDA Intel PCH
# device), sounds correct
aplay test-arecord.wav
Playing WAVE 'test-arecord.wav' : Signed 32 bit Little Endian, Rate
48000 Hz, Stereo
# Starting jackd
# Verbose output at: https://pastebin.com/YzHEGSnR
jackd -d alsa -d hw:0
jackdmp 1.9.12 Copyright 2001-2005 Paul Davis and others. Copyright
2004-2016 Grame.
Copyright 2016-2017 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and
you are welcome to redistribute it under certain conditions; see the
file COPYING for details
no message buffer overruns no message buffer overruns no message
buffer overruns JACK server starting in realtime mode with priority 20
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init Acquire audio card Audio0 creating alsa driver
... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2
periods ALSA: final selected sample format for capture: 32bit integer
little-endian ALSA: use 2 periods for capture ALSA: final selected
sample format for playback: 32bit integer little-endian ALSA: use 2
periods for playback
# Capture via jackrec
# This results in a too high pitched WAV file
# Verbose output at: https://pastebin.com/PCnymKLA
jackrec -f /tmp/test-jackrec.wav -d 10 -b 32 system:capture_1
system:capture_2
# playing jackrec wav (via my local notebook's HDA Intel PCH
# device), sounds incorrect
aplay test-jackrec.wav
Playing WAVE 'test-jackrec.wav' : Signed 32 bit Little Endian, Rate
48000 Hz, Stereo
System environment:
Distribution: CentOS 7.4.1708
Kernel: 3.10.0-693.17.1.el7.x86_64
ALSA Utils: 1.1.3
Jackd: 1.9.12
The jackd was rebuilt from Fedora source RPM to be able to test with
the latest version:
https://build.opensuse.org/package/show/home:radiorabe:audio/jack-aud
io-c onnection-kit
Many thanks and best regards
Chris
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
8:23 a.m.
Hi Thomas,
On 30.01.2018 14:05, Thomas Brand wrote:
you can try to run jack with --verbose, maybe it gives another hint.
I did that already, see the pastbin links below:
this sounds like a SR mismatch but it's not
obvious.
Yes, most likely.
before you debug more, can you try to record
with
https://github.com/kmatheussen/jack_capture ?
This results in the same issue. I've started jack_capture with the
following parameters:
jack_capture -b 32 -c 2 -d 10 -fn /tmp/test-jack_capture.wav \ -p
system:capture_1 \
-p system:capture_2
The resulting file:
https://filebin.ca/3pykjU8lo2jO/test-jack_capture.wav
A simple test is to connect system:capture to
system:playback and see
if you get what's expected on your headphone/speakers.
Yes, but unfortunately it's a virtual device running on a headless
server without any speakers attached. The playout would go into the
Livewire+ network where I would have to re-capture it from another
system.
>>>> # Starting jackd
>>>> # Verbose output at: https://pastebin.com/YzHEGSnR
>>>> jackd -d alsa -d hw:0
>>>>> # Capture via jackrec
>>>>> # This results in a too high pitched WAV file
>>>>> # Verbose output at: https://pastebin.com/PCnymKLA
you can run jack_bufsize to be absolutely sure it runs
at the correct SR.
jack_bufsize
buffer size = 1024 sample rate = 48000
you can play a file in jack, record that and see if
it's ok. if that's the
case, most probably jack is running ok.
I did that with mpg123, which works correctly (see below)
>>>> I've also tried to play an mp3
file via mpg123 over jack (without the
>>>> involvement of the Alsa device) and record it again with jackrec.
>>>> This works and sounds correct.
the alsa device could be the issue. you could try to
start a dummy jack
and add the alsa device with alsa_in to see if it makes a difference.
also make sure that you use a vanilla jack (git clone
https://github.com/jackaudio/jack2/) to rule out any other side-effect.
OK, I will compile from source later an re-run the captures.
Thanks again
Chris
On Tue, January 30, 2018 12:35, Christian Affolter
wrote:
Hi everyone,
capturing from ALSA capture devices via the Jack2 sound server
(1.9.12),
results in too high pitched wav files (they are playing "too fast" and
sound like the "chipmunks"). If I run the same capture directly from
the ALSA devices (without Jack involved), everything sounds as
expected without any problems.
Audio examples:
Capture via jackrec: https://filebin.ca/3pyMxBw8cexQ/test-jackrec.wav
Capture via arecord: https://filebin.ca/3pyOPjcKGym5/test-arecord.wav
The device in question is a "virtual" Axia-ALSA (Livewire+) audio
device on CentOS 7 which operates at a sample rate of 48kHz and a bit
depth of either 16 or 32. As far as I can see, the sample rate and
format detection on the Jack side looks correct. I'm therefore looking
for some guidance on how to further debug this, I most certainly
missed something obvious.
I've also tried to play an mp3 file via mpg123 over jack (without the
involvement of the Alsa device) and record it again with jackrec.
This
works and sounds correct.
Here is what I've tried and what the environment looks like:
# Capabilities of the Axia-ALSA device
arecord -D hw:0 --dump-hw-params
Recording WAVE 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:0":
--------------------
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S16_LE S32_LE
SUBFORMAT: STD
SAMPLE_BITS: [16 32]
FRAME_BITS: [16 256]
CHANNELS: [1 8]
RATE: 48000
PERIOD_TIME: (41 1365334)
PERIOD_SIZE: [2 65536]
PERIOD_BYTES: [64 131072]
PERIODS: [1 1024]
BUFFER_TIME: (41 1365334)
BUFFER_SIZE: [2 65536]
BUFFER_BYTES: [64 131072]
TICK_TIME: ALL
--------------------
arecord: set_params:1299: Sample format non available
Available formats:
- S16_LE
- S32_LE
# Capture via arecord directly from the ALSA device (without jackd)
# This works as expected and the WAV file sounds fine
arecord -D hw:0 -c 2 -d 10 -r 48000 -f S32_LE -v /tmp/test-arecord.wav
Recording WAVE '/tmp/test-arecord.wav' : Signed 32 bit Little Endian,
Rate 48000 Hz, Stereo
Hardware PCM card 0 'Axia' device 0 subdevice 0
Its setup is:
stream : CAPTURE access : RW_INTERLEAVED format :
S32_LE
subformat : STD channels : 2 rate : 48000 exact rate
:
48000 (48000/1)
msbits : 32 buffer_size : 16384 period_size : 4096 period_time
:
85333
tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1
avail_min
:
4096
period_event : 0 start_threshold : 1 stop_threshold : 16384
silence_threshold: 0
silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0
hw_ptr : 0
# playing arecord wav (via my local notebook's HDA Intel PCH
# device), sounds correct
aplay test-arecord.wav
Playing WAVE 'test-arecord.wav' : Signed 32 bit Little Endian, Rate
48000 Hz, Stereo
# Starting jackd
# Verbose output at: https://pastebin.com/YzHEGSnR
jackd -d alsa -d hw:0
jackdmp 1.9.12 Copyright 2001-2005 Paul Davis and others. Copyright
2004-2016 Grame.
Copyright 2016-2017 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and
you are welcome to redistribute it under certain conditions; see the
file COPYING for details
no message buffer overruns no message buffer overruns no message
buffer overruns JACK server starting in realtime mode with priority 20
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init Acquire audio card Audio0 creating alsa driver
... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2
periods ALSA: final selected sample format for capture: 32bit integer
little-endian ALSA: use 2 periods for capture ALSA: final selected
sample format for playback: 32bit integer little-endian ALSA: use 2
periods for playback
# Capture via jackrec
# This results in a too high pitched WAV file
# Verbose output at: https://pastebin.com/PCnymKLA
jackrec -f /tmp/test-jackrec.wav -d 10 -b 32 system:capture_1
system:capture_2
# playing jackrec wav (via my local notebook's HDA Intel PCH
# device), sounds incorrect
aplay test-jackrec.wav
Playing WAVE 'test-jackrec.wav' : Signed 32 bit Little Endian, Rate
48000 Hz, Stereo
System environment:
Distribution: CentOS 7.4.1708
Kernel: 3.10.0-693.17.1.el7.x86_64
ALSA Utils: 1.1.3
Jackd: 1.9.12
The jackd was rebuilt from Fedora source RPM to be able to test with
the latest version:
https://build.opensuse.org/package/show/home:radiorabe:audio/jack-aud
io-c onnection-kit
Many thanks and best regards
Chris
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
8:52 a.m.
On Tue, January 30, 2018 16:23, Christian Affolter wrote:
this looks normal so far ..
as expected ..
Hi Thomas,
>> Yes, but unfortunately it's a virtual device running on a headless
>> server without any speakers attached. The playout would go into the
>> Livewire+ network where I would have to re-capture it from another
>> system.
If you try that it will help to rule out to be an issue of any jack client.
you can try to run jack with --verbose, maybe it gives another hint.
I did that already, see the pastbin links below:
>>>> # Starting jackd
>>>> # Verbose output at: https://pastebin.com/YzHEGSnR
>>>> jackd -d alsa -d hw:0
>>>>>> # Capture via jackrec
>>>>>> # This results in a too high pitched WAV file
>>>>>> # Verbose output at: https://pastebin.com/PCnymKLA
>>>>>> you can run jack_bufsize to be absolutely sure it
runs at the correct
SR.
jack_bufsize buffer size = 1024 sample rate = 48000
the alsa
device could be the issue. you could try to start a dummy jack
and add the alsa device with alsa_in to see if it makes a difference.
also make sure that you use a vanilla jack (git clone
https://github.com/jackaudio/jack2/) to rule out any other side-effect.
OK, I will compile from source later an re-run the captures.
Thanks again
Chris
10:15 a.m.
On 30.01.2018 16:23, Christian Affolter wrote:
Just a short update: I've built and run jack2 from Git master (a5e6585)
and face the same issue.
Regards,
Chris
the alsa
device could be the issue. you could try to start a dummy jack
and add the alsa device with alsa_in to see if it makes a difference.
also make sure that you use a vanilla jack (git clone
https://github.com/jackaudio/jack2/) to rule out any other side-effect.
OK, I will compile from source later an re-run the captures.
11:46 a.m.
Hi Thomas,
On 30.01.2018 18:15, Christian Affolter wrote:
On 30.01.2018 16:23, Christian Affolter wrote:
>> the alsa device could be the issue. you could try to start a dummy jack
>> and add the alsa device with alsa_in to see if it makes a difference.
This seems to work, the audio gets captured (and can be played)
correctly. Here is what I did:
# Start jackd with the dummy backend
jackd -d dummy
# Add the alsa device via alsa_in
alsa_in -d hw:0 -c 2
# Capture via jack_capture
jack_capture -b 32 -c 2 -d 10 -fn /tmp/test-jack_capture.wav \
-p alsa_in:capture_1 -p alsa_in:capture_2
# Capture via jackrec
jackrec -f /tmp/test-jackrec.wav -d 10 -b 32 alsa_in:capture_1
alsa_in:capture_2
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)
So I guess we're one step closer.
Thanks a lot for your help
Chris
12:35 p.m.
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.
--
Chris Caudle
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.
7:49 p.m.
On Tue, January 30, 2018 1:52 pm, Kjetil Matheussen wrote:
It seems more likely like jack doesn't call the
process callback as
often as it should.
The most likely cause for that would seem to be driver does not interrupt
as frequently as jackd expects. A driver for a typical bus connected
audio device would interrupt whenever there were enough audio samples to
fill one buffer.
Do you have source for the LiveWire driver? I think someone mentioned it
was a closed binary, is that correct?
--
Chris Caudle
31 Jan
31 Jan
3:29 a.m.
On 31.01.2018 03:49, Chris Caudle wrote:
On Tue, January 30, 2018 1:52 pm, Kjetil Matheussen
wrote:
Yes, it's a proprietary driver and I don't have access to the source
code. I could contact the vendor and ask if they observed the same or a
similar issue already.
However, I'm wondering what arecord and jackd-dummy/alsa_in are doing
different compared to jackd-alsa.
Regards,
Chris
It seems more likely like jack doesn't call
the process callback as
often as it should.
The most likely cause for that would seem to be driver does not interrupt
as frequently as jackd expects. A driver for a typical bus connected
audio device would interrupt whenever there were enough audio samples to
fill one buffer.
Do you have source for the LiveWire driver? I think someone mentioned it
was a closed binary, is that correct?
3:42 a.m.
On Wed, Jan 31, 2018 at 11:29 AM, Christian Affolter <
c.affolter(a)purplehaze.ch> wrote:
Yes, it's a proprietary driver and I don't have access to the source
code. I could contact the vendor and ask if they observed the same or a
similar issue already.
However, I'm wondering what arecord and jackd-dummy/alsa_in are doing
different compared to jackd-alsa.
Sorry if this is not relevant (I'm not quite following what's happening),
but could
it be that the difference can be explained by different alsa paremeters set
by arecord and jack? Have you tried to run "arecord -L" and find the most
low-level device to record from (which jack probably uses).
For instance by running something like "arecord -D iec958:CARD=M2496,DEV=0"
(my soundcard).
If that is the case, then it's probably the default alsa device that does
something magic
when accessing a more low-level device.
3:45 a.m.
On Wed, Jan 31, 2018 at 11:42 AM, Kjetil Matheussen <
k.s.matheussen(a)gmail.com> wrote:
If that is the case, then it's probably the default alsa device that does
something magic
when accessing a more low-level device.
Sorry, some words were lost there. By "if that is the case", I meant if
you
get the same result with arecord now as you get when recording via jack.
7:08 a.m.
On 31.01.2018 11:42, Kjetil Matheussen wrote:
On Wed, Jan 31, 2018 at 11:29 AM, Christian Affolter
<c.affolter(a)purplehaze.ch <mailto:c.affolter@purplehaze.ch>> wrote:
Yes, it's a proprietary driver and I don't have access to the source
code. I could contact the vendor and ask if they observed the same or a
similar issue already.
However, I'm wondering what arecord and jackd-dummy/alsa_in are doing
different compared to jackd-alsa.
Sorry if this is not relevant (I'm not quite following what's
happening), but could
it be that the difference can be explained by different alsa paremeters set
by arecord and jack? Have you tried to run "arecord -L" and find the most
low-level device to record from (which jack probably uses).
For instance by running something like "arecord -D iec958:CARD=M2496,DEV=0"
(my soundcard).
If that is the case, then it's probably the default alsa device that
does something magic
when accessing a more low-level device.
I ran both, arecord and jackd with hw:0 initially. I re-ran the capture
again with "arecord -D default:CARD=Axia ...", which didn't make any
difference (the recording sounds correct).
For the record, here is the ALSA capture PCM and device list:
arecord -L
null
Discard all samples (playback) or generate zero samples (capture)
default:CARD=Axia
Axia, Axia PCM
Default Audio Device
sysdefault:CARD=Axia
Axia, Axia PCM
Default Audio Device
arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: Axia [Axia], device 0: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 1: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 2: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 3: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 4: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 5: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 6: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 7: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 8: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 9: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 10: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 11: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 12: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 13: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 14: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 15: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 16: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 17: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 18: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 19: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 20: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 21: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 22: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Axia [Axia], device 23: Axia PCM [Axia PCM]
Subdevices: 1/1
Subdevice #0: subdevice #0
7:20 a.m.
On Wed, Jan 31, 2018 at 3:08 PM, Christian Affolter <
c.affolter(a)purplehaze.ch> wrote:
On 31.01.2018 11:42, Kjetil Matheussen wrote:
Maybe jack will work if you give it the same parameters that arecord uses.
I.e. compare
the content of /proc/asound/card0/pcm0p/sub0/hw_params (or a similarly
named file)
when running arecord and when running jack.
Also, maybe it works to record in jack if you change audio from "duplex" to
"capture only".
On Wed, Jan 31, 2018 at 11:29 AM, Christian
Affolter
<c.affolter(a)purplehaze.ch <mailto:c.affolter@purplehaze.ch>> wrote:
Yes, it's a proprietary driver and I don't have access to the source
code. I could contact the vendor and ask if they observed the same
or a
similar issue already.
However, I'm wondering what arecord and jackd-dummy/alsa_in are doing
different compared to jackd-alsa.
Sorry if this is not relevant (I'm not quite following what's
happening), but could
it be that the difference can be explained by different alsa paremeters
set
by arecord and jack? Have you tried to run
"arecord -L" and find the most
low-level device to record from (which jack probably uses).
For instance by running something like "arecord -D
iec958:CARD=M2496,DEV=0"
(my soundcard).
If that is the case, then it's probably the default alsa device that
does something magic
when accessing a more low-level device.
I ran both, arecord and jackd with hw:0 initially. I re-ran the capture
again with "arecord -D default:CARD=Axia ...", which didn't make any
difference (the recording sounds correct).
For the record, here is the ALSA capture PCM and device list:
7:55 a.m.
On 31.01.2018 15:20, Kjetil Matheussen wrote:
On Wed, Jan 31, 2018 at 3:08 PM, Christian Affolter
<c.affolter(a)purplehaze.ch <mailto:c.affolter@purplehaze.ch>> wrote:
On 31.01.2018 11:42, Kjetil Matheussen wrote:
BINGO and thank you so much for this pointer!
If I start jackd in capture-only mode with only two channels, the
capturing finally works as expected:
jackd -d alsa -d hw:0 -C -i 2
Interestingly, the different period size of 4096 vs. 1024 doesn't seems
to have any impact (I first tried to run with -p 4096 as well).
Below are the HW parameters of the ALSA device, during different states.
# hw_params during arecord
cat /proc/asound/card0/pcm0c/sub0/hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 4096
buffer_size: 16384
# hw_params during jackd -d alsa -d hw:0
# jackd -d alsa
cat /proc/asound/card0/pcm0c/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 8
rate: 48000 (48000/1)
period_size: 1024
buffer_size: 2048
# hw_params during jackd -d alsa -d hw:0 -C -i 2
cat /proc/asound/card0/pcm0c/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 1024
buffer_size: 2048
Thank you everyone for your valuable help!
Chris
On Wed, Jan 31, 2018 at 11:29 AM, Christian
Affolter
<c.affolter(a)purplehaze.ch <mailto:c.affolter@purplehaze.ch>
<mailto:c.affolter@purplehaze.ch <mailto:c.affolter@purplehaze.ch>>>
wrote:
Yes, it's a proprietary driver and I don't have access to the source
code. I could contact the vendor and ask if they observed the same or a
similar issue already.
However, I'm wondering what arecord and jackd-dummy/alsa_in are doing
different compared to jackd-alsa.
Sorry if this is not relevant (I'm not quite following what's
happening), but could
it be that the difference can be explained by different alsa paremeters set
by arecord and jack? Have you tried to run "arecord -L" and find the most
low-level device to record from (which jack probably uses).
For instance by running something like "arecord -D iec958:CARD=M2496,DEV=0"
(my soundcard).
If that is the case, then it's probably the default alsa device that
does something magic
when accessing a more low-level device.
I ran both, arecord and jackd with hw:0 initially. I re-ran the capture
again with "arecord -D default:CARD=Axia ...", which didn't make any
difference (the recording sounds correct).
For the record, here is the ALSA capture PCM and device list:
Maybe jack will work if you give it the same parameters that arecord
uses. I.e. compare
the content of /proc/asound/card0/pcm0p/sub0/hw_params (or a similarly
named file)
when running arecord and when running jack.
Also, maybe it works to record in jack if you change audio from "duplex"
to "capture only".
1:23 p.m.
On Wed, January 31, 2018 15:55, Christian Affolter wrote:
On 31.01.2018 15:20, Kjetil Matheussen wrote:
Maybe jack will work if you give it the same
parameters that arecord
uses. I.e. compare the content of
/proc/asound/card0/pcm0p/sub0/hw_params (or a similarly
named file) when running arecord and when running jack.
Also, maybe it works to record in jack if you change audio from
"duplex"
to "capture only".
BINGO and thank you so much for this pointer!
# hw_params during jackd -d alsa -d hw:0
# jackd -d alsa
cat /proc/asound/card0/pcm0c/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 8
rate: 48000 (48000/1)
period_size: 1024
buffer_size: 2048
What i wonder is did you see 8 JACK system:capture ports with the above
configuration? It's still confusing that JACK would attach the device
differently. The factor 4 can probably be explained by 8 / 2 channels (?)
or has it do with duplex?.
It could be that the record just took every 4th sample. But why?
For future reference, this could be issued on github with these detailed
debug informations. It's possible that JACK can't do anything about it if
it's driver related. So.. up to you.
# hw_params during jackd -d alsa -d hw:0 -C -i 2
cat /proc/asound/card0/pcm0c/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 1024
buffer_size: 2048
2 Feb
2 Feb
6:18 a.m.
On 31.01.2018 21:22, Thomas Brand wrote:
On Wed, January 31, 2018 15:55, Christian Affolter
wrote:
yes, there are 8 ports available:
jack_lsp -c -t
system:capture_1
32 bit float mono audio
[...]
system:capture_8
32 bit float mono audio
system:playback_1
32 bit float mono audio
[...]
system:playback_8
32 bit float mono audio
On 31.01.2018 15:20, Kjetil Matheussen wrote:
Maybe jack will work if you give it the same
parameters that arecord
uses. I.e. compare the content of
/proc/asound/card0/pcm0p/sub0/hw_params (or a similarly
named file) when running arecord and when running jack.
Also, maybe it works to record in jack if you change audio from
"duplex"
to "capture only".
BINGO and thank you so much for this pointer!
# hw_params during jackd -d alsa -d hw:0
# jackd -d alsa
cat /proc/asound/card0/pcm0c/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 8
rate: 48000 (48000/1)
period_size: 1024
buffer_size: 2048
What i wonder is did you see 8 JACK system:capture ports with the above
configuration? It's still confusing that JACK would attach the
device
differently. The factor 4 can probably be explained by 8 / 2 channels (?)
or has it do with duplex?.
It could be that the record just took every 4th sample. But why?
I guess it has something to do with the fact, that I only have the first
Livewire+ Destination on the Axia-ALSA driver configured (which equals
to the first two system capture ports in jackd) to actually receive RTP
streams from the Livewire+ network. The other 3 stereo Livewire
Destinations (6 system capture channels) are not configured. However,
this is just a speculation and I would have to verify that, by
configuring more than one Livewire destinations.
But anyway, it's a pretty unexpected recording behaviour. Either the
driver shouldn't block (or whatever it's doing) or jackd would need a
way to detect that only two of the ports are actually working, which is
most likely outside of jackd's responsibility.
For future reference, this could be issued on github
with these detailed
debug informations. It's possible that JACK can't do anything about it if
it's driver related. So.. up to you.
I can do this, if anyone thinks that this issue might be of any help
and/or someone is willing to spend more time to actually debug this
within the jackd source code. On the other hand, it's kind of documented
on the mailing list archive by now for others to find.
> # hw_params during jackd -d alsa -d hw:0 -C -i 2
> cat /proc/asound/card0/pcm0c/sub0/hw_params
>
> access: MMAP_INTERLEAVED
> format: S32_LE
> subformat: STD
> channels: 2
> rate: 48000 (48000/1)
> period_size: 1024
> buffer_size: 2048
Thanks again for your help
Chris
30 Jan
30 Jan
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.
1:01 p.m.
On Tue, January 30, 2018 19:46, Christian Affolter wrote:
Hi Thomas,
On 30.01.2018 18:15, Christian Affolter wrote:
now that's an interesting find .. in theory it should not make a
difference if jack uses alsa backend or if you attach via alsa_in but
obviously it *does* make a difference.
40 seconds is the length when played at 12k.
4 x 8 bit also fit into 32 bit. something is fishy.
On 30.01.2018 16:23, Christian Affolter wrote:
>> the alsa device could be the issue. you could try to start a dummy
>> jack and add the alsa device with alsa_in to see if it makes a
>> difference.
This seems to work, the audio gets captured (and can be played)
correctly. Here is what I did:
# Start jackd with the dummy backend
jackd -d dummy
# Add the alsa device via alsa_in
alsa_in -d hw:0 -c 2
# Capture via jack_capture
jack_capture -b 32 -c 2 -d 10 -fn /tmp/test-jack_capture.wav \ -p
alsa_in:capture_1 -p alsa_in:capture_2
# Capture via jackrec
jackrec -f /tmp/test-jackrec.wav -d 10 -b 32 alsa_in:capture_1
alsa_in:capture_2
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)
So I guess we're one step closer.
Thanks a lot for your help
Chris
7:38 a.m.
Here is a hypothesis: the record software does not correctly handle 32
bits per sample, and stores it as 16 bits per sample at double the rate.
I have tried converting the file with sndfile-convert to 16 and 24 bit
formats, that did not correct the behavior. Maybe I can force some
conversion with SoX. I'll play around with it when I get time to see if
that gives some better idea of what is wrong.
--
Chris Caudle
7:46 a.m.
I think it's not the recording software.
I speculate that the ALSA device is showing the correct information but
indeed delivering something else.
As far as I can see, the driver is closed source. Bump.
Strange that it works with ALSA directly though.
On Tue, January 30, 2018 15:38, Chris Caudle wrote:
Here is a hypothesis: the record software does not
correctly handle 32
bits per sample, and stores it as 16 bits per sample at double the rate.
I have tried converting the file with sndfile-convert to 16 and 24 bit
formats, that did not correct the behavior. Maybe I can force some
conversion with SoX. I'll play around with it when I get time to see if
that gives some better idea of what is wrong.
--
Chris Caudle
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
7:46 a.m.
On Tue, Jan 30, 2018 at 1:37 PM, Christian Affolter <
c.affolter(a)purplehaze.ch> wrote:
Hi Thomas,
thanks for your reply.
On 30.01.2018 13:09, Thomas Brand wrote:
Can you try this?
jack_capture -d 10 -mp3 /tmp/test-jack_capture.mp3 -p system:capture_1 -p
system:capture_2
and (if it worked) this?
jack_capture -d 10 -f ogg /tmp/test-jack_capture.mp3 -p
system:capture_1 -p system:capture_2
If it worked to create mp3, we know that it's got something to do with
using sndfile.
If it worked to create ogg, we know that it's got something to do with
creating wav files with sndfile.
Hi Chris,
this sounds like a SR mismatch but it's not obvious.
Yes, most likely.
before you debug more, can you try to record
with
https://github.com/kmatheussen/jack_capture ?
This results in the same issue. I've started jack_capture with the
following parameters:
jack_capture -b 32 -c 2 -d 10 -fn /tmp/test-jack_capture.wav \
-p system:capture_1 \
-p system:capture_2
The resulting file:
https://filebin.ca/3pykjU8lo2jO/test-jack_capture.wav
7:48 a.m.
On Tue, Jan 30, 2018 at 3:46 PM, Kjetil Matheussen <k.s.matheussen(a)gmail.com
wrote:
>
>
> On Tue, Jan 30, 2018 at 1:37 PM, Christian Affolter <
> c.affolter(a)purplehaze.ch wrote:
>
>> Hi Thomas,
>>
>> thanks for your reply.
>>
>> On 30.01.2018 13:09, Thomas Brand wrote:
>> >
>> > Hi Chris,
>> >
>> > this sounds like a SR mismatch but it's not obvious.
>>
>> Yes, most likely.
>>
>>
>> > before you debug more, can you try to record with
>> > https://github.com/kmatheussen/jack_capture ?
>>
>> This results in the same issue. I've started jack_capture with the
>> following parameters:
>>
>> jack_capture -b 32 -c 2 -d 10 -fn /tmp/test-jack_capture.wav \
>> -p system:capture_1 \
>> -p system:capture_2
>>
>> The resulting file:
>> https://filebin.ca/3pykjU8lo2jO/test-jack_capture.wav
>>
>>
> Can you try this?
>
> jack_capture -d 10 -mp3 /tmp/test-jack_capture.mp3 -p system:capture_1 -p
> system:capture_2
>
> and (if it worked) this?
>
> jack_capture -d 10 -f ogg /tmp/test-jack_capture.mp3 -p
> system:capture_1 -p system:capture_2
>
>
>
Sorry, errors in the commands.
To create mp3:
jack_capture -d 10 -mp3 -p system:capture_1 -p system:capture_2
/tmp/test-jack_capture.mp3
To create ogg:
jack_capture -d 10 -f ogg -p system:capture_1 -p system:capture_2
/tmp/test-jack_capture.ogg
8:32 a.m.
On Tue, January 30, 2018 15:48, Kjetil Matheussen wrote:
To create mp3:
jack_capture -d 10 -mp3 -p system:capture_1 -p system:capture_2
/tmp/test-jack_capture.mp3
To create ogg:
jack_capture -d 10 -f ogg -p system:capture_1 -p system:capture_2
/tmp/test-jack_capture.ogg
interesting approach, leaving out libsndfile... it just came to mind that
jack_capture also has the --write-to-stdout option so one could inspect
raw data.
funnily enough, if the file is played at 12kHz it sounds lo-fi but ok. 12k
is 1/4 of 48k. there is somewhere a factor 4 where it shouldn't be ~
8:32 a.m.
On 30.01.2018 15:48, Kjetil Matheussen wrote:
I've tried that. Both, the mp3 and the ogg file have the same issue.
Thanks,
Chris
before you
debug more, can you try to record with
https://github.com/kmatheussen/jack_capture
<https://github.com/kmatheussen/jack_capture> ?
This results in the same issue. I've started jack_capture with the
following parameters:
jack_capture -b 32 -c 2 -d 10 -fn /tmp/test-jack_capture.wav \
-p system:capture_1 \
-p system:capture_2
The resulting file:
https://filebin.ca/3pykjU8lo2jO/test-jack_capture.wav
<https://filebin.ca/3pykjU8lo2jO/test-jack_capture.wav>
Can you try this?
jack_capture -d 10 -mp3 /tmp/test-jack_capture.mp3 -p
system:capture_1 -p system:capture_2
and (if it worked) this?
jack_capture -d 10 -f ogg /tmp/test-jack_capture.mp3 -p
system:capture_1 -p system:capture_2
Sorry, errors in the commands.
To create mp3:
jack_capture -d 10 -mp3 -p system:capture_1 -p system:capture_2
/tmp/test-jack_capture.mp3
To create ogg:
jack_capture -d 10 -f ogg -p system:capture_1 -p system:capture_2
/tmp/test-jack_capture.ogg
5:27 a.m.
I see a posssible bug in jackrec. Don't know if this is the cause though:
diff --git a/example-clients/capture_client.c
b/example-clients/capture_client.c
index d3360b4..da11fd8 100644
--- a/example-clients/capture_client.c
+++ b/example-clients/capture_client.c
@@ -167,7 +167,7 @@ jack_shutdown (void *arg)
static void
setup_disk_thread (jack_thread_info_t *info)
{
- SF_INFO sf_info;
+ SF_INFO sf_info = {0}
int short_mask;
On Tue, Jan 30, 2018 at 12:35 PM, Christian Affolter <
c.affolter(a)purplehaze.ch> wrote:
Hi everyone,
capturing from ALSA capture devices via the Jack2 sound server (1.9.12),
results in too high pitched wav files (they are playing "too fast" and
sound like the "chipmunks"). If I run the same capture directly from the
ALSA devices (without Jack involved), everything sounds as expected
without any problems.
Audio examples:
Capture via jackrec: https://filebin.ca/3pyMxBw8cexQ/test-jackrec.wav
Capture via arecord: https://filebin.ca/3pyOPjcKGym5/test-arecord.wav
The device in question is a "virtual" Axia-ALSA (Livewire+) audio device
on CentOS 7 which operates at a sample rate of 48kHz and a bit depth of
either 16 or 32. As far as I can see, the sample rate and format
detection on the Jack side looks correct. I'm therefore looking for some
guidance on how to further debug this, I most certainly missed something
obvious.
I've also tried to play an mp3 file via mpg123 over jack (without the
involvement of the Alsa device) and record it again with jackrec. This
works and sounds correct.
Here is what I've tried and what the environment looks like:
# Capabilities of the Axia-ALSA device
arecord -D hw:0 --dump-hw-params
Recording WAVE 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:0":
--------------------
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S16_LE S32_LE
SUBFORMAT: STD
SAMPLE_BITS: [16 32]
FRAME_BITS: [16 256]
CHANNELS: [1 8]
RATE: 48000
PERIOD_TIME: (41 1365334)
PERIOD_SIZE: [2 65536]
PERIOD_BYTES: [64 131072]
PERIODS: [1 1024]
BUFFER_TIME: (41 1365334)
BUFFER_SIZE: [2 65536]
BUFFER_BYTES: [64 131072]
TICK_TIME: ALL
--------------------
arecord: set_params:1299: Sample format non available
Available formats:
- S16_LE
- S32_LE
# Capture via arecord directly from the ALSA device (without jackd)
# This works as expected and the WAV file sounds fine
arecord -D hw:0 -c 2 -d 10 -r 48000 -f S32_LE -v /tmp/test-arecord.wav
Recording WAVE '/tmp/test-arecord.wav' : Signed 32 bit Little Endian,
Rate 48000 Hz, Stereo
Hardware PCM card 0 'Axia' device 0 subdevice 0
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : S32_LE
subformat : STD
channels : 2
rate : 48000
exact rate : 48000 (48000/1)
msbits : 32
buffer_size : 16384
period_size : 4096
period_time : 85333
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 4096
period_event : 0
start_threshold : 1
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 4611686018427387904
appl_ptr : 0
hw_ptr : 0
# playing arecord wav (via my local notebook's HDA Intel PCH
# device), sounds correct
aplay test-arecord.wav
Playing WAVE 'test-arecord.wav' : Signed 32 bit Little Endian, Rate
48000 Hz, Stereo
# Starting jackd
# Verbose output at: https://pastebin.com/YzHEGSnR
jackd -d alsa -d hw:0
jackdmp 1.9.12
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2017 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
no message buffer overruns
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 20
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init
Acquire audio card Audio0
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer
little-endian
ALSA: use 2 periods for playback
# Capture via jackrec
# This results in a too high pitched WAV file
# Verbose output at: https://pastebin.com/PCnymKLA
jackrec -f /tmp/test-jackrec.wav -d 10 -b 32 system:capture_1
system:capture_2
# playing jackrec wav (via my local notebook's HDA Intel PCH
# device), sounds incorrect
aplay test-jackrec.wav
Playing WAVE 'test-jackrec.wav' : Signed 32 bit Little Endian, Rate
48000 Hz, Stereo
System environment:
Distribution: CentOS 7.4.1708
Kernel: 3.10.0-693.17.1.el7.x86_64
ALSA Utils: 1.1.3
Jackd: 1.9.12
The jackd was rebuilt from Fedora source RPM to be able to test with the
latest version:
https://build.opensuse.org/package/show/home:radiorabe:
audio/jack-audio-connection-kit
Many thanks and best regards
Chris
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
2514
days inactive
2517
days old
jackaudio@lists.linuxaudio.org
27 comments
4 participants
participants (4)
-
Chris Caudle -
Christian Affolter -
Kjetil Matheussen -
Thomas Brand