Hi, I have a new sound problem. The machine is my previous desktop machine, maybe 10 year old, running a relatively new system with Leap 15.3, and XFCE desktop. I watch movies on it, and the headphones do not work. Sound taken from the line.out output of the sound card goes to the loud speakers, and they work. If I connect the headphones on the front, I hear a very low hiss on them; the loudspeakers go silent, but no actual sound on the headphones. I see on the "audio mixer" gadget that output changes from "line out (plugged in)" to "headphones (plugged in)", so they are detected. But if I take out the jack just slightly, I can get sound on both devices. The mixer tool says that I have just line out. So I get working headphones if I tune down the external volume control on the external speakers. This means that the hardware front jack is actually connected and works, but the software is not working, once it detects the headphones are connected and does something about it. I don't know what info to provide, but here goes what I can think of: Elesar:~ # hwinfo --sound 08: PCI 300.0: 0403 Audio device [Created at pci.386] Unique ID: svHJ.YhraNp3EzIA Parent ID: B35A.Ap1NNKytTd3 SysFS ID: /devices/pci0000:00/0000:00:1c.0/0000:02:00.0/0000:03:00.0 SysFS BusID: 0000:03:00.0 Hardware Class: sound Model: "Creative SB1040 PCI Express" Vendor: pci 0x1102 "Creative Labs" Device: pci 0x0009 "CA0110 [Sound Blaster X-Fi Xtreme Audio]" SubVendor: pci 0x1102 "Creative Labs" SubDevice: pci 0x0018 "SB1040 PCI Express" Driver: "snd_hda_intel" Driver Modules: "snd_hda_intel" Memory Range: 0xfe6fc000-0xfe6fffff (rw,non-prefetchable) IRQ: 16 (17396 events) Module Alias: "pci:v00001102d00000009sv00001102sd00000018bc04sc03i00" Driver Info #0: Driver Status: snd_hda_intel is active Driver Activation Cmd: "modprobe snd_hda_intel" Config Status: cfg=yes, avail=yes, need=no, active=unknown Attached to: #14 (PCI bridge) Elesar:~ # Elesar:~ # inxi --audio --admin Audio: Device-1: Creative Labs CA0110 [Sound Blaster X-Fi Xtreme Audio] driver: snd_hda_intel v: kernel bus ID: 03:00.0 chip ID: 1102:0009 Sound Server: ALSA v: k5.3.18-150300.59.71-default Elesar:~ # -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Hello, In the Message; Subject : [oS-EN] New sound problem Message-ID : <fae953aa-280a-d85e-e7c9-bd5bfe995876@telefonica.net> Date & Time: Mon, 20 Jun 2022 23:42:57 +0200 [CER] == "Carlos E. R." <robin.listas@telefonica.net> has written: CER> Hi, CER> I have a new sound problem. Meaning that it has been working fine until now? CER> The machine is my previous desktop machine, maybe 10 year old, running a CER> relatively new system with Leap 15.3, and XFCE desktop. I watch movies CER> on it, and the headphones do not work. CER> Sound taken from the line.out output of the sound card goes to the loud CER> speakers, and they work. If I connect the headphones on the front, I CER> hear a very low hiss on them; the loudspeakers go silent, but no actual CER> sound on the headphones. I see on the "audio mixer" gadget that output CER> changes from "line out (plugged in)" to "headphones (plugged in)", so CER> they are detected. CER> But if I take out the jack just slightly, I can get sound on both CER> devices. The mixer tool says that I have just line out. So I get working CER> headphones if I tune down the external volume control on the external CER> speakers. CER> This means that the hardware front jack is actually connected and works, CER> but the software is not working, once it detects the headphones are CER> connected and does something about it. Normally, when you connect it to the front jack on the PC, it works with the on-board sound chip, but you are using it wired to the Sound Labs X-Fi Xtreme? But still, Sound Labs X-Fi Xtreme is very old...... Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ "It should never be said that it is OK to ignore the theoretical as long as it becomes a tool." -- T. Mori (The original is in Japanese) --
On 2022-06-21 02:16, Masaru Nomiya wrote:
Hello,
In the Message;
Subject : [oS-EN] New sound problem Message-ID : <fae953aa-280a-d85e-e7c9-bd5bfe995876@telefonica.net> Date & Time: Mon, 20 Jun 2022 23:42:57 +0200
[CER] == "Carlos E. R." <robin.listas@telefonica.net> has written:
CER> Hi,
CER> I have a new sound problem.
Meaning that it has been working fine until now?
No, I don't remember when it started. New because it is become a nuisance just yesterday :-) I had to move the machine to a new position; previously I just plugged the headphones instead of the loudspeaker on the back of the computer. But the cable is so short that I have to sit with my face close to the display, and that is a pain :-(
CER> The machine is my previous desktop machine, maybe 10 year old, running a CER> relatively new system with Leap 15.3, and XFCE desktop. I watch movies CER> on it, and the headphones do not work.
CER> Sound taken from the line.out output of the sound card goes to the loud CER> speakers, and they work. If I connect the headphones on the front, I CER> hear a very low hiss on them; the loudspeakers go silent, but no actual CER> sound on the headphones. I see on the "audio mixer" gadget that output CER> changes from "line out (plugged in)" to "headphones (plugged in)", so CER> they are detected.
CER> But if I take out the jack just slightly, I can get sound on both CER> devices. The mixer tool says that I have just line out. So I get working CER> headphones if I tune down the external volume control on the external CER> speakers.
CER> This means that the hardware front jack is actually connected and works, CER> but the software is not working, once it detects the headphones are CER> connected and does something about it.
Normally, when you connect it to the front jack on the PC, it works with the on-board sound chip, but you are using it wired to the Sound Labs X-Fi Xtreme?
AFAIK there is only one sound hardware, the Sound Labs X-Fi Xtreme card the board came with. Does it have also an on-board sound chip, you think?
But still, Sound Labs X-Fi Xtreme is very old......
Well, yes, the machine is over a decade old. It is my previous desktop machine, I have a newer one back home. I had to put this one back into service from retirement, I have guests :-) The Nvidia card is also a nuisance, can't use the proprietary driver anymore, I use nouveau instead. Suffices. And RAM is limited to 8 GiB by the motherboard. Elesar:~ # inxi --cpu CPU: Topology: Quad Core model: Intel Core2 Quad Q9550 bits: 64 type: MCP L2 cache: 6144 KiB Speed: 2788 MHz min/max: N/A Core speeds (MHz): 1: 2788 2: 2824 3: 2736 4: 2796 Elesar:~ # -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
On 2022-06-21 08:33, Darryl Gregorash wrote:
On 2022-06-21 00:20, Carlos E. R. wrote:
AFAIK there is only one sound hardware, the Sound Labs X-Fi Xtreme card the board came with. Does it have also an on-board sound chip, you think?
YaST/Sound
No, it only shows one card: YaST2 - sound @ Elesar Sound Configuration ┌────────────────────────────────────────────────────────────... │Index│Card Model │ │0 │SB1040 PCI Express │ │ │ -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Hello, In the Message; Subject : Re: [oS-EN] New sound problem Message-ID : <24a323f7-ba0d-2f75-2701-ebc57ad866cb@telefonica.net> Date & Time: Tue, 21 Jun 2022 08:42:44 +0200 [CER] == "Carlos E. R." <robin.listas@telefonica.net> has written: CER> On 2022-06-21 08:33, Darryl Gregorash wrote: DG> > YaST/Sound CER> No, it only shows one card: CER> YaST2 - sound @ Elesar CER> Sound Configuration CER> ┌────────────────────────────────────────────────────────────... CER> │Index│Card Model │ CER> │0 │SB1040 PCI Express │ CER> │ You might have incompatible or broken sound chip, I guess... (_ _? Can you tell me the name of the PC, and if you can figure it out, the name of the M/B? Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ "In the west, from the time of the Ancient Greeks to the modern day ― from Plato in his cave to Aldous Huxley's Brave New World ― the idea that reality has value, no matter how ugly or unpleasant it might be, has been accepted as an article of faith." -- J. Kelly "What Meta's VR advert tells us about life in the metaverse" --
On 21/06/2022 09.43, Masaru Nomiya wrote:
Hello,
You might have incompatible or broken sound chip, I guess... (_ _?
Can you tell me the name of the PC, and if you can figure it out, the name of the M/B?
No brand name.
Elesar:~ # inxi --machine --dmidecode Use of uninitialized value in string eq at /usr/bin/inxi line 10982. Machine: Type: Desktop System: MICRO-STAR product: MS-7516 v: 1.0 serial: N/A Mobo: MICRO-STAR model: MS-7516 serial: N/A BIOS: American Megatrends v: 1.5 rev: 8.15 date: 10/10/2008 Elesar:~ #
EElesar:~ # inxi --machine Machine: Type: Desktop Mobo: MICRO-STAR model: MS-7516 v: 1.0 serial: N/A BIOS: American Megatrends v: 1.5 date: 10/10/2008 Elesar:~ #lesar:~ # inxi --machine Machine: Type: Desktop Mobo: MICRO-STAR model: MS-7516 v: 1.0 serial: N/A BIOS: American Megatrends v: 1.5 date: 10/10/2008 Elesar:~ #
-- Cheers / Saludos, Carlos E. R. (from openSUSE 15.3 (Legolas))
Hello, On Tue, 21 Jun 2022, Carlos E. R. wrote:
On 21/06/2022 09.43, Masaru Nomiya wrote:
Hello,
You might have incompatible or broken sound chip, I guess... (_ _?
Can you tell me the name of the PC, and if you can figure it out, the name of the M/B?
No brand name.
Elesar:~ # inxi --machine --dmidecode Use of uninitialized value in string eq at /usr/bin/inxi line 10982. Machine: Type: Desktop System: MICRO-STAR product: MS-7516 v: 1.0 serial: N/A Mobo: MICRO-STAR model: MS-7516 serial: N/A BIOS: American Megatrends v: 1.5 rev: 8.15 date: 10/10/2008 Elesar:~ #
MSI == MicroStar International, and the MS-* are the actual model names. The sales branding seems to be "P45 Diamond". Here's the specs: https://www.msi.com/Motherboard/P45_Diamond/Specification Nice: 2 x eSATA on the back-I/O ;) HTH, -dnh -- A common mistake that people make, when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -- Douglas Adams - Mostly Harmless
On 22/06/2022 01.50, David Haller wrote:
Hello,
On Tue, 21 Jun 2022, Carlos E. R. wrote:
On 21/06/2022 09.43, Masaru Nomiya wrote:
Hello,
You might have incompatible or broken sound chip, I guess... (_ _?
Can you tell me the name of the PC, and if you can figure it out, the name of the M/B?
No brand name.
Elesar:~ # inxi --machine --dmidecode Use of uninitialized value in string eq at /usr/bin/inxi line 10982. Machine: Type: Desktop System: MICRO-STAR product: MS-7516 v: 1.0 serial: N/A Mobo: MICRO-STAR model: MS-7516 serial: N/A BIOS: American Megatrends v: 1.5 rev: 8.15 date: 10/10/2008 Elesar:~ #
MSI == MicroStar International, and the MS-* are the actual model names. The sales branding seems to be "P45 Diamond". Here's the specs:
Yes, that name is familiar. Nice find, thanks. It came with the audio card in the same box, by the way.
https://www.msi.com/Motherboard/P45_Diamond/Specification
Nice: 2 x eSATA on the back-I/O ;)
Oh, yes. And "many" SATA inside, which some times I used to capacity. Plus an RS232 port, too. My new board has no eSATA, and fewer SATA :-( But still RS232 and a parallel port! -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.3 (Legolas))
Hello, Sorry for late reply. In the Message; Subject : Re: [oS-EN] New sound problem Message-ID : <20220621235042.5skgzhyy5346anij@grusum.dhaller.de> Date & Time: Wed, 22 Jun 2022 01:50:42 +0200 [DH] == David Haller <dnh@opensuse.org> has written: [...] DH> MSI == MicroStar International, and the MS-* are the actual model names. DH> The sales branding seems to be "P45 Diamond". Here's the specs: DH> https://www.msi.com/Motherboard/P45_Diamond/Specification DH> Nice: 2 x eSATA on the back-I/O ;) Thanks, David. I confirmed, the on-board soundchip is Sound Blaster X-Fi Xtreme. But I think about it, the phenomenon that Carlos is describing as a problem is a natural one．Rather, do we ever use a speaker and a headphone at the same time? So, I looked into it, and found that Soundblaster offers a tool for windows that allows we to mute the headphone when using the speaker, and vice versa when using the headphone. https://crates.io/crates/sbz-switch/3.0.0 Regards. --- ┏━━┓彡 野宮 賢 mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ "Tim Cook, the C.E.O. of Apple, said earlier this year that he would not let his nephew join social networks. Bill Gates banned cellphone until his children were teenagers, and Melinda Gates wrote that she wished they had waited even longer. Steve Jobs would not let his young children near iPads." -- The New York Times --
On 2022-06-22 14:26, Masaru Nomiya wrote:
Hello,
Sorry for late reply.
In the Message;
Subject : Re: [oS-EN] New sound problem Message-ID : <20220621235042.5skgzhyy5346anij@grusum.dhaller.de> Date & Time: Wed, 22 Jun 2022 01:50:42 +0200
[DH] == David Haller <dnh@opensuse.org> has written:
[...] DH> MSI == MicroStar International, and the MS-* are the actual model names. DH> The sales branding seems to be "P45 Diamond". Here's the specs:
DH> https://www.msi.com/Motherboard/P45_Diamond/Specification
DH> Nice: 2 x eSATA on the back-I/O ;)
Thanks, David.
I confirmed, the on-board soundchip is Sound Blaster X-Fi Xtreme.
But I think about it, the phenomenon that Carlos is describing as a problem is a natural one．Rather, do we ever use a speaker and a headphone at the same time?
So, I looked into it, and found that Soundblaster offers a tool for windows that allows we to mute the headphone when using the speaker, and vice versa when using the headphone.
And that is what is not working correctly in Linux (I don't have Windows to try). When I plug in the headphones at the front, the loudspeakers should mute, and the headphones should work. This doesn't happen. The loudspeakers go mute (correct), and the headphones play no sound (incorrect). If I pull the jack half a millimeter, the "detection" fails and both play sound. I could try another desktop. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
On Wed, 22 Jun 2022 20:38:14 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2022-06-22 14:26, Masaru Nomiya wrote:
Hello,
Sorry for late reply.
In the Message;
Subject : Re: [oS-EN] New sound problem Message-ID : <20220621235042.5skgzhyy5346anij@grusum.dhaller.de> Date & Time: Wed, 22 Jun 2022 01:50:42 +0200
[DH] == David Haller <dnh@opensuse.org> has written:
[...] DH> MSI == MicroStar International, and the MS-* are the actual DH> model names. The sales branding seems to be "P45 Diamond". DH> Here's the specs:
DH> https://www.msi.com/Motherboard/P45_Diamond/Specification
DH> Nice: 2 x eSATA on the back-I/O ;)
Thanks, David.
I confirmed, the on-board soundchip is Sound Blaster X-Fi Xtreme.
But I think about it, the phenomenon that Carlos is describing as a problem is a natural one．Rather, do we ever use a speaker and a headphone at the same time?
So, I looked into it, and found that Soundblaster offers a tool for windows that allows we to mute the headphone when using the speaker, and vice versa when using the headphone.
And that is what is not working correctly in Linux (I don't have Windows to try). When I plug in the headphones at the front, the loudspeakers should mute, and the headphones should work.
This doesn't happen.
The loudspeakers go mute (correct), and the headphones play no sound (incorrect).
If I pull the jack half a millimeter, the "detection" fails and both play sound.
I could try another desktop.
Faulty jack socket? Does it work under any software?
On 6/22/22 15:22, Dave Howorth wrote:
If I pull the jack half a millimeter, the "detection" fails and both play sound.
I could try another desktop. Faulty jack socket?
That sounds likely given the half a millimeter wiggle. Other possibility is worn insulation ring on the male plugin. Not as likely, but if your headphones are old, something to look at. -- David C. Rankin, J.D.,P.E.
On 2022-06-22 23:25, David C. Rankin wrote:
On 6/22/22 15:22, Dave Howorth wrote:
If I pull the jack half a millimeter, the "detection" fails and both play sound.
I could try another desktop. Faulty jack socket?
That sounds likely given the half a millimeter wiggle.
Other possibility is worn insulation ring on the male plugin. Not as likely, but if your headphones are old, something to look at.
Nope. This is not a hardware problem, it is a software problem. It is not hardware muting the headphones, it is the software which mutes them. The hardware simply tells (correctly) that the headphones are plugged, and the software reacts silencing everything.
-- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
On 2022-06-22 23:39, Carlos E. R. wrote:
On 2022-06-22 23:25, David C. Rankin wrote:
On 6/22/22 15:22, Dave Howorth wrote:
If I pull the jack half a millimeter, the "detection" fails and both play sound.
I could try another desktop. Faulty jack socket?
That sounds likely given the half a millimeter wiggle.
Other possibility is worn insulation ring on the male plugin. Not as likely, but if your headphones are old, something to look at.
Nope.
This is not a hardware problem, it is a software problem.
It is not hardware muting the headphones, it is the software which mutes them. The hardware simply tells (correctly) that the headphones are plugged, and the software reacts silencing everything.
If I wiggle out a bit the jack, the hardware does not tell the software that the headphones are connected, and thus both headphones and loudspeakers get sound.
-- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
On Wed, 22 Jun 2022 23:46:54 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2022-06-22 23:39, Carlos E. R. wrote:
On 2022-06-22 23:25, David C. Rankin wrote:
On 6/22/22 15:22, Dave Howorth wrote:
If I pull the jack half a millimeter, the "detection" fails and both play sound.
I could try another desktop. Faulty jack socket?
That sounds likely given the half a millimeter wiggle.
Other possibility is worn insulation ring on the male plugin. Not as likely, but if your headphones are old, something to look at.
Nope.
This is not a hardware problem, it is a software problem.
It is not hardware muting the headphones, it is the software which mutes them. The hardware simply tells (correctly) that the headphones are plugged, and the software reacts silencing everything.
If I wiggle out a bit the jack, the hardware does not tell the software that the headphones are connected, and thus both headphones and loudspeakers get sound.
and then later
There is a hiss in them, which proves they are connected to the hardware.
Sorry, I get the impression that you're drip feeding new information into the thread, perhaps as you remember it. But it makes it very difficult to help to diagnose. I'm not going to go back and reread every post in the thread and try to keep it all straight in my head. If you can post a summary with all the pertinent information in a single message then I'll read that and see if I can think of anything. But I would hope that in the act of writing it all out in an organized way, the solution will occur to you :)
On 2022-06-23 12:45, Dave Howorth wrote:
On Wed, 22 Jun 2022 23:46:54 +0200 "Carlos E. R." <> wrote:
On 2022-06-22 23:39, Carlos E. R. wrote:
On 2022-06-22 23:25, David C. Rankin wrote:
On 6/22/22 15:22, Dave Howorth wrote:
If I pull the jack half a millimeter, the "detection" fails and both play sound.
I could try another desktop. Faulty jack socket?
That sounds likely given the half a millimeter wiggle.
Other possibility is worn insulation ring on the male plugin. Not as likely, but if your headphones are old, something to look at.
Nope.
This is not a hardware problem, it is a software problem.
It is not hardware muting the headphones, it is the software which mutes them. The hardware simply tells (correctly) that the headphones are plugged, and the software reacts silencing everything.
If I wiggle out a bit the jack, the hardware does not tell the software that the headphones are connected, and thus both headphones and loudspeakers get sound.
and then later
There is a hiss in them, which proves they are connected to the hardware.
Sorry, I get the impression that you're drip feeding new information into the thread, perhaps as you remember it. But it makes it very difficult to help to diagnose. I'm not going to go back and reread every post in the thread and try to keep it all straight in my head.
Yes, as I remember, and as people comment and ask, making me think and remember things.
If you can post a summary with all the pertinent information in a single message then I'll read that and see if I can think of anything. But I would hope that in the act of writing it all out in an organized way, the solution will occur to you :)
There is no solution, only get a length of stereo cable + usb connecting to the back of the computer. AFAIK the cause of the problem is that Linux simply do not fully support this hardware: when the connection of the headphones is detected, something decides to silence the speakers (correct), but also silences the headphones; pavucontrol does nothing to correct this. If I move the headphones jack just about half a milliliter out the detection fails (the headphones output disappears from pavucontrol), and there is output in both speakers and headphone. This position is acceptable for me. This has been hapened since I bought the machine, but I had forgotten, so old openSUSE will not work. Masaru has commented that this hardware has a tool in Windows to silence the speakers when headphone is connected. Soundblaster people are not interested in replicating this in Linux, and whatever/whomever reverse engineered this feature, it doesn't work right. Hardware is: Elesar:~ # inxi --audio Audio: Device-1: Creative Labs CA0110 [Sound Blaster X-Fi Xtreme Audio] driver: snd_hda_intel Sound Server: ALSA v: k5.3.18-150300.59.71-default Elesar:~ # Elesar:~ # inxi --cpu CPU: Topology: Quad Core model: Intel Core2 Quad Q9550 bits: 64 type: MCP L2 cache: 6144 KiB Speed: 2788 MHz min/max: N/A Core speeds (MHz): 1: 2788 2: 2824 3: 2736 4: 2796 Elesar:~ # Elesar:~ # inxi --machine --dmidecode Use of uninitialized value in string eq at /usr/bin/inxi line 10982. Machine: Type: Desktop System: MICRO-STAR product: MS-7516 v: 1.0 serial: N/A Mobo: MICRO-STAR model: MS-7516 serial: N/A BIOS: American Megatrends v: 1.5 rev: 8.15 date: 10/10/2008 Elesar:~ # inxi --machine Machine: Type: Desktop Mobo: MICRO-STAR model: MS-7516 v: 1.0 serial: N/A BIOS: American Megatrends v: 1.5 date: 10/10/2008 Elesar:~ # Corresponds to: https://www.msi.com/Motherboard/P45_Diamond/Specification -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Carlos E. R. wrote:
There is no solution,
Surely that is jumping to conclusions.
AFAIK the cause of the problem is that Linux simply do not fully support this hardware: when the connection of the headphones is detected, something decides to silence the speakers (correct), but also silences the headphones;
FWIW, on my laptop running 15.2, alsamixer shows the reaction when a headset is plugged in and out. (sound card = HDA Intel PCH). I am curious to know if you see the same: In - speaker volume is reduced to 0, headphone volume set to 100. Master is reduced to about 50%. Out - speaker volume is increased to 100, headphone volume set to 0. Master is increased to 100. This is in fact using the very same driver - snd_hda_intel - albeit with a different sound chip. (Conexant 20751). -- Per Jessen, Zürich (29.0°C)
On 2022-06-23 17:46, Per Jessen wrote:
Carlos E. R. wrote:
There is no solution,
Surely that is jumping to conclusions.
AFAIK the cause of the problem is that Linux simply do not fully support this hardware: when the connection of the headphones is detected, something decides to silence the speakers (correct), but also silences the headphones;
FWIW, on my laptop running 15.2, alsamixer shows the reaction when a headset is plugged in and out. (sound card = HDA Intel PCH). I am curious to know if you see the same:
In - speaker volume is reduced to 0, headphone volume set to 100. Master is reduced to about 50%. Out - speaker volume is increased to 100, headphone volume set to 0. Master is increased to 100.
No, volumes do not change here. Looking at alsamixer, tab "Output Devices", er... pause. At this moment, it shows "Dummy output" and sound does not work, at all. I have to run "yast2 sound", delete the card, add it again (edit), automatic quick setup. This happens on almost every reboot (no solution for this, either). Now, Looking at alsamixer, tab "Output Devices", I see it shows "CA0110 (Soundblaster X-Fi Xtreme Audio (SB1040 PCI Express) Analog Stereo), set at 41% on port "Line out (plugged in)". Headphones show as unplugged, volume at 18%. I connect the headphones, and automatically alsamixer shows them as connected, same volume. Line out can be selected, same level as before. But neither output produces sound, despite alsamixer showing that there is audio going out. None show as muted, and clicking the mute icon doesn't change the situation.
This is in fact using the very same driver - snd_hda_intel - albeit with a different sound chip. (Conexant 20751).
Well, it simply does not work here, never has. And this is a new installation on this old machine. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Carlos E. R. wrote:
On 2022-06-23 17:46, Per Jessen wrote:
FWIW, on my laptop running 15.2, alsamixer shows the reaction when a headset is plugged in and out. (sound card = HDA Intel PCH). I am curious to know if you see the same:
In - speaker volume is reduced to 0, headphone volume set to 100. Master is reduced to about 50%. Out - speaker volume is increased to 100, headphone volume set to 0. Master is increased to 100.
No, volumes do not change here.
Looking at alsamixer, tab "Output Devices", er...
pause.
At this moment, it shows "Dummy output" and sound does not work, at all.
That sounds reasonable :-)
I have to run "yast2 sound", delete the card, add it again (edit), automatic quick setup. This happens on almost every reboot (no solution for this, either).
That is weird - is this specific to 15.4? If I run "yast2 sound", I see two devices listed, but both "Not configured". IOW, apparently a yast configuration is not required in order to have sound. In alsamixer, I have two devices - "HDA Intel HDMI", and "HDA Intel PCH".
Now, Looking at alsamixer, tab "Output Devices", I see it shows "CA0110 (Soundblaster X-Fi Xtreme Audio (SB1040 PCI Express) Analog Stereo), set at 41% on port "Line out (plugged in)". Headphones show as unplugged, volume at 18%.
I connect the headphones, and automatically alsamixer shows them as connected, same volume. Line out can be selected, same level as before. But neither output produces sound, despite alsamixer showing that there is audio going out. None show as muted, and clicking the mute icon doesn't change the situation.
I can't help but suspect some configuration conflict/issue - that you need to fiddle with yast whereas I don't, that is odd. Given that my config works without a yast sound config, in your situation I would be tempted to get rid of it and start from there. -- Per Jessen, Zürich (22.5°C)
On 2022-06-24 10:10, Per Jessen wrote:
Carlos E. R. wrote:
On 2022-06-23 17:46, Per Jessen wrote:
FWIW, on my laptop running 15.2, alsamixer shows the reaction when a headset is plugged in and out. (sound card = HDA Intel PCH). I am curious to know if you see the same:
In - speaker volume is reduced to 0, headphone volume set to 100. Master is reduced to about 50%. Out - speaker volume is increased to 100, headphone volume set to 0. Master is increased to 100.
No, volumes do not change here.
Looking at alsamixer, tab "Output Devices", er...
pause.
At this moment, it shows "Dummy output" and sound does not work, at all.
That sounds reasonable :-)
I have to run "yast2 sound", delete the card, add it again (edit), automatic quick setup. This happens on almost every reboot (no solution for this, either).
That is weird - is this specific to 15.4?
Nope, it happens on this 15.3 and earlier on this computer. There was a thread about it, no real practical solution except what I did.
If I run "yast2 sound", I see two devices listed, but both "Not configured". IOW, apparently a yast configuration is not required in order to have sound.
Some times. Most times, hopefully.
In alsamixer, I have two devices - "HDA Intel HDMI", and "HDA Intel PCH".
Now, Looking at alsamixer, tab "Output Devices", I see it shows "CA0110 (Soundblaster X-Fi Xtreme Audio (SB1040 PCI Express) Analog Stereo), set at 41% on port "Line out (plugged in)". Headphones show as unplugged, volume at 18%.
I connect the headphones, and automatically alsamixer shows them as connected, same volume. Line out can be selected, same level as before. But neither output produces sound, despite alsamixer showing that there is audio going out. None show as muted, and clicking the mute icon doesn't change the situation.
I can't help but suspect some configuration conflict/issue - that you need to fiddle with yast whereas I don't, that is odd. Given that my config works without a yast sound config, in your situation I would be tempted to get rid of it and start from there.
And do what? I don't know how to activate sound except by using YaST, since decades. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Carlos E. R. wrote:
On 2022-06-24 10:10, Per Jessen wrote:
I can't help but suspect some configuration conflict/issue - that you need to fiddle with yast whereas I don't, that is odd. Given that my config works without a yast sound config, in your situation I would be tempted to get rid of it and start from there.
And do what? I don't know how to activate sound except by using YaST, since decades.
and I don't recall having had to do that, for years. I don't know what the yast sound config does, but on my desktop systems (also quite old), it doesn't seem to be required. My suspicion is that the yast config is _somehow_ getting in the way on your system. Starting with a clean slate might help with the diagnosis. I only have 15.2 desktop systems, sound works on all of them, I'll be happy to compare configs. The only difference ought to be in the hardware.
From my laptop, Leap 15.2:
office68:/etc/modprobe.d # l /proc/asound/ total 0 dr-xr-xr-x 6 root root 0 Jun 24 10:51 ./ dr-xr-xr-x 282 root root 0 May 14 20:48 ../ lrwxrwxrwx 1 root root 5 Jun 24 10:51 HDMI -> card0/ lrwxrwxrwx 1 root root 5 Jun 24 10:51 PCH -> card1/ dr-xr-xr-x 7 root root 0 Jun 24 10:51 card0/ dr-xr-xr-x 4 root root 0 Jun 24 10:51 card1/ -r--r--r-- 1 root root 0 Jun 24 10:51 cards -r--r--r-- 1 root root 0 Jun 24 10:51 devices -r--r--r-- 1 root root 0 Jun 24 10:51 hwdep -r--r--r-- 1 root root 0 Jun 24 10:51 modules dr-xr-xr-x 2 root root 0 Jun 24 10:51 oss/ -r--r--r-- 1 root root 0 Jun 24 10:51 pcm dr-xr-xr-x 2 root root 0 Jun 24 10:51 seq/ -r--r--r-- 1 root root 0 Jun 24 10:51 timers -r--r--r-- 1 root root 0 Jun 24 10:51 version office68:/etc/modprobe.d # cat /proc/asound/cards 0 [HDMI ]: HDA-Intel - HDA Intel HDMI HDA Intel HDMI at 0xc1210000 irq 52 1 [PCH ]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xc1214000 irq 51 -- Per Jessen, Zürich (23.6°C)
Per Jessen wrote:
And do what? I don't know how to activate sound except by using YaST, since decades.
and I don't recall having had to do that, for years. I don't know what the yast sound config does,
Judging by the source code, it is about configuring Pulseaudio.
but on my desktop systems (also quite old), it doesn't seem to be required.
Although pulseaudio _is_ running. -- Per Jessen, Zürich (24.5°C)
On 2022-06-24 10:56, Per Jessen wrote:
Carlos E. R. wrote:
On 2022-06-24 10:10, Per Jessen wrote:
I can't help but suspect some configuration conflict/issue - that you need to fiddle with yast whereas I don't, that is odd. Given that my config works without a yast sound config, in your situation I would be tempted to get rid of it and start from there.
And do what? I don't know how to activate sound except by using YaST, since decades.
and I don't recall having had to do that, for years. I don't know what the yast sound config does, but on my desktop systems (also quite old), it doesn't seem to be required. My suspicion is that the yast config is _somehow_ getting in the way on your system. Starting with a clean slate might help with the diagnosis.
I only have 15.2 desktop systems, sound works on all of them, I'll be happy to compare configs. The only difference ought to be in the hardware.
On other machines, I don't have to do anything, it works directly from installation. Not in this. Anyway, I do not know how to "start with a clean slate". Install openSUSE again? Not doable, machine is in production, several people use it. And I am too busy to do that, they would behead me for wasting time on the computer :-p What I have done, is insert this code in one of my boot scripts: /usr/bin/logger -t Mine -p daemon.info \ "Reseting sound system with yast." yast sound remove && yast2 sound add And that solves the issue. And I just got the extension cord for the headphones. I just unplug the speakers and connect the headphones, or viceversa, as needed, and done.
From my laptop, Leap 15.2:
office68:/etc/modprobe.d # l /proc/asound/ total 0 dr-xr-xr-x 6 root root 0 Jun 24 10:51 ./ dr-xr-xr-x 282 root root 0 May 14 20:48 ../ lrwxrwxrwx 1 root root 5 Jun 24 10:51 HDMI -> card0/ lrwxrwxrwx 1 root root 5 Jun 24 10:51 PCH -> card1/ dr-xr-xr-x 7 root root 0 Jun 24 10:51 card0/ dr-xr-xr-x 4 root root 0 Jun 24 10:51 card1/ -r--r--r-- 1 root root 0 Jun 24 10:51 cards -r--r--r-- 1 root root 0 Jun 24 10:51 devices -r--r--r-- 1 root root 0 Jun 24 10:51 hwdep -r--r--r-- 1 root root 0 Jun 24 10:51 modules dr-xr-xr-x 2 root root 0 Jun 24 10:51 oss/ -r--r--r-- 1 root root 0 Jun 24 10:51 pcm dr-xr-xr-x 2 root root 0 Jun 24 10:51 seq/ -r--r--r-- 1 root root 0 Jun 24 10:51 timers -r--r--r-- 1 root root 0 Jun 24 10:51 version office68:/etc/modprobe.d # cat /proc/asound/cards 0 [HDMI ]: HDA-Intel - HDA Intel HDMI HDA Intel HDMI at 0xc1210000 irq 52 1 [PCH ]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xc1214000 irq 51
Elesar:~ # l /proc/asound/ total 0 dr-xr-xr-x 5 root root 0 Jun 24 17:59 ./ dr-xr-xr-x 291 root root 0 Jun 24 17:57 ../ lrwxrwxrwx 1 root root 5 Jun 24 18:06 Creative -> card0/ dr-xr-xr-x 6 root root 0 Jun 24 17:59 card0/ -r--r--r-- 1 root root 0 Jun 24 18:06 cards -r--r--r-- 1 root root 0 Jun 24 18:06 devices -r--r--r-- 1 root root 0 Jun 24 18:06 hwdep -r--r--r-- 1 root root 0 Jun 24 18:06 modules dr-xr-xr-x 2 root root 0 Jun 24 18:06 oss/ -r--r--r-- 1 root root 0 Jun 24 18:06 pcm dr-xr-xr-x 2 root root 0 Jun 24 17:59 seq/ -r--r--r-- 1 root root 0 Jun 24 18:06 timers -r--r--r-- 1 root root 0 Jun 24 18:06 version Elesar:~ # Elesar:~ # cat /proc/asound/cards 0 [Creative ]: HDA-Intel - HDA Creative HDA Creative at 0xfe6fc000 irq 16 Elesar:~ # -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Carlos E. R. wrote:
On 2022-06-24 10:56, Per Jessen wrote:
Carlos E. R. wrote:
On 2022-06-24 10:10, Per Jessen wrote:
I can't help but suspect some configuration conflict/issue - that you need to fiddle with yast whereas I don't, that is odd. Given that my config works without a yast sound config, in your situation I would be tempted to get rid of it and start from there.
And do what? I don't know how to activate sound except by using YaST, since decades.
and I don't recall having had to do that, for years. I don't know what the yast sound config does, but on my desktop systems (also quite old), it doesn't seem to be required. My suspicion is that the yast config is _somehow_ getting in the way on your system. Starting with a clean slate might help with the diagnosis.
On other machines, I don't have to do anything, it works directly from installation. Not in this. Anyway, I do not know how to "start with a clean slate". Install openSUSE again? Not doable, machine is in production, several people use it. And I am too busy to do that, they would behead me for wasting time on the computer :-p
Just clean as far as the sound config goes. Simply get rid of the pulseaudio stuff configured by yast.
What I have done, is insert this code in one of my boot scripts:
/usr/bin/logger -t Mine -p daemon.info \ "Reseting sound system with yast." yast sound remove && yast2 sound add
And that solves the issue.
It all depends on what you want - a kludgy work around as the above or actually solve the problem ;-) Me, I don't like work arounds for what appears to be a pretty banal problem. -- Per Jessen, Zürich (22.6°C) Слава Україні! Slava Ukraini!
On 2022-06-25 12:57, Per Jessen wrote:
Carlos E. R. wrote:
On 2022-06-24 10:56, Per Jessen wrote:
Carlos E. R. wrote:
On 2022-06-24 10:10, Per Jessen wrote:
it doesn't seem to be required. My suspicion is that the yast config is _somehow_ getting in the way on your system. Starting with a clean slate might help with the diagnosis.
On other machines, I don't have to do anything, it works directly from installation. Not in this. Anyway, I do not know how to "start with a clean slate". Install openSUSE again? Not doable, machine is in production, several people use it. And I am too busy to do that, they would behead me for wasting time on the computer :-p
Just clean as far as the sound config goes. Simply get rid of the pulseaudio stuff configured by yast.
No idea what files YaST writes, what services it starts. Consider that I used YaST when after installation sound was not working, many moons ago.
What I have done, is insert this code in one of my boot scripts:
/usr/bin/logger -t Mine -p daemon.info \ "Reseting sound system with yast." yast sound remove && yast2 sound add
And that solves the issue.
It all depends on what you want - a kludgy work around as the above or actually solve the problem ;-) Me, I don't like work arounds for what appears to be a pretty banal problem.
Well, as compared to starting VLC to see a movie, finding that sound does not work, and firing YaST to correct the problem, then restarting vlc, having it automated, and VLC playing instantly with no delay, is a huge advancement. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
* Carlos E. R. <robin.listas@telefonica.net> [06-25-22 12:18]:
On 2022-06-25 12:57, Per Jessen wrote:
Carlos E. R. wrote:
On 2022-06-24 10:56, Per Jessen wrote:
Carlos E. R. wrote:
On 2022-06-24 10:10, Per Jessen wrote:
it doesn't seem to be required. My suspicion is that the yast config is _somehow_ getting in the way on your system. Starting with a clean slate might help with the diagnosis.
On other machines, I don't have to do anything, it works directly from installation. Not in this. Anyway, I do not know how to "start with a clean slate". Install openSUSE again? Not doable, machine is in production, several people use it. And I am too busy to do that, they would behead me for wasting time on the computer :-p
Just clean as far as the sound config goes. Simply get rid of the pulseaudio stuff configured by yast.
No idea what files YaST writes, what services it starts.
Consider that I used YaST when after installation sound was not working, many moons ago.
What I have done, is insert this code in one of my boot scripts:
/usr/bin/logger -t Mine -p daemon.info \ "Reseting sound system with yast." yast sound remove && yast2 sound add
And that solves the issue.
It all depends on what you want - a kludgy work around as the above or actually solve the problem ;-) Me, I don't like work arounds for what appears to be a pretty banal problem.
Well, as compared to starting VLC to see a movie, finding that sound does not work, and firing YaST to correct the problem, then restarting vlc, having it automated, and VLC playing instantly with no delay, is a huge advancement.
there was no argument that you "should", only that the OP preferred not. you are the admin or your system and can choose as you wish. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
On 25/06/2022 18.17, Carlos E. R. wrote:
On 2022-06-25 12:57, Per Jessen wrote:
Carlos E. R. wrote:
On 2022-06-24 10:56, Per Jessen wrote:
Carlos E. R. wrote:
On 2022-06-24 10:10, Per Jessen wrote:
it doesn't seem to be required. My suspicion is that the yast config is _somehow_ getting in the way on your system. Starting with a clean slate might help with the diagnosis.
On other machines, I don't have to do anything, it works directly from installation. Not in this. Anyway, I do not know how to "start with a clean slate". Install openSUSE again? Not doable, machine is in production, several people use it. And I am too busy to do that, they would behead me for wasting time on the computer :-p
Just clean as far as the sound config goes. Simply get rid of the pulseaudio stuff configured by yast.
No idea what files YaST writes, what services it starts.
Consider that I used YaST when after installation sound was not working, many moons ago.
What I have done, is insert this code in one of my boot scripts:
/usr/bin/logger -t Mine -p daemon.info \ "Reseting sound system with yast." yast sound remove && yast2 sound add
And that solves the issue.
It all depends on what you want - a kludgy work around as the above or actually solve the problem ;-) Me, I don't like work arounds for what appears to be a pretty banal problem.
Well, as compared to starting VLC to see a movie, finding that sound does not work, and firing YaST to correct the problem, then restarting vlc, having it automated, and VLC playing instantly with no delay, is a huge advancement.
Ah, I forgot that there was a thread dedicated to that problem. Masaru Nomiya tried for several days to find the proper solution, but we did not find it. He suggested to switch to piperwire instead of pulse, but I don't like that, for Leap. So the only thing that we know that works in that machine is to tell YaST to remove and add/configure sound again, on every boot. And as I found a way to do that automatically by boot script without my intervention, I am a happy camper. I doubt you can easily find a way to remove whatever YaST did and have sound working on that machine (I'm now on my laptop). And I am too busy these days to get very involved with a computer problem (I have a worse problem with nouveau crashing the machine now and then). I just need the machine to work, and that hack works. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.3 (Legolas))
Hello, In the Message; Subject : Re: [oS-EN] Old sound problem Message-ID : <29fbe47d-56c6-3d51-ea46-2937d7a7d621@telefonica.net> Date & Time: Sat, 25 Jun 2022 20:49:23 +0200 [CER] == "Carlos E. R." <robin.listas@telefonica.net> has written: [...] CER> Ah, I forgot that there was a thread dedicated to that CER> problem. Masaru Nomiya tried for several days to find the proper CER> solution, but we did not find it. He suggested to switch to piperwire CER> instead of pulse, but I don't like that, for Leap. You TRIED to use pipewire without any settings. CER> So the only thing that we know that works in that machine is to tell YaST to CER> remove and add/configure sound again, on every boot. And as I CER> found a way to do that automatically by boot script without my CER> intervention, I am a happy camper. I fully understand that your stance is "I don't care about logic as long as it works". Goog luck, and Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ "It should never be said that it is OK to ignore the theoretical as long as it becomes a tool." -- T. Mori (The original is in Japanese) --
On 2022-06-25 23:26, Masaru Nomiya wrote:
Hello,
In the Message;
Subject : Re: [oS-EN] Old sound problem Message-ID : <29fbe47d-56c6-3d51-ea46-2937d7a7d621@telefonica.net> Date & Time: Sat, 25 Jun 2022 20:49:23 +0200
[CER] == "Carlos E. R." <robin.listas@telefonica.net> has written:
[...] CER> Ah, I forgot that there was a thread dedicated to that CER> problem. Masaru Nomiya tried for several days to find the proper CER> solution, but we did not find it. He suggested to switch to piperwire CER> instead of pulse, but I don't like that, for Leap.
You TRIED to use pipewire without any settings.
Yes. I think piperwire is the future, but not the present, on Leap. I read of things I use that are not finished. I'll wait.
CER> So the only thing that we know that works in that machine is to tell YaST to CER> remove and add/configure sound again, on every boot. And as I CER> found a way to do that automatically by boot script without my CER> intervention, I am a happy camper.
I fully understand that your stance is "I don't care about logic as long as it works".
Goog luck, and Regards.
Maybe, in about a month, I have more free time and I can try again. Not now. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Carlos E. R. wrote:
I doubt you can easily find a way to remove whatever YaST did and have sound working on that machine (I'm now on my laptop).
"Remove what yast did" is easy. Do a new install or ask someone with a new install, and you can look at the default setup. Also, it is easy to find out what yast does, the source code is available. -- Per Jessen, Zürich (21.9°C)
On 2022-06-26 10:22, Per Jessen wrote:
Carlos E. R. wrote:
I doubt you can easily find a way to remove whatever YaST did and have sound working on that machine (I'm now on my laptop).
"Remove what yast did" is easy. Do a new install
Can't do, machine is in production, that's hours of work. Machine would be off line for several people, while results and gains unpredictable. And my internet is capped in this location. Also I don't have room in tiny ssd disk to try extra installation and compare. Some time in august or later, I might be tempted.
or ask someone with a new install, and you can look at the default setup.
Not trivial.
Also, it is easy to find out what yast does, the source code is available.
Yeah, sure :-DDDD I can also read the logs, but I don't have the installation logs. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Carlos E. R. wrote:
On 2022-06-26 10:22, Per Jessen wrote:
Carlos E. R. wrote:
I doubt you can easily find a way to remove whatever YaST did and have sound working on that machine (I'm now on my laptop).
"Remove what yast did" is easy. Do a new install
Can't do, machine is in production, that's hours of work.
I did not suggest on the same machine. To check out the default config, any machine with a soundcard will do.
or ask someone with a new install, and you can look at the default setup.
Not trivial.
Uh, 100% trivial I would suggest. What isn't trivial about comparing two setups? 'diff' will help with that.
Also, it is easy to find out what yast does, the source code is available.
Yeah, sure :-DDDD
I can also read the logs, but I don't have the installation logs.
The installation logs won't tell you anything. The source code is easy to read, you will see which files are being touched etc. -- Per Jessen, Zürich (23.9°C)
On 2022-06-26 21:35, Per Jessen wrote:
Carlos E. R. wrote:
On 2022-06-26 10:22, Per Jessen wrote:
Carlos E. R. wrote:
I doubt you can easily find a way to remove whatever YaST did and have sound working on that machine (I'm now on my laptop).
"Remove what yast did" is easy. Do a new install
Can't do, machine is in production, that's hours of work.
I did not suggest on the same machine. To check out the default config, any machine with a soundcard will do.
Can't do, the other machines do not have problems with sound, AFAIR. Nor do I have suitable machines here, only my tiny laptop. Plus, I don't remember on which machines I used yast and on which I didn't.
or ask someone with a new install, and you can look at the default setup.
Not trivial.
Uh, 100% trivial I would suggest. What isn't trivial about comparing two setups? 'diff' will help with that.
Once you know what files to select...
Also, it is easy to find out what yast does, the source code is available.
Yeah, sure :-DDDD
I can also read the logs, but I don't have the installation logs.
The installation logs won't tell you anything. The source code is easy to read, you will see which files are being touched etc.
Not that easy, you have to reproduce the decision tree. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Carlos E. R. wrote:
On 2022-06-26 21:35, Per Jessen wrote:
Carlos E. R. wrote:
On 2022-06-26 10:22, Per Jessen wrote:
Carlos E. R. wrote:
I doubt you can easily find a way to remove whatever YaST did and have sound working on that machine (I'm now on my laptop).
"Remove what yast did" is easy. Do a new install
Can't do, machine is in production, that's hours of work.
I did not suggest on the same machine. To check out the default config, any machine with a soundcard will do.
Can't do, the other machines do not have problems with sound, AFAIR.
Nor do I have suitable machines here, only my tiny laptop. Plus, I don't remember on which machines I used yast and on which I didn't.
Hence my earlier suggestion of asking someone with a default install.
or ask someone with a new install, and you can look at the default setup.
Not trivial.
Uh, 100% trivial I would suggest. What isn't trivial about comparing two setups? 'diff' will help with that.
Once you know what files to select...
The easiest is just to run a diff -qrb /etc1 /etc2 - it'll give you too much of course, but it's easy to get rid of what isn't relevant.
The installation logs won't tell you anything. The source code is easy to read, you will see which files are being touched etc.
Not that easy, you have to reproduce the decision tree.
I think I neglected to do that, but it still worked :-) Anyway, too many hurdles. -- Per Jessen, Zürich (21.4°C)
On 2022-06-27 11:23, Per Jessen wrote:
The easiest is just to run a diff -qrb /etc1 /etc2 - it'll give you too much of course, but it's easy to get rid of what isn't relevant.
I do the same. Sometimes I want to be able to see it all more graphically (read colors) so I make a patch and then use a tool like gitk or kompare to show the end result. From the top of my head. ex. diff -ruN testdir1/ testdir2/ > thepatch.patch && kompare thepatch.patch -- /bengan (from the sunny side on the beach)
On 2022-06-28 10:05, Bengt Gördén wrote:
On 2022-06-27 11:23, Per Jessen wrote:
The easiest is just to run a diff -qrb /etc1 /etc2 - it'll give you too much of course, but it's easy to get rid of what isn't relevant.
I do the same. Sometimes I want to be able to see it all more graphically (read colors) so I make a patch and then use a tool like gitk or kompare to show the end result.
From the top of my head. ex. diff -ruN testdir1/ testdir2/ > thepatch.patch && kompare thepatch.patch
The result of that in my system can be many hundreds of lines. And unless it is the exact same hardware, it will not be relevant. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Carlos E. R. wrote:
On 2022-06-28 10:05, Bengt Gördén wrote:
On 2022-06-27 11:23, Per Jessen wrote:
The easiest is just to run a diff -qrb /etc1 /etc2 - it'll give you too much of course, but it's easy to get rid of what isn't relevant.
I do the same. Sometimes I want to be able to see it all more graphically (read colors) so I make a patch and then use a tool like gitk or kompare to show the end result.
From the top of my head. ex. diff -ruN testdir1/ testdir2/ > thepatch.patch && kompare thepatch.patch
The result of that in my system can be many hundreds of lines. And unless it is the exact same hardware, it will not be relevant.
Carlos, you are putting up hurdles for yourself :-) Bengt was making a general example - in my own example, you would only get a list of the _filenames_ that are different. You could then relatively easily (but manually) filter out those with no bearing on the issue, and continue to look at those few that mattered. Very few lines in the end. -- Per Jessen, Zürich (20.5°C)
On 28/06/2022 20.00, Per Jessen wrote:
Carlos E. R. wrote:
On 2022-06-28 10:05, Bengt Gördén wrote:
On 2022-06-27 11:23, Per Jessen wrote:
The easiest is just to run a diff -qrb /etc1 /etc2 - it'll give you too much of course, but it's easy to get rid of what isn't relevant.
I do the same. Sometimes I want to be able to see it all more graphically (read colors) so I make a patch and then use a tool like gitk or kompare to show the end result.
From the top of my head. ex. diff -ruN testdir1/ testdir2/ > thepatch.patch && kompare thepatch.patch
The result of that in my system can be many hundreds of lines. And unless it is the exact same hardware, it will not be relevant.
Carlos, you are putting up hurdles for yourself :-)
Bengt was making a general example - in my own example, you would only get a list of the _filenames_ that are different. You could then relatively easily (but manually) filter out those with no bearing on the issue, and continue to look at those few that mattered. Very few lines in the end.
But I simply don't have such a tree. I am in no position to generate one, and that's the one I need, not a random one from someone here. In two months time I may have the time to run such an experiment. Now, no. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.3 (Legolas))
Carlos E. R. wrote:
On 2022-06-25 12:57, Per Jessen wrote:
Just clean as far as the sound config goes. Simply get rid of the pulseaudio stuff configured by yast.
No idea what files YaST writes, what services it starts.
Looking at the yast source code, it is all about pulseaudio. If you take a look at /etc/pulse/, I'm sure you will see recently changed files. Maybe also some module config in /etc/modprobe.d .
It all depends on what you want - a kludgy work around as the above or actually solve the problem ;-) Me, I don't like work arounds for what appears to be a pretty banal problem.
Well, as compared to starting VLC to see a movie, finding that sound does not work, and firing YaST to correct the problem, then restarting vlc, having it automated, and VLC playing instantly with no delay, is a huge advancement.
Yep. It's a matter of attitude, that's all. -- Per Jessen, Zürich (21.4°C)
On 2022-06-26 10:08, Per Jessen wrote:
Carlos E. R. wrote:
On 2022-06-25 12:57, Per Jessen wrote:
Just clean as far as the sound config goes. Simply get rid of the pulseaudio stuff configured by yast.
No idea what files YaST writes, what services it starts.
Looking at the yast source code, it is all about pulseaudio. If you take a look at /etc/pulse/, I'm sure you will see recently changed files.
Nope. Elesar:~ # tree --si -D /etc/pulse/ /etc/pulse/ ├── [1.2k Apr 4 2021] client.conf ├── [4.1k Mar 28 15:19] client.conf.d │ ├── [ 15 Apr 4 2021] 50-system.conf │ └── [ 16 Mar 28 14:18] 50-system.conf.rpmsave ├── [2.4k Apr 4 2021] daemon.conf ├── [4.1k Mar 28 15:19] daemon.conf.d │ └── [ 131 Apr 4 2021] 60-disable_flat_volumes.conf ├── [5.1k Apr 4 2021] default.pa └── [1.9k Apr 4 2021] system.pa 2 directories, 7 files Elesar:~ #
Maybe also some module config in /etc/modprobe.d .
Elesar:~ # tree --si -D /etc/modprobe.d/ /etc/modprobe.d/ ├── [3.6k Dec 7 2021] 00-system.conf ├── [1.3k Dec 6 2021] 10-unsupported-modules.conf ├── [ 308 Jun 17 9:33] 20-kernel-default-extra.conf ├── [5.3k Dec 6 2021] 50-blacklist.conf ├── [ 128 Nov 24 2021] 50-bluetooth.conf ├── [ 33 May 25 2018] 50-ipw2200.conf ├── [ 34 May 25 2018] 50-iwl3945.conf ├── [ 18 May 25 2018] 50-prism54.conf ├── [ 103 Jun 26 8:11] 50-sound.conf <=========== ├── [ 1 Jun 26 8:11] 50-sound.conf.YaST2save ├── [ 668 Dec 7 2021] 60-blacklist_fs-adfs.conf ├── [ 668 Dec 7 2021] 60-blacklist_fs-affs.conf ├── [ 668 Dec 7 2021] 60-blacklist_fs-befs.conf ├── [ 664 Dec 7 2021] 60-blacklist_fs-bfs.conf ├── [ 676 Dec 7 2021] 60-blacklist_fs-cramfs.conf ├── [ 664 Dec 7 2021] 60-blacklist_fs-efs.conf ├── [ 672 Dec 7 2021] 60-blacklist_fs-erofs.conf ├── [ 672 Dec 7 2021] 60-blacklist_fs-exofs.conf ├── [ 668 Dec 7 2021] 60-blacklist_fs-f2fs.conf ├── [ 684 Dec 7 2021] 60-blacklist_fs-freevxfs.conf ├── [ 664 Dec 7 2021] 60-blacklist_fs-hfs.conf ├── [ 668 Dec 7 2021] 60-blacklist_fs-hpfs.conf ├── [ 664 Dec 7 2021] 60-blacklist_fs-jfs.conf ├── [ 672 Dec 7 2021] 60-blacklist_fs-minix.conf ├── [ 676 Dec 7 2021] 60-blacklist_fs-nilfs2.conf ├── [ 668 Dec 7 2021] 60-blacklist_fs-ntfs.conf ├── [ 668 Dec 7 2021] 60-blacklist_fs-omfs.conf ├── [ 668 Dec 7 2021] 60-blacklist_fs-qnx4.conf ├── [ 668 Dec 7 2021] 60-blacklist_fs-qnx6.conf ├── [ 668 Dec 7 2021] 60-blacklist_fs-sysv.conf ├── [ 664 Dec 7 2021] 60-blacklist_fs-ufs.conf ├── [ 47 Dec 6 2021] 99-local.conf ├── [ 158 May 10 11:02] firewalld-sysctls.conf ├── [ 674 Jan 8 2019] tuned.conf └── [ 49 Apr 23 2019] vmware-fuse.conf 0 directories, 35 files Elesar:~ # Bingo. Elesar:~ # cat /etc/modprobe.d/50-sound.conf options snd slots=snd-hda-intel # svHJ.YhraNp3EzIA:SB1040 PCI Express alias snd-card-0 snd-hda-intel Elesar:~ # cat /etc/modprobe.d/50-sound.conf.YaST2save Elesar:~ # Something had erased the 50-sound.conf file, and YaST restored it. My guess.
It all depends on what you want - a kludgy work around as the above or actually solve the problem ;-) Me, I don't like work arounds for what appears to be a pretty banal problem.
Well, as compared to starting VLC to see a movie, finding that sound does not work, and firing YaST to correct the problem, then restarting vlc, having it automated, and VLC playing instantly with no delay, is a huge advancement.
Yep. It's a matter of attitude, that's all.
No, it is a machine in production, people depend on it. I'm sure you are aware of the constraints. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Carlos E. R. wrote:
On 2022-06-26 10:08, Per Jessen wrote:
Carlos E. R. wrote:
On 2022-06-25 12:57, Per Jessen wrote:
Just clean as far as the sound config goes. Simply get rid of the pulseaudio stuff configured by yast.
No idea what files YaST writes, what services it starts.
Looking at the yast source code, it is all about pulseaudio. If you take a look at /etc/pulse/, I'm sure you will see recently changed files.
Nope. Elesar:~ # tree --si -D /etc/pulse/
Interesting, mine looks 99% similar.
Elesar:~ # tree --si -D /etc/modprobe.d/ /etc/modprobe.d/ ├── [3.6k Dec 7 2021] 00-system.conf ├── [1.3k Dec 6 2021] 10-unsupported-modules.conf ├── [ 308 Jun 17 9:33] 20-kernel-default-extra.conf ├── [5.3k Dec 6 2021] 50-blacklist.conf ├── [ 128 Nov 24 2021] 50-bluetooth.conf ├── [ 33 May 25 2018] 50-ipw2200.conf ├── [ 34 May 25 2018] 50-iwl3945.conf ├── [ 18 May 25 2018] 50-prism54.conf ├── [ 103 Jun 26 8:11] 50-sound.conf <=========== ├── [ 1 Jun 26 8:11] 50-sound.conf.YaST2save
Okay.
Bingo.
Elesar:~ # cat /etc/modprobe.d/50-sound.conf
options snd slots=snd-hda-intel # svHJ.YhraNp3EzIA:SB1040 PCI Express alias snd-card-0 snd-hda-intel
It's only giving the card an alias name, I can't imagine that screwing anything up.
Yep. It's a matter of attitude, that's all.
No, it is a machine in production, people depend on it. I'm sure you are aware of the constraints.
Do they all depend on the sound working, 24x7 ? :-) -- Per Jessen, Zürich (24.2°C)
On 2022-06-26 21:28, Per Jessen wrote:
Carlos E. R. wrote:
On 2022-06-26 10:08, Per Jessen wrote:
Carlos E. R. wrote:
...
Elesar:~ # cat /etc/modprobe.d/50-sound.conf
options snd slots=snd-hda-intel # svHJ.YhraNp3EzIA:SB1040 PCI Express alias snd-card-0 snd-hda-intel
It's only giving the card an alias name, I can't imagine that screwing anything up.
Right.
Yep. It's a matter of attitude, that's all.
No, it is a machine in production, people depend on it. I'm sure you are aware of the constraints.
Do they all depend on the sound working, 24x7 ? :-)
They depend on the machine working, so I can not (format and) reinstall it. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
If I pull the jack half a millimeter, the "detection" fails and both play sound.
At that point I would highly suspect that the connections for the female have become bent and aren't working correctly, almost but not quite. I'd power it down, open the case, and give it a close eyeball inspection with a pair of needlenose, and maybe an ohm meter, close at hand. It maybe nothing that a bigger hammer can't cure.
Hello, In the Message; Subject : Re: [oS-EN] New sound problem Message-ID : <97e5f170-6e87-0b4c-c29b-8bb5367fc6cf@telefonica.net> Date & Time: Wed, 22 Jun 2022 20:38:14 +0200 [CER] == "Carlos E. R." <robin.listas@telefonica.net> has written: CER> On 2022-06-22 14:26, Masaru Nomiya wrote: [...] MN> > But I think about it, the phenomenon that Carlos is describing as a MN> > problem is a natural one．Rather, do we ever use a speaker and a MN> > headphone at the same time? MN> > MN> > So, I looked into it, and found that Soundblaster offers a tool for MN> > windows that allows we to mute the headphone when using the speaker, MN> > and vice versa when using the headphone. MN> > MN> > https://crates.io/crates/sbz-switch/3.0.0 CER> And that is what is not working correctly in Linux (I don't have Windows CER> to try). When I plug in the headphones at the front, the loudspeakers CER> should mute, and the headphones should work. Shouldn't we assume that because it doesn't work that way, Soundblaster is providing the tool? First of all, Soundblaster is not interested in Linux, and what you are using is a kernel driver, and what you say "should" be possible by creating a separate software? It's not about the driver. [...] CER> I could try another desktop. If you want to do it, go ahead. Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ "It should never be said that it is OK to ignore the theoretical as long as it becomes a tool." -- T. Mori (The original is in Japanese) --
Hello, PS. In the Message; Subject : Re: [oS-EN] New sound problem Message-ID : <87pmj048jg.wl-nomiya@galaxy.dti.ne.jp> Date & Time: Thu, 23 Jun 2022 07:50:43 +0900 [MN] == Masaru Nomiya <nomiya@galaxy.dti.ne.jp> has written: MN> Hello, MN> In the Message; MN> Subject : Re: [oS-EN] New sound problem MN> Message-ID : <97e5f170-6e87-0b4c-c29b-8bb5367fc6cf@telefonica.net> MN> Date & Time: Wed, 22 Jun 2022 20:38:14 +0200 MN> [CER] == "Carlos E. R." <robin.listas@telefonica.net> has written: CER> On 2022-06-22 14:26, Masaru Nomiya wrote: [...] MN> First of all, Soundblaster is not interested in Linux, and what you MN> are using is a kernel driver, and what you say "should" be possible by MN> creating a separate software? MN> It's not about the driver. If I were you, I would use pavucontrol (or pavucontrol-qt). Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ Think. -- The IBM slogan --
On 2022-06-23 02:10, Masaru Nomiya wrote:
Hello,
PS.
In the Message;
Subject : Re: [oS-EN] New sound problem Message-ID : <87pmj048jg.wl-nomiya@galaxy.dti.ne.jp> Date & Time: Thu, 23 Jun 2022 07:50:43 +0900
[MN] == Masaru Nomiya <nomiya@galaxy.dti.ne.jp> has written:
MN> Hello,
MN> In the Message;
MN> Subject : Re: [oS-EN] New sound problem MN> Message-ID : <97e5f170-6e87-0b4c-c29b-8bb5367fc6cf@telefonica.net> MN> Date & Time: Wed, 22 Jun 2022 20:38:14 +0200
MN> [CER] == "Carlos E. R." <> has written:
CER> On 2022-06-22 14:26, Masaru Nomiya wrote:
[...] MN> First of all, Soundblaster is not interested in Linux, and what you MN> are using is a kernel driver, and what you say "should" be possible by MN> creating a separate software?
MN> It's not about the driver.
If I were you, I would use pavucontrol (or pavucontrol-qt).
I already tried the former. It shows the headphones as playing, there is sound activity in the moving graph, but the headphones remain silent no matter if I crank their volume to max. There is a hiss in them, which proves they are connected to the hardware. I can switch, in pavucontrol, to the loudspeakers, but they also remain silent. It means that some software is silencing them both, and forcing this. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
On 23/06/2022 08:15, Carlos E. R. wrote:
On 2022-06-23 02:10, Masaru Nomiya wrote:
Hello,
PS.
In the Message;
Subject : Re: [oS-EN] New sound problem Message-ID : <87pmj048jg.wl-nomiya@galaxy.dti.ne.jp> Date & Time: Thu, 23 Jun 2022 07:50:43 +0900
[MN] == Masaru Nomiya <nomiya@galaxy.dti.ne.jp> has written:
MN> Hello,
MN> In the Message;
MN> Subject : Re: [oS-EN] New sound problem MN> Message-ID : <97e5f170-6e87-0b4c-c29b-8bb5367fc6cf@telefonica.net> MN> Date & Time: Wed, 22 Jun 2022 20:38:14 +0200
MN> [CER] == "Carlos E. R." <> has written:
CER> On 2022-06-22 14:26, Masaru Nomiya wrote:
[...] MN> First of all, Soundblaster is not interested in Linux, and what you MN> are using is a kernel driver, and what you say "should" be possible by MN> creating a separate software?
MN> It's not about the driver.
If I were you, I would use pavucontrol (or pavucontrol-qt).
I already tried the former. It shows the headphones as playing, there is sound activity in the moving graph, but the headphones remain silent no matter if I crank their volume to max.
There is a hiss in them, which proves they are connected to the hardware.
I can switch, in pavucontrol, to the loudspeakers, but they also remain silent.
It means that some software is silencing them both, and forcing this.
I remember having problems similar to this on my old laptop, but it's a few years ago and I don't recall if I ever found a perfect solution, or just things that sometimes worked erratically. It seemed that the audio got somehow reversed and plugging in to the headphone jack would mute it and vice-versa. Things were complicated by my having a full docking station with additional audio outs. What I do remember is that I frequently would have to open alsamixer in a terminal to fix it. By default when opening alsamixer I'd be presented with just the one slider due to PulseAudio. I'd then do F6 to select the soundcard. Somewhere along the line of audio outs I'd need to flip a switch or two, but I don't know which. gumb
Hello, In the Message; Subject : Re: [oS-EN] New sound problem Message-ID : <1786509c-8df3-a4bd-a04b-1c8c9b551193@telefonica.net> Date & Time: Thu, 23 Jun 2022 08:15:01 +0200 [CER] == "Carlos E. R." <robin.listas@telefonica.net> has written: CER> On 2022-06-23 02:10, Masaru Nomiya wrote: [...] MN> > If I were you, I would use pavucontrol (or pavucontrol-qt). CER> I already tried the former. It shows the headphones as playing, there is CER> sound activity in the moving graph, but the headphones remain silent no CER> matter if I crank their volume to max. CER> There is a hiss in them, which proves they are connected to the hardware. CER> I can switch, in pavucontrol, to the loudspeakers, but they also remain CER> silent. This is suspicious. CER> It means that some software is silencing them both, and forcing CER> this. I don't think so. Is there something wrong with the sound card.....? Regards & Good Night. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ "It should never be said that it is OK to ignore the theoretical as long as it becomes a tool." -- T. Mori (The original is in Japanese) --
On 2022-06-23 14:38, Masaru Nomiya wrote:
Hello,
In the Message;
Subject : Re: [oS-EN] New sound problem Message-ID : <1786509c-8df3-a4bd-a04b-1c8c9b551193@telefonica.net> Date & Time: Thu, 23 Jun 2022 08:15:01 +0200
[CER] == "Carlos E. R." <robin.listas@telefonica.net> has written:
CER> On 2022-06-23 02:10, Masaru Nomiya wrote: [...] MN> > If I were you, I would use pavucontrol (or pavucontrol-qt).
CER> I already tried the former. It shows the headphones as playing, there is CER> sound activity in the moving graph, but the headphones remain silent no CER> matter if I crank their volume to max.
CER> There is a hiss in them, which proves they are connected to the hardware.
CER> I can switch, in pavucontrol, to the loudspeakers, but they also remain CER> silent.
This is suspicious.
CER> It means that some software is silencing them both, and forcing CER> this.
I don't think so.
Is there something wrong with the sound card.....?
Who knows... Not important at this time. I will simply get a stereo extension cord, + usb extension cord, and forget about it. Not worth wasting more time on it. I just hoped this was something known and easy to correct. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
On 6/23/22 09:35, Carlos E. R. wrote:
Who knows... Not important at this time.
I will simply get a stereo extension cord, + usb extension cord, and forget about it. Not worth wasting more time on it.
I just hoped this was something known and easy to correct.
My bet is still a hardware issue, jack problem or short in one of the wires running though the cable. (or a driver issue misinterpreting the configuration) Most all of the old hardware stuff is programmed like a microcontroller looking at voltages on pins coming from the jack. If you have a jack or cord short issue that pulls voltage (either up or down) on a combination of pins that the driver doesn't handle in combination, it could very well give the symptoms you describe. From your description it sees the headphone-in connection (for lack of better words), but doesn't complete the switch of audio out from speakers to headphones (or it does, but due to a short all you get is a hiss). The wiggle and both on tells me that it loses the headphone-in signal at that point and restores audio though the speakers that is also (either due to card or cord or jack issue) sent though the headphone jack at at point. It could be something as boring as a bad capacitor on the card in the headphone circuit as well. None of which I can explain from afar, and I like your thought of just going the USB route, because it probably isn't worth trying to take a needle and multi-meter to check each path from the jack through the cord to the headphones. -- David C. Rankin, J.D.,P.E.
On 2022-06-23 17:22, David C. Rankin wrote:
On 6/23/22 09:35, Carlos E. R. wrote:
Who knows... Not important at this time.
I will simply get a stereo extension cord, + usb extension cord, and forget about it. Not worth wasting more time on it.
I just hoped this was something known and easy to correct.
My bet is still a hardware issue, jack problem or short in one of the wires running though the cable.
Nope.
(or a driver issue misinterpreting the configuration)
Yes.
Most all of the old hardware stuff is programmed like a microcontroller looking at voltages on pins coming from the jack. If you have a jack or cord short issue that pulls voltage (either up or down) on a combination of pins that the driver doesn't handle in combination, it could very well give the symptoms you describe.
From your description it sees the headphone-in connection (for lack of better words), but doesn't complete the switch of audio out from speakers to headphones (or it does, but due to a short all you get is a hiss). The wiggle and both on tells me that it loses the headphone-in signal at that point and restores audio though the speakers that is also (either due to card or cord or jack issue) sent though the headphone jack at at point. It could be something as boring as a bad capacitor on the card in the headphone circuit as well.
The wiggle shows that when the software does not see the headphones, the the headphones work. Move the headphones out a bit so that the detection switch is not activated, and things work. All the cables and connections are fine.
None of which I can explain from afar, and I like your thought of just going the USB route, because it probably isn't worth trying to take a needle and multi-meter to check each path from the jack through the cord to the headphones.
No, I'm not going the USB route. Confusion here. The active loudspeakers take power, and only power, via an USB connector on the back on the computer. They get the audio signal via the standard line-out jack on the back. So I need just a stereo extension cord, and an USB extension cord. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Hello, In the Message; Subject : Re: [oS-EN] New sound problem Message-ID : <925877c0-cbd0-0ec0-213f-a910a447ad46@suddenlinkmail.com> Date & Time: Thu, 23 Jun 2022 10:22:15 -0500 [DCR] == "David C. Rankin" <drankinatty@suddenlinkmail.com> has written: DCR> On 6/23/22 09:35, Carlos E. R. wrote: CER> > Who knows... Not important at this time. CER> > CER> > I will simply get a stereo extension cord, + usb extension cord, and CER> > forget about it. Not worth wasting more time on it. CER> > CER> > I just hoped this was something known and easy to correct. DCR> My bet is still a hardware issue, jack problem or short in one of the wires DCR> running though the cable. (or a driver issue misinterpreting the DCR> configuration) Most all of the old hardware stuff is programmed DCR> like a microcontroller looking [...] DCR> though the headphone jack at at point. It could be something as DCR> boring as a bad capacitor on the card in the headphone circuit DCR> as well. Thank you for the detailed explanation. The Sound Blaster X-Fi Xtreme Audio in question seems to be a difficult hardware to handle, and I found a description on debian's old official site that the driver snd-hda-intel was modified to be specialized for it. I question the recent trend of using snd-hda-intel driver to handle every sound chips. Regards, --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ "In a mobile phone metadata dataset of more than 40k people, it correctly identifies 52% of individuals based on their 2-hop interaction graph. We further show that the profiles learned by our method are stable over time and that 24% of people are still identifiable after 20 weeks. " -- 「Interaction data are identifiable even across long periods of time」 --
On 23/06/2022 00.50, Masaru Nomiya wrote:
Hello,
In the Message;
Subject : Re: [oS-EN] New sound problem Message-ID : <97e5f170-6e87-0b4c-c29b-8bb5367fc6cf@telefonica.net> Date & Time: Wed, 22 Jun 2022 20:38:14 +0200
[CER] == "Carlos E. R." <...> has written:
CER> On 2022-06-22 14:26, Masaru Nomiya wrote:
[...] MN> > But I think about it, the phenomenon that Carlos is describing as a MN> > problem is a natural one．Rather, do we ever use a speaker and a MN> > headphone at the same time? MN> > MN> > So, I looked into it, and found that Soundblaster offers a tool for MN> > windows that allows we to mute the headphone when using the speaker, MN> > and vice versa when using the headphone. MN> > MN> > https://crates.io/crates/sbz-switch/3.0.0
CER> And that is what is not working correctly in Linux (I don't have Windows CER> to try). When I plug in the headphones at the front, the loudspeakers CER> should mute, and the headphones should work.
Shouldn't we assume that because it doesn't work that way, Soundblaster is providing the tool?
No, I thought that the feature had been reverse engineered, after a decade :-D The headphones jack is useless without it. I seem to remember that it never worked. I used the socket in the back or a jack in the loudspeakers I used then.
First of all, Soundblaster is not interested in Linux, and what you are using is a kernel driver, and what you say "should" be possible by creating a separate software?
It's not about the driver.
"Should" as in machine can not make use of headphone jack without such a similar software feature. As you confirm this doesn't exist, I'll try get a extension cord from Amazon. Need a stereo jack extension cable plus an USB extension cable, this speaker set uses the USB for power.
[...] CER> I could try another desktop.
If you want to do it, go ahead.
I tried Plasma. I get a pop up message when I plug the headphones, but otherwise the problem is the same. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.3 (Legolas))
Carlos E. R. wrote:
And that is what is not working correctly in Linux (I don't have Windows to try). When I plug in the headphones at the front, the loudspeakers should mute, and the headphones should work.
This doesn't happen.
The loudspeakers go mute (correct), and the headphones play no sound (incorrect).
If I pull the jack half a millimeter, the "detection" fails and both play sound.
I wonder if that "detection" isn't a simple mechanical switch - in earlier days, it was certainly common enough on those minijack sockets. If you think it is a driver issue, you could try booting some live system (Knoppix, an older openSUSE etc). -- Per Jessen, Zürich (21.1°C)
On 23/06/2022 09.18, Per Jessen wrote:
Carlos E. R. wrote:
And that is what is not working correctly in Linux (I don't have Windows to try). When I plug in the headphones at the front, the loudspeakers should mute, and the headphones should work.
This doesn't happen.
The loudspeakers go mute (correct), and the headphones play no sound (incorrect).
If I pull the jack half a millimeter, the "detection" fails and both play sound.
I wonder if that "detection" isn't a simple mechanical switch - in earlier days, it was certainly common enough on those minijack sockets.
I'm almost sure it is. I could perhaps disable the cable, but if I do, the mixer will not show a volume control for the headphones.
If you think it is a driver issue, you could try booting some live system (Knoppix, an older openSUSE etc).
I remembered that this issue has been there since ever, so older openSUSE I tried all of them since 2009 or so. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.3 (Legolas))
Carlos E. R. wrote:
On 23/06/2022 09.18, Per Jessen wrote:
I wonder if that "detection" isn't a simple mechanical switch - in earlier days, it was certainly common enough on those minijack sockets.
I'm almost sure it is. I could perhaps disable the cable, but if I do, the mixer will not show a volume control for the headphones.
If you think it is a driver issue, you could try booting some live system (Knoppix, an older openSUSE etc).
I remembered that this issue has been there since ever, so older openSUSE I tried all of them since 2009 or so.
Hmmm. Usually such problems don't stay hidden for so long, but maybe. I googled "sb1040 sound blaster linux headphone jack", there are some hits, but nothing really promising. One suggests using another driver "snd_ctxfi", but it's quite an old post. -- Per Jessen, Zürich (22.7°C)
participants (12)
-
Bengt Gördén -
bent fender -
Bill Swisher -
Carlos E. R. -
Darryl Gregorash -
Dave Howorth -
David C. Rankin -
David Haller -
gumb -
Masaru Nomiya -
Patrick Shanahan -
Per Jessen