On Thu, 2019-11-28 at 16:44 -0700, Angus Ainslie wrote:
> Hi,
>
> On the librem5 phone I'm having problems getting the audio routed from
> the modem to the codec.
>
> The modem source is displaying a couple of odd behaviours. Here are the
> modem sources
>
> index: 0
> name: <alsa_output.platform-sound-wwan.stereo-fallback.monitor>
> driver: <module-alsa-card.c>
> flags: DECIBEL_VOLUME LATENCY
> state: SUSPENDED
> suspend cause: IDLE
> priority: 1000
> volume: front-left: 65536 / 100% / 0.00 dB, front-right: 65536
> / 100% / 0.00 dB
> balance 0.00
> base volume: 65536 / 100% / 0.00 dB
> volume steps: 65537
> muted: no
> current latency: 0.00 ms
> max rewind: 0 KiB
> sample spec: s16le 2ch 48000Hz
> channel map: front-left,front-right
> Stereo
> used by: 0
> linked by: 0
> fixed latency: 100.00 ms
> monitor_of: 0
> card: 0 <alsa_card.platform-sound-wwan>
> module: 6
> properties:
> device.description = "Monitor of Built-in Audio Stereo"
> device.class = "monitor"
> alsa.card = "0"
> alsa.card_name = "MODEM"
> alsa.long_card_name = "MODEM"
> device.bus_path = "platform-sound-wwan"
> sysfs.path = "/devices/platform/sound-wwan/sound/card0"
> device.form_factor = "internal"
> device.string = "0"
> module-udev-detect.discovered = "1"
> device.icon_name = "audio-card"
> index: 1
> name: <alsa_input.platform-sound-wwan.stereo-fallback>
> driver: <module-alsa-card.c>
> flags: HARDWARE DECIBEL_VOLUME LATENCY
> state: SUSPENDED
> suspend cause: IDLE
> priority: 9000
> volume: front-left: 65536 / 100% / 0.00 dB, front-right: 65536
> / 100% / 0.00 dB
> balance 0.00
> base volume: 65536 / 100% / 0.00 dB
> volume steps: 65537
> muted: no
> current latency: 0.00 ms
> max rewind: 0 KiB
> sample spec: s16le 2ch 48000Hz
> channel map: front-left,front-right
> Stereo
> used by: 0
> linked by: 1
> fixed latency: 100.00 ms
> card: 0 <alsa_card.platform-sound-wwan>
> module: 6
> properties:
> alsa.resolution_bits = "16"
> device.api = "alsa"
> device.class = "sound"
> alsa.class = "generic"
> alsa.subclass = "generic-mix"
> alsa.name = ""
> alsa.id = "30030000.sai-gtm601 gtm601-0"
> alsa.subdevice = "0"
> alsa.subdevice_name = "subdevice #0"
> alsa.device = "0"
> alsa.card = "0"
> alsa.card_name = "MODEM"
> alsa.long_card_name = "MODEM"
> device.bus_path = "platform-sound-wwan"
> sysfs.path = "/devices/platform/sound-wwan/sound/card0"
> device.form_factor = "internal"
> device.string = "hw:0"
> device.buffering.buffer_size = "19200"
> device.buffering.fragment_size = "4800"
> device.access_mode = "mmap"
> device.profile.name = "stereo-fallback"
> device.profile.description = "Stereo"
> device.description = "Built-in Audio Stereo"
> module-udev-detect.discovered = "1"
> device.icon_name = "audio-card"
> ports:
> analog-input: Analog Input (priority 10000, latency
> offset 0 usec, available: unknown)
> properties:
>
> active port: <analog-input>
>
> If I use parecord to record from alsa_card.platform-sound-wwan I get the
> audio from the modem.
>
> If I use parecord to record from
> alsa_output.platform-sound-wwan.stereo-fallback.monitor I don't get any
> audio from the call until it disconnects.
You apparently solved your routing problem already, but are you aware
that that the monitor source captures everything that is played to the
"alsa_output.platform-sound-wwan.stereo-fallback" sink, nothing more,
nothing less? So if the modem audio isn't playing to the sink, it's
expected that there's no audio from the monitor source.
> Our application is grabbing the first source from alsa.card_name =
> "MODEM" and is showing the same behaviour as parecord.
>
> Is there a way to disable the monitor source or possibly reorder the
> sources ?
Why not just fix the source selection logic in your application? Like
ignore monitor sources or something. Monitor sources can't be disabled,
and sources are listed in the order they are created.
> I tried remapping the source and sink but I can't record from that
> either.
>
> load-module module-remap-source source_name=Modem
> master=alsa_input.platform-sound-wwan.stereo-fallback
> load-module module-remap-sink sink_name=Modem
> master=alsa_output.platform-sound-wwan.stereo-fallback
Do you still have these remap devices? What are they trying to achieve?
> The modem sink is passing audio so that's good. The issue with the sink
> is there is about 3 seconds of latency. I can see ~1 second of that due
> to the cellular network.
>
> How would I check the latency through pulseaudio ?
I assume you use module-loopback to route the modem audio to the phone
speakers. I use module-loopback to route audio from an electric piano
to the computer speakers (actually just USB sound card input to the
same card's output), so I can explain how I would check the loopback
latency in my case:
$ pactl list source-outputs
Source Output #11
Driver: module-loopback.c
[...]
Buffer Latency: 0 usec
Source Latency: 0 usec
[...]
Properties:
[...]
media.name = "Loopback to PreSonus AudioBox iTwo Analog
Stereo"
[...]
So here we see that I have a recording stream created by module-
loopback with zero latency from the source and zero internal latency.
$ pactl list sink-inputs
Sink Input #959
Driver: module-loopback.c
[...]
Buffer Latency: 12607 usec
Sink Latency: 15778 usec
[...]
Properties:
[...]
media.name = "Loopback from PreSonus AudioBox iTwo
Analog Stereo"
[...]
Here we see that I have a playback stream created by module-loopback
with 15.8 ms latency from the sink and 12.6 ms internal latency. So far
28.4 ms in total.
What these commands don't show is the latency introduced by module-
loopback's internal buffer. The fill level of that buffer is not
currently shown anywhere. However, the module arguments show what total
latency the loopback is trying to achieve:
$ pactl list modules
Module #41
Name: module-loopback
Argument: source=alsa_input.usb-PreSonus_PreSonus_AudioBox_iTwo_AB5C18071273-00.analog-stereo sink=alsa_output.usb-PreSonus_PreSonus_AudioBox_iTwo_AB5C18071273-00.analog-stereo latency_msec=10 adjust_time=0
Usage counter: n/a
Properties:
module.author = "Pierre-Louis Bossart"
module.description = "Loopback from source to sink"
module.version = "13.0-8-gd72a3"
The module is loaded with argument "latency_msec=10", and that target
apparently isn't being met (this is interesting news to me!). 10 ms is
probably unnecessarily low target, since I haven't noticed while
playing that the piano would have too high latency. In any case, since
I care about latency more than avoiding dropouts, I should use the
"max_latency_msec" argument instead (new in PulseAudio 13.0).
"latency_msec" relaxes the initial target if there are buffer
underruns, but "max_latency_msec" sets a hard ceiling for the total
latency.
I hope this helps. 3 seconds of latency sounds weird, because even if
you don't configure any latency with module-loopback, the default
latency isn't that high. The latency handling in module-loopback was
very bad prior to 11.0, but I hope you're not using that old
PulseAudio.
Your modem seems to have a fixed latency of 100 ms (maybe you've set
tched=0?), which sounds a bit high for something that is used for call
audio.
--
Tanu
https://www.patreon.com/tanuk
https://liberapay.com/tanuk
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
