FE-PI (NXP SGTL5000) Audio codec chip has severe delay at startup #3106
Comments
|
Is this a regression (has it got worse, or has it always been like this)? Have you tried using alsamixer to disable any muting options, power-off delays etc.? It takes a certain amount of time for the circuitry to power on at startup. There is a setting called SMALL_POP, currently enabled by the driver, that slows down the voltage ramp-up from ~200ms to ~400ms, so disabling that would reduce the startup time. But before we consider doing that (or making it optional) you have to ask yourself whether you care about the delay or the lost audio. It should be easy to eliminate the lost audio by adding a delay to the driver, but I think it would be impossible to avoid the wait. |
|
This has always been this way to our knowledge, it has just been quantized
by Tobias, but we have seen it for a long time with this chipset.
We absolutely care about the lost audio as the device is used for emergency
communications (Radio repeater sites) so anything we can do to minimize the
startup delay is greatly desirable. Our application only turns on the
codec when there is sound to play so we catch the missing audio every time
it wakes up, so as you can imagine if you are having a meeting and you miss
the first 1-2 words of each person speaking, it can get really annoying.
In alsamixer, I don't recall seeing anything related to power off delays or
the likes. I haven't been in there recently, but we set everything by
script so if there is a command we can use to force the best behavior we
can easily adapt it.
I would be in favor of exposing the setting as an option that we can set up
in our scripts, in the dtb or in alsa, either is fine as long as we know
how to set it up.
|
Let's avoid the word delay because it is ambiguous. Would you say that you care about lost audio but not about increased latency (<1 second)? (I think the answer is yes, but I want to make certain) |
|
Also, are you willing to build your own kernel to make testing easier? It doesn't take too long on a Pi 3 or 4, and incremental changes after the first build only take a few minutes. There are instructions here if you want to see what is involved: https://www.raspberrypi.org/documentation/linux/kernel/building.md |
|
No noticeable lost audio, but also the latency should be kept to an
absolute minimum (say 200ms). We can adjust the latency some on our
application so I would say set it to the 200ms or 400ms based on the
setting we are talking about using exposing, assuming this is possible. Of
course we want to have the conversation flow naturally so long delays are
to be avoided.
…On Thu, Jul 25, 2019 at 8:45 AM Phil Elwell ***@***.***> wrote:
We absolutely care about the lost audio as the device is used for emergency
communications (Radio repeater sites) so anything we can do to minimize the
startup delay is greatly desirable.
Let's avoid the word delay because it is ambiguous. Would you say that you
care about lost audio but not about increased latency (<1 second)? (I think
the answer is yes, but I want to make certain)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3106?email_source=notifications&email_token=ACPI3DPMTVNKPU7HQHHXXSTQBHDCNA5CNFSM4IGWFHRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2Z4FWI#issuecomment-515097305>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACPI3DOEIDG6JQUNQ4GPCA3QBHDCNANCNFSM4IGWFHRA>
.
--
Daniel Loranger
|
|
I can try to run builds, I have no experience with it, but open to learning
and experimenting
…On Thu, Jul 25, 2019 at 9:01 AM Phil Elwell ***@***.***> wrote:
Also, are you willing to build your own kernel to make testing easier? It
doesn't take too long on a Pi 3 or 4, and incremental changes after the
first build only take a few minutes.
There are instructions here if you want to see what is involved:
https://www.raspberrypi.org/documentation/linux/kernel/building.md
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3106?email_source=notifications&email_token=ACPI3DLIEUIKXXKRRL47ZVTQBHE53A5CNFSM4IGWFHRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2Z5TQQ#issuecomment-515103170>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACPI3DNAT2AVI54O22EX2ELQBHE53ANCNFSM4IGWFHRA>
.
--
Daniel Loranger
|
|
We found a workaround in the application code. Closing this bug report |
Describe the bug
The drivers/etc (unsure where it originates) introduce a severe latency when first starting up the codec
To reproduce
This commentary was generated by Tobias (SM0SVX) over in the SVXLINK github issues area as he was helping to debug the problem we have been seeing.
sm0svx/svxlink#273 (comment)
Expected behaviour
The codec chipset should play audio in a reasonable (few milliseconds) time frame which should be virtually undetectable loss
Actual behaviour
The codec chipset takes over 400ms to start playing audio, which causes detectable lost audio at start-up for our application. Example saying "test 1 2 3 4 5", we actually hear "2 3 4 5" due to the time loss. Once the codec is up and running, it seems to be fine, its just the startup condition
System
Which model of Raspberry Pi? All except Pi 1, 4B, and compute modules have been tested and demonstrate the issue.
Which OS and version (
cat /etc/rpi-issue)?cat /etc/rpi-issue
Raspberry Pi reference 2019-04-08
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, e910bf55ac92e27c6e77043e8995bcb5e0a2d742, stage2
Which firmware version (
vcgencmd version)?vcgencmd version
Mar 27 2019 15:45:53
Copyright (c) 2012 Broadcom
version 2e98b31d18547962e564bdf88e57b3df7085c29b (clean) (release) (start)
Which kernel version (
uname -a)?uname -a
Linux openrepeater 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l GNU/Linux
Logs
N/A
Additional context
N/A
The text was updated successfully, but these errors were encountered: