31 Jan
2018
31 Jan
'18
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: