Strange behaviours with sound settings and mounting drives

[dreamer]

@m_pav
I opened the case of my PC and I didn't find any bad capacitors. The flat side of all cylinders were truly flat. None of them bulged, not even a little bit.
And, in my case, there was no cross × on the capacitors, but a T.

To be honest, I would be surprised if my problem was hardware related, because Windows 10 on this same PC plays audio normally, without any interruptions. If Windows 10 can do it, then the hardware is capable of playing sound uninterrupted. Then the problem must be with the software.

MX-23 is a pretty unique system because it can boot using two different init/service systems. I see in your Quick System Info that you booted default SysVinit. Since your hardware seems Ok running Windows 10, why not test MX Linux with systemd. In GRUB choose Advanced and boot a kernel in systemd mode.

[atomick]

Ghosts in the Machine: Wow nice find and good purchase. 1st off your running Windows-10 and dual booted with MX-Linux. Versions do not matter its Linux. Give away to being mis-lead.
Its running and its a work horse and your experiencing Ghosted issue with linux booted.

Capacitors should not be mentioned regardless its a RED-Herring, collusion to the issue. If its dead in its tracks and your seeing Blue Smoke ( highly toxic don't ever breath, fan this away immediately ) These described E-type or X-stamped Topped Capacitors are a new but old. The reason for the stamp is "If a capacitor where? and that is Where to pop by
"Brown Outs, Hydro Surges, Metal Staple dropped onto a live mother board or ... would cause a short and usually the circuits of proximity containing any like would/could pop and these types expand or Bubble expand when blown
"Easy to Identify for a trouble shooter" No worry can leave that one alone.

Sound issues, suggest to add your self user name to sound Group IDs. as in open a Terminal Shell like - Xfce4-terminal tap enter couple times see your focus is in this terminal.
add your user name to these groups like

Code: Select all

 sudo usermod -aG audio johndoe 
sudo usermod -aG video johndoe
sudo usermod -aG Pipewire johndoe 

See "if" that may make any glitch changes experienced. Another method Possibly as simple would be click the MX-Application Start select MX-Tools , right there top section is " User Manager "
top right tab is "Group Membership" simple check mark the groups you believe are associated to Video/Audio / Pipewire.
these are all there once click and apply your sudo passwd is required to finalize the change.

if by chance still in your terminal you can also simply tap the enter key couple times just to make habitually sure your operating in this Window then type clear followed by id
id will show all your user group id associations set at install or user account creation. single them out by another command.

Code: Select all

 id | egrep -e "audio|video|pipewire" 

here you may see color selected response on these 3 checks along with the rest of group memberships. See how this may change "Ghost in the Machine"
also view /var/log/syslog and or dmesg also contained in the /var/log this is Device Messaging and here check for Retries or errors detecting devices "especially audio type devices"

[markwiering]

@m_pav
I opened the case of my PC and I didn't find any bad capacitors. The flat side of all cylinders were truly flat. None of them bulged, not even a little bit.
And, in my case, there was no cross × on the capacitors, but a T.

To be honest, I would be surprised if my problem was hardware related, because Windows 10 on this same PC plays audio normally, without any interruptions. If Windows 10 can do it, then the hardware is capable of playing sound uninterrupted. Then the problem must be with the software.

MX-23 is a pretty unique system because it can boot using two different init/service systems. I see in your Quick System Info that you booted default SysVinit. Since your hardware seems Ok running Windows 10, why not test MX Linux with systemd. In GRUB choose Advanced and boot a kernel in systemd mode.

Thank you for the suggestion. I will try this!
I would be surprised if this solved the problem, but I will give it a shot.

Thank you, @atomick!
I will try your steps as soon as I am back behind that computer.

[dreamer]

Thank you for the suggestion. I will try this!
I would be surprised if this solved the problem, but I will give it a shot.

Also create a new user in MX User Manager and see if that user has the same problems. Maybe the config files in the home folder of your current user are corrupt in some way.

[j2mcgreg]

I think that you should try an earlier kernel IE one that was current to when your machine was made : either the AntiX 5.10 or the 4.19. Both are available via MXPI.

[m_pav]

If Windows 10 can do it, then the hardware is capable of playing sound uninterrupted. Then the problem must be with the software.

That's a reasonable assumption and it may even be the right one, but we're not finished with the hardware yet. I fix a lot of computers and you'd be surprised to see just how many issues are related to ageing hardware. The next check is your RAM. I see you have 8GB installed and with the age, my reckoning is that's likely to be 2x 4GB, or at a stretch, 4 x 2GB.

My next suggestion is you do a memtest which you can find at the grub screen. This will test each module independently because it runs linearly, so if it finds any faults above the value of your first module, then the fault will be with the next module and so on till it completes, but, you can save some time by simply looking at the RAM modules for yourself to see if they're all of the same type. The ideal scenario is when all modules look identical and appear to be from the same batch. Memory mappings and timings can produce some random faults and mismatched memory modules can be a huge contributor towards machine instability. Memory speed and timings are critical.

I have an old Sony VAIO PC that I truly can not give away. It's got an excellent screen, probably the best thing about it, but, it is very slow to boot, a fresh Windows 10 install with all drivers will take 2M30s to arrive at the Desktop and load a web page with an auto-login and 1M36s to shut down, and enabling fast startup only makes a few seconds difference. By comparison, MX-23.5 KDE takes 31s from cold boot to arrive at the same point, and shutdown is under 10s. However, it was not always this way.

I tried to make a LibreOffice Impress presentation on the machine using MX and discovered the longer I spend in the app, the worse it gets. The machine passes all tests with flying colours, but it is simply not a stable machine at all, not in Windows, nor in MX, and for its age, it has not done that many hours of operational time. I have a firm belief it's the processor in the machine. This machine gets random KDE errors for no reason whatsoever, things just seem to break through regular use, so I have to concede that sooner or later, it will be stripped down to and I'll likely make a TechBench monitor out of the display.