Re: Delayed muting of studio speakers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Yeah, I've thought about switching in a different set of speakers, but I love the way these sound!  I have plenty of other sets of PC speakers, but the lack of range on my favorite songs makes it hard to bear :-)  I'm sure I'll give it a try in the fullness of time.


On Tue, Dec 22, 2020 at 11:47 AM Matt Feifarek <matt.feifarek@xxxxxxxxx> wrote:
That'd be something to try; another device plugged into the same analog out, see if the muting behavior persists. Perhaps you thought of that already?

On Tue, Dec 22, 2020 at 12:45 PM Chris Mayes <cmayes@xxxxxxxxxx> wrote:
Speaking of Spotify, I remembered that I'd selected "quiet" for the volume level under Music Quality:


I've switched it to "normal".  This ought to help with the signal level, though I'd still like to find where this minimum signal threshold is being enforced.  It may be in the speakers themselves, especially since the left channel tends to mute before the right.  I've written to the manufacturers, but I've yet to receive a response.

I'll see how well the "normal" volume level does at keeping the cutoff at bay.  If I ever do hear from the manufacturer, I'll send an update.


-Chris Mayes

On Tue, Dec 22, 2020 at 8:57 AM Chris Mayes <cmayes@xxxxxxxxxx> wrote:
Thanks for your help, Arun!

I ran the script, but the before-and-after look nearly identical:

(base) cmayes@ninja:/home/cmayes/Downloads $ diff pulseaudio-active pulseaudio-muted
< cmayes      2315  1.8  0.0 4179804 28436 ?       S<sl Dec21  18:02 /usr/bin/pulseaudio --daemonize=no --log-target=journal
< root       32265  0.0  0.0   3284   812 pts/3    S+   08:30   0:00 grep pulseaudio
> cmayes      2315  1.8  0.0 4179804 28436 ?       S<sl Dec21  17:58 /usr/bin/pulseaudio --daemonize=no --log-target=journal
> root       31674  0.0  0.0   3284   812 pts/3    S+   08:29   0:00 grep pulseaudio
< !!Script ran on: Tue Dec 22 15:30:16 UTC 2020
> !!Script ran on: Tue Dec 22 15:29:20 UTC 2020

I'll give it another go when the audio drops out again, but I doubt it'll be much different.

It might also be worth noting that it's Spotify (Ubuntu Snap v. 43, which contains Spotify version that I'm using when the sound drops out.  I'll try playing other audio sources to see whether they work.


-Chris Mayes

On Mon, Dec 21, 2020 at 7:59 PM Arun Raghavan <arun@xxxxxxxxxxxxxxxx> wrote:
On Sat, 19 Dec 2020, at 2:43 PM, Chris Mayes wrote:
> Hi, everybody!
> It takes me back to have subscribed via Mailman to an email
> distribution list.  I'm generally able to solve my issues via Googling,
> but this one's proven tricky.

Welcome back to the past! :)

> I recently bought a pair of KRK Classic 5
> <> speakers to replace a pair of
> M-Audio Studiophile AV 40
> <> speakers that had
> developed a rapid popping noise in the internal amplifier.  The new
> speakers sound fantastic, but they have an odd spontaneous muting
> issue, at least as configured.
> The issue is that the speakers seem to become muted (first one, then
> the other, usually L->R) after some time of playing without any issues.
>  My provisional solution is to crank the volume past 100%, which
> un-mutes them (though at an unpleasantly loud volume).  This clears up
> the issue, though it usually happens again a few minutes later once
> I've brought the volume back to a reasonable level.
> Based on my Googling, I tried modifying analog-output.conf.common to
> "ignore" volume.  Here's the PCM block:
> [Element PCM]
> switch = on
> volume = ignore
> volume-limit = 2.0
> override-map.1 = all
> override-map.2 = all-left,all-right
> Sadly, this didn't seem to make any difference.  What else might I try?
> I have a passing familiarity with audio concepts, and one difference
> that I noted is that the new speakers have about half of the impedance
> of the old pair (which never had this problem).  Do sound cards use
> impedance to detect the presence of a device?  It's plugged into
> line-out (lime green) on an Asus Xonar SE
> <> (the motherboard (Asus
> PRIME Z390-A) <> had
> the same issue).
> Also, the audio is fed to each speaker separately rather than being fed
> to a single speaker and bridged to the left via speaker cable.  Maybe
> that's a factor?
> The brute-force thing would be to just mark the line-out port as
> "always on" and to skip attempts to detect whether there's a device
> connected.  Can PulseAudio do this?  More elegant solutions are also
> warmly welcomed.

This is pretty odd. Could you run the pa-info script (hopefully it's packaged in your distribution) when the stream is playing fine vs. when it's not playing fine? The idea is to see if any mixer controls or any of the stream/sink volumes have actually changed when this happens, or if something else is going on lower down in the hardware.

-- Arun
pulseaudio-discuss mailing list
pulseaudio-discuss mailing list

pulseaudio-discuss mailing list
pulseaudio-discuss mailing list

[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux