[pulseaudio-discuss] Delayed muting of studio speakers
Matt Feifarek
matt.feifarek at gmail.com
Tue Dec 22 18:46:58 UTC 2020
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 at cmayes.com> wrote:
> Speaking of Spotify, I remembered that I'd selected "quiet" for the volume
> level under Music Quality:
>
> [image: spotify_levels.png]
>
> 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.
>
> Thanks,
>
> -Chris Mayes
>
> On Tue, Dec 22, 2020 at 8:57 AM Chris Mayes <cmayes at cmayes.com> wrote:
>
>> Thanks for your help, Arun!
>>
>> I ran the script, but the before-and-after look nearly identical:
>>
>> (base) cmayes at ninja:/home/cmayes/Downloads $ diff pulseaudio-active
>> pulseaudio-muted
>> 3,4c3,4
>> < 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
>> 769c769
>> < !!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 1.1.46.916.g416cacf1) that I'm using when the
>> sound drops out. I'll try playing other audio sources to see whether they
>> work.
>>
>> Thanks!
>>
>> -Chris Mayes
>>
>>
>> On Mon, Dec 21, 2020 at 7:59 PM Arun Raghavan <arun at arunraghavan.net>
>> 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
>>> > <https://www.krkmusic.com/Classic> speakers to replace a pair of
>>> > M-Audio Studiophile AV 40
>>> > <https://m-audio.com/products/view/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
>>> > <https://www.asus.com/us/Sound-Cards/Xonar-SE/> (the motherboard
>>> (Asus
>>> > PRIME Z390-A) <https://www.asus.com/us/Motherboards/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 at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>>>
>> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20201222/87b21ba4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: spotify_levels.png
Type: image/png
Size: 20119 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20201222/87b21ba4/attachment-0001.png>
More information about the pulseaudio-discuss
mailing list