On Wed, Jan 31, 2018 at 3:08 PM, Christian Affolter <c.affolter@purplehaze.ch> wrote:
On 31.01.2018 11:42, Kjetil Matheussen wrote:
> On Wed, Jan 31, 2018 at 11:29 AM, Christian Affolter
> <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".