Bug 1214658

Summary:	I No Longer Can Monitor Computer Speaker Output
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	Bill Wayson <bill_wayson>
Component:	Sound	Assignee:	Takashi Iwai <tiwai>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	bill_wayson
Version:	Current
Target Milestone:	---
Hardware:	x86-64
OS:	openSUSE Tumbleweed
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	Where monitoring output would normally be selected Files requested by Takashi Iwai in comment 1

Description Bill Wayson 2023-08-27 21:33:18 UTC

Created attachment 869045 [details]
Where monitoring output would normally be selected

I used to stream audio to my computer's speakers, with the audio device configured as "Analog Stereo Duplex", and monitor the output and record it in Audacity.  The process is described at https://manual.audacityteam.org/man/tutorial_recording_computer_playback_on_linux.html.  This process still does work on this computer when I boot into and use Leap 15.5.  But sometime between July 31 and August 6, it stopped working under Tumbleweed.  I can no longer select "Monitor of Built-In Audio Analog Stereo" in pavucontrol-qt (see SelectingMonitor.png).  The option is listed, but clicking it does not change the recording source.  Under TW, I can record the speaker output by changing the audio playback device to "Analog Stereo Output".  Also, I can no longer monitor output from the HDMI audio device, either, under TW.  Selecting it does not "stick."

I do not know what other information (e.g. logs, etc.) would be helpful, but am happy to provide anything that is asked for.

Comment 1 Takashi Iwai 2023-08-30 14:46:22 UTC

Please give alsa-info.sh output from both working and non-working cases.
Run the script with --no-upload option, and attach the generated outputs on Bugzilla (use attachments).

Also, please give the output of dmesg from both working and non-working cases, too.

Comment 2 Bill Wayson 2023-08-30 21:33:05 UTC

Created attachment 869137 [details]
Files requested by Takashi Iwai in comment 1

@Takashi, the files are attached as Comment1Files.zip.

Comment 3 Takashi Iwai 2023-08-31 14:43:31 UTC

Thanks.  The difference might be rather the sound sever you're using; on Leap 15.5, you're using PulseAudio, while pipewire is used on TW.
pipewire provides the compatibility with PulseAudio, but the monitoring feature might be differently implemented.

You can still switch back to pulseaudio on TW, too.  Replace pipewire-pulseaudio with puleaudio package, and it'll lead to replacements of a few relevant packages.

Comment 4 Bill Wayson 2023-08-31 18:02:54 UTC

Thank you, Takashi.  I hear what you are saying about the sound server difference, and I do appreciate the tip on switching to pulseaudio in TW.  I am happy to try that if it helps troubleshoot this issue.

I will just emphasize that I did not knowingly choose the sound server systems for either Leap ot TW.  I just let the systems, from installation through updates, do the choosing for me.  I think TW has been undergoing a change of sound support to being pipewire-based, and maybe something changed a few weeks ago in TW that exposed an unimplemented feature.

Comment 5 Takashi Iwai 2023-09-04 15:49:42 UTC

The recent TW already switched the default installation with pipewire, IIRC, so it's no surprise.  Note that pipewire is in general a better choice nowadays as it's been more actively developed.  I asked to switch back to PulseAudio just for confirming whether it's the behavior difference between PA and PW.

Comment 6 Bill Wayson 2023-10-01 23:17:00 UTC

(In reply to Takashi Iwai from comment #5)
> The recent TW already switched the default installation with pipewire, IIRC,
> so it's no surprise.  Note that pipewire is in general a better choice
> nowadays as it's been more actively developed.  I asked to switch back to
> PulseAudio just for confirming whether it's the behavior difference between
> PA and PW.

I'm sorry, Takashi.  I missed this comment.  Sometime during the week of September 10, 2023, my issue went away.  My guess is an update.  For a couple of weeks or more, I've been able to switch at will, back and forth using pavucontrol-qt, between recording the actual line input and the monitor of both the Analog Stereo Duplex output and Digital Stereo (HDMI) Output devices.  So, the expected behavior has been restored.  Unless you'd like me to do something, this report can be closed, as far as I am concerned.  Thanks for your attention and time.

(Now, if I could only figure out why only the right channel plays on the HDMI output, but both channels play on the Analog Stereo Duplex output.  It has been a long time since I've had this issue, and I've found very little written about this issue on the Internet.)

Comment 7 Takashi Iwai 2023-10-09 06:44:58 UTC

Thanks for the update. Then let's close the bug happily :)