Hi all,
I have a strange problem with the speaker output, it goes to MUTE after a bit of time that it is not used and if I disable it the output continues to not work.
I try to disable the mute remotely by ssh with the following command:
$ pactl set-sink-mute 0 0
The same issue happens on different Jetsons TK1, so I think that it is a bug in the kernel.
Anyone with the same problem?
Thank you
Walter
Is this the HDMI audio, or is it from the 3.5mm jack? HDMI audio goes through the nVidia video card I use on the desktop…if you use HDMI audio on the Jetson this too is tied to video card hardware (3.5mm jack does not touch the video hardware, but rules for switching sinks may still affect 3.5mm when HDMI changes).
I have not worked on this for a Jetson, but I’ve noticed on my desktop system (which uses nVidia HDMI video) that when the system has sat around long enough and the screen blanks and goes into low power mode return back to full power mode has audio come back up wrong or not at all. Turning the monitor off and back on is a workaround (audio hardware in the video card is hotplug), although this gets complicated with multiple monitors (audio and video seem to determine primary monitor differently and it takes a series of monitor off/on to get both video and audio to the right place). I’m thinking perhaps low power mode for screen blanking is not preserving settings when normal operation is resumed.
I’m not using HDMI since it is an application without an LCD, but I’m logged in Graphig Environment since I’m using CUDA and I need the GPU to be active.
Are you saying that maybe that the problem is related to “monitor standby” after “x” time?
Do you know how I can disable standby by command line?
Thank you
Walter
This is one of those great questions I’ve also wondered. There are GUI applications to deal with standby mode and such, but I don’t know what to tell you for command line. I have a number of low power and standby functions disabled by default (including through rc.local), but the monitor will still blank after a certain time unless I use the GUI app.
The command line tool “gsettings” may be what you want to change some GUI details, but I couldn’t tell you for sure. I use this after an install (this is nothing to do with audio, but I suspect a similar setting exists which the GUI controls work with for standby modes):
gsettings set com.canonical.Unity.Lenses disabled-scopes "['more_suggestions-amazon.scope', 'more_suggestions-u1ms.scope', 'more_suggestions-populartracks.scope', 'music-musicstore.scope', 'more_suggestions-ebay.scope', 'more_suggestions-ubuntushop.scope', 'more_suggestions-skimlinks.scope']"
Just a reminder though, I’m only guessing this is the issue because I’ve noted the time-delay sound changes before and tracked it down to monitor audio thinking the audio was gone when standby mode hits…followed by changing of audio when standby goes away (unfortunately on my multi-monitor setup on the desktop I can’t be sure that going to and from standby enforces the order of monitor startup…the software seems to depend on this, but should not). Every audio sink which gets added or removed from the list of audio devices has a chance to bump other audio sinks out of their expected place…this is one possible place for that to happen if it isn’t a bug in the kernel. I don’t even know for sure that the HDMI audio code would matter when no monitor is attached.
Hi @linuxdev,
I think that the problem is not related to “Display sleep” or any other energy setting.
I’m doing a few tests using a TK1 connected to an HDMI display, I’m sending “white noise” to it on RTP using GStreamer and I’m redirecting the sound to the speaker output.
I made a script that is launched at boot.
Board start → Noise emitted → Mute after less than a minute
Board reboot → Noise emitted → No mute since more than 5 minute
It is really random!!!
Is there a log where I can understand who is setting the mute status?
Thank you
Walter
I noticed another strange fact: when the system goes in MUTE by itself randomly if I try to toggle mute to turn on the speaker output I cannot get any output.
The only way to reactivate the speaker output is to switch Mode from “Analog Stereo Output” to “Analog Mono Output” and back again to “Analog Stereo Output”.
I’m sure that this operation kills the driver and starts it again because “Sink#” for “alsa_output” changes every time you switch from mono to stereo and viceversa.
You can verify this with the command
pactl list sinks
So my conclusion is that the driver for “tegra-snd-rt5639” has a kind of bug that generates this “mute issue”.
I think that I can create a simple software that check for mute and when it turns to ON I restart the sound drive, but I do not really know what I must restart “manually”.
You may have to adjust this for your case, but mixer settings I’ve used in the past can be checked with this (and you might want to check before and after mute failure to compare):
DISPLAY AUDIO SETTINGS:
=======================
amixer cget name="Stereo ADC MIXL ADC2 Switch"
amixer cget name="Stereo ADC MIXR ADC2 Switch"
amixer cget name="Int Mic Switch"
amixer cget name="ADC Capture Switch"
amixer cget name="RECMIXL BST1 Switch"
amixer cget name="RECMIXR BST1 Switch"
amixer cget name="RECMIXL BST2 Switch"
amixer cget name="RECMIXR BST2 Switch"
amixer cget name="Stereo ADC L1 Mux"
amixer cget name="Stereo ADC R1 Mux"
amixer cget name="Stereo ADC MIXL AD1 Switch"
amixer cget name="Stereo ADC MIXR ADC1 Switch"
amixer cget name="Stereo ADC MIXL ADC2 Switch"
amixer cget name="Stereo ADC MIXR ADC2 Switch"
amixer cget name="IN1 Mode Control"
amixer cget name="IN2 Mode Control"
amixer cget name="Mic Jack Switch"
You’ll find more query options with “man amixer”. One of those is to list controls, “amixer scontrols”. Controls may change depending on drivers loaded and devices detected…you might try a complete list of controls while the app runs correctly, and then compare to see if something went away after the problem occurs.
If you specifically have the pulse-audio server being used, then the program to look at pulse-audio is “pactl”. Not everything uses pulse-audio, but if you do use this, try “sudo pactl list” before and after failure (or in this case, during a working playback and after).