[pulseaudio-discuss] Sound recording/routing issues on Librem5
Angus Ainslie
angus at akkea.ca
Mon Dec 2 15:49:01 UTC 2019
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
More information about the pulseaudio-discuss
mailing list