Hi Tanu,
On 2019-11-30 12:02, Tanu Kaskinen wrote:
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.
Thanks for the info. I did figure that out after I sent the email to the
list.
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 misunderstood how the application was selecting the sources and it
already correctly ignores the monitor sources.
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?
I was trying to map to the hw device instead of the monitor but as you
point out above there are a few ways that is the wrong thing to do.
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.
So this was a weird one. The modem and codec are fixed at a 48K sample
rate ( the codec can do other rates but the clocks are currently set for
48k). On the devkit we added an alternate rate of 44.1K to deal with
call audio. Pulse audio was using the alternate rate instead of the
default rate and it was setting up the codec for 44.1K and one of the
rates got set to a sample rate of 47999 Hz
https://source.puri.sm/Librem5/calls/uploads/c6430c76b6a79aae827291e55305d3ec/after_call.sink-inputs
In one of the tests I also saw a rate of 43KHz but I don't seem to have
captured any debug for that one.
Dropping the alternate rate caused pulse audio to use 48K which allowed
the sound to flow through the loopbacks and the latency disappeared at
the same time.
https://source.puri.sm/angus.ainslie/librem5-base/commit/450976adfacf25da79b71b6dd24a5f8643da0873#dd3464357c7325c6a3167bc6243c1a62926ba401
Thanks for your help.
Angus
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
