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

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Capture problems with jack2 on Axia-Alsa device

Christian Affolter
On 31.01.2018 03:49, Chris Caudle wrote:

> 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?

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
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Capture problems with jack2 on Axia-Alsa device

Kjetil Matheussen-2


On Wed, Jan 31, 2018 at 11:29 AM, Christian Affolter <[hidden email]> 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.




_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Capture problems with jack2 on Axia-Alsa device

Kjetil Matheussen-2


On Wed, Jan 31, 2018 at 11:42 AM, Kjetil Matheussen <[hidden email]> 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.
 


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Capture problems with jack2 on Axia-Alsa device

Christian Affolter
In reply to this post by Kjetil Matheussen-2
On 31.01.2018 11:42, Kjetil Matheussen wrote:

> On Wed, Jan 31, 2018 at 11:29 AM, Christian Affolter
> <[hidden email] <mailto:[hidden email]>> 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



_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Capture problems with jack2 on Axia-Alsa device

Kjetil Matheussen-2


On Wed, Jan 31, 2018 at 3:08 PM, Christian Affolter <[hidden email]> wrote:
On 31.01.2018 11:42, Kjetil Matheussen wrote:
> On Wed, Jan 31, 2018 at 11:29 AM, Christian Affolter
> <[hidden email] <mailto:[hidden email]>> 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".


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Capture problems with jack2 on Axia-Alsa device

Christian Affolter
On 31.01.2018 15:20, Kjetil Matheussen wrote:

> On Wed, Jan 31, 2018 at 3:08 PM, Christian Affolter
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 31.01.2018 11:42, Kjetil Matheussen wrote:
>     > On Wed, Jan 31, 2018 at 11:29 AM, Christian Affolter
>     > <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>>
>     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".

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



_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Capture problems with jack2 on Axia-Alsa device

Thomas Brand
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
>


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Capture problems with jack2 on Axia-Alsa device

Christian Affolter
On 31.01.2018 21:22, Thomas Brand wrote:

> 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?

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



> 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
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
12