Bug 206873
|
Description
vitkor
2020-03-18 04:07:33 UTC
Same here on MSI TRX40. SPDIF and front pannel (mic/headphones) as well as back panel mic don't work. Issues with error in dmesg solved by patches from https://bugzilla.kernel.org/show_bug.cgi?id=206543 Alsainfo attached. Is there any other information needed? Created attachment 288301 [details]
alsa-info
It seems that the USB-audio device gives 4 individual streams. Could you figure out which one corresponds to what output? In your case, the card #3 is USB-audio, so you can try like aplay -Dhw:3,0 foo.wav aplay -Dhw:3,1 foo.wav and so on. Hm. aplay -Dhw:3,0 ./1.wav gives error aplay: main:828: audio open error: Device or resource busy. Possibly it's a line out occupied by pulseaudio aplay -Dhw:3,1 ./1.wav gives sound in front panel headephones. aplay -Dhw:3,2 ./1.wav gives no sound aplay -Dhw:3,3 ./1.wav gives no sound For testing with aplay and arecord, disable PA, e.g. pasuspender -- aplay -Dhw:3,0 foo.wav Also check the recording as well. (BTW hw:3,3 might not work for recording.) Then list up which stream corresponds which actual I/O in a table. Last but not least, please give lsusb -v output, too. also it looks like all fine in alsa. Takashi, thanks for help. I found that arecord -Dhw:3,2 records sound from front mic and arecord -Dhw:3,1 from back mic. Looks like it's a pulseaudio issue then? And one another thing: please run alsactl -f /tmp/somefile store as root, and attach the generated file to Bugzilla. By some reason this wasn't included in alsa-info.sh output. aplay -Dhw:3,0 ./1.wav - is a front output (line out) alsactl: get_control:256: Cannot read control '0,0,0,PCM - Output Jack,0': Broken pipe (In reply to Takashi Iwai from comment #8) > And one another thing: please run > alsactl -f /tmp/somefile store > as root, and attach the generated file to Bugzilla. > By some reason this wasn't included in alsa-info.sh output. sudo alsactl -f /tmp/somefile store alsactl: get_control:256: Cannot read control '0,0,0,PCM - Output Jack,0': Broken pipe No file somefile exist (In reply to Denis from comment #7) > also it looks like all fine in alsa. Takashi, thanks for help. > I found that arecord -Dhw:3,2 records sound from front mic and arecord > -Dhw:3,1 from back mic. > Looks like it's a pulseaudio issue then? Partly yes, but partly a driver problem. The USB-audio is a bit hard to provide the proper stream assignment, and for this kind of complex example, we'd need a dedicated UCM profile, so that PA can understand which stream to take. I can create a UCM profile once after figuring out the role of each stream. This might need another change in the kernel side for specifying the UCM profile name, too, but it should be a simple change on top of the current patch set. Got error in dmesg: connectors status: req = 0x81, wValue = 0x200, wIndex = 0xd00, type = 0 [ 2348.390558] usb 7-5: cannot get connectors status: req = 0x81, wValue = 0x200, wIndex = 0xd00, type = 0 (In reply to Denis from comment #10) > sudo alsactl -f /tmp/somefile store > alsactl: get_control:256: Cannot read control '0,0,0,PCM - Output Jack,0': > Broken pipe > > No file somefile exist OK, now that explains. Then try to set a module option ignore_ctl_error=1 to snd-usb-audio module. Usually create a module config file, e.g. /etc/modprobe.d/50-usb-audio.conf, containing the following line options snd-usb-audio ignore_ctl_error=1 Then reload the module or reboot. This should ignore the mixer error and get some results from alsactl, I hope. This will leave some repeated error messages, and they will give us hints how the firmware is broken. It seems that the jack detection doesn't work as expected, at least, judging from the error message... It don't work. I tryed to do this but got same error and no file created. I also tryed to directly specify option in modprobe call: modprobe snd_usb_audio ignore_ctl_error=1 But still have same error in dmesg and no file created. Can I somehow check that it was applyed? Looks like it was applied correctly: cat /sys/module/snd_usb_audio/parameters/ignore_ctl_error Y Then try the patch below. This should make the option effective. Created attachment 288303 [details]
Patch to ignore ctl error
It doesn't help. Still no file and same error. Created attachment 288305 [details]
lsusb -v
Attaching lsusb -v
Audio is
Bus 007 Device 003: ID 0db0:0d64 Micro Star International USB Audio
Created attachment 288307 [details]
lsusb -v 2>&1
Reuploaded lsusb. To include errors that happens.
OK, try the following one instead of the previous patch. Also, please give the contents of /proc/asound/card3/stream* files, too. Created attachment 288313 [details]
Revised patch to ignore ctl error
Created attachment 288325 [details]
/proc/asound/card3/stream*
Created attachment 288327 [details]
alsactl
It works now.
Following errors logged:
[12556.120124] usb 7-5: cannot get connectors status: req = 0x81, wValue = 0x200, wIndex = 0xd00, type = 0
[12556.120745] usb 7-5: cannot get connectors status: req = 0x81, wValue = 0x200, wIndex = 0xe00, type = 0
[12556.121495] usb 7-5: cannot get connectors status: req = 0x81, wValue = 0x200, wIndex = 0xf00, type = 0
[12556.121868] usb 7-5: cannot get connectors status: req = 0x81, wValue = 0x200, wIndex = 0xa00, type = 0
[12556.122633] usb 7-5: cannot get connectors status: req = 0x81, wValue = 0x200, wIndex = 0xb00, type = 0
[12556.123250] usb 7-5: cannot get connectors status: req = 0x81, wValue = 0x200, wIndex = 0xc00, type = 0
[12556.123494] usb 7-5: cannot get connectors status: req = 0x81, wValue = 0x200, wIndex = 0x1200, type = 0
OK, below are four patches for covering those response errors, including the previous test fix patch. Please check whether this makes the errors go away, and give alsa-info.sh output again, as well as streams* proc files. Created attachment 288339 [details]
Patch #1
Created attachment 288341 [details]
Patch #2
Created attachment 288343 [details]
Patch #3
Created attachment 288345 [details]
Patch #4
Created attachment 288347 [details]
alsa-info
Alsa info. No errors while running.
Created attachment 288349 [details]
/proc/asound/card3/stream*
Just checked stream info for record: stream0 - line in stream1 - back microphone stream2 - front microphone Playback: stream0 - line out stream1 - front headphones streams2&3 - unknown. Don't have way to check TOS link Thanks! One more favor: try to run "alsactl monitor" and plug/unplug the jacks. Do you see any events shown? Created attachment 288353 [details]
alsa-info from TRX40 AORUS PRO WIFI
Here ist the output from alsa-info for the TRX40 AORUS PRO WIFI The front panel doesn't work. However can't check if the TOS Link port works. I already applied the patches from bug 206543. Rear mic: node hw:3, #12 (0,0,0,Rear Mic-In - Input Jack,0) VALUE node hw:3, #23 (0,0,0,Speaker - Output Jack,0) VALUE Front headphones: node hw:3, #8 (0,0,0,Line-In - Input Jack,0) VALUE node hw:3, #8 (0,0,0,Line-In - Input Jack,0) VALUE Front mic: node hw:3, #16 (0,0,0,Front Mic-In - Input Jack,0) VALUE node hw:3, #23 (0,0,0,Speaker - Output Jack,0) VALUE node hw:3, #16 (0,0,0,Front Mic-In - Input Jack,0) VALUE node hw:3, #23 (0,0,0,Speaker - Output Jack,0) VALUE Can confirm that Toslink works on TRX40 AORUS PRO WIFI after attaching those 4 patches and running: aplay -Dhw:3,2 ./test.wav I get sound from Toslink. Does not work with pulseaudio yet. (In reply to Takashi Iwai from comment #29) > Created attachment 288345 [details] > Patch #4 After applying all 4 patches the audio ist working on the TRX40 AORUS PRO WIFI. (On all ports including S/PDIF) aplay -l | grep USB card 1: Audio [USB Audio], device 0: USB Audio [USB Audio] card 1: Audio [USB Audio], device 1: USB Audio [USB Audio #1] card 1: Audio [USB Audio], device 2: USB Audio [USB Audio #2] card 1: Audio [USB Audio], device 3: USB Audio [USB Audio #3] aplay -D plughw:1,0 test.wav Back speaker aplay -D plughw:1,1 test.wav Front speaker/headphones aplay -D plughw:1,2 test.wav S/PDIF out aplay -D plughw:1,3 test.wav S/PDIF out arecord -l | grep USB card 1: Audio [USB Audio], device 0: USB Audio [USB Audio] card 1: Audio [USB Audio], device 1: USB Audio [USB Audio #1] card 1: Audio [USB Audio], device 2: USB Audio [USB Audio #2] arecord -f dat --device="hw:1,0" test1.wav Back line in arecord -f dat --device="hw:1,1" test2.wav Back mic arecord -f dat --device="hw:1,2" test3.wav Front mic Thanks! The information so far shows that both boards have the same configuration, hence likely the same quirk can be applied.
Below is another patch on top of the previous four fixes. This will rename the device appearance and also rename some mixer controls to match with the actual roles. After the patch, please try to run like
alsamixer -c3
(or with a different card number corresponding to the device), and check the mixer control really matches with the given I/O.
Please give alsa-info.sh output after the patch.
Then, the next two files are UCM profiles for the new device. It'll work together with the 5th patch. Create /usr/share/alsa/ucm/Realtek-ALC1220-VB-Desktop directory, and copy two files (Realtek-ALC1220-VB-Desktop.conf and HiFi.conf) onto the directory.
% mkdir /usr/share/alsa/ucm/Realtek-ALC1220-VB-Desktop
% cp Realtek-ALC1220-VB-Desktop.conf /usr/share/alsa/ucm/Realtek-ALC1220-VB-Desktop/
% cp HiFi.conf /usr/share/alsa/ucm/Realtek-ALC1220-VB-Desktop/
After installing UCM profiles, re-login to restart PulseAudio. If everything works as expected, you should have PA profile to switch to different I/Os.
Created attachment 288363 [details]
Patch #5 (testing)
Created attachment 288365 [details]
Realtek-ALC1220-VB-Desktop.conf
Created attachment 288367 [details]
HiFi.conf
Note that UCM profiles are still incomplete, they could have the jack detection. Also, for the newer alsa-lib version, UCMv2 profiles are needed, instead. Created attachment 288371 [details]
alsa-info
Namings in alsamixer becomes invalid after this patch. Will check later recording part. But on line out (front, rear, ceneter, woofer, side) I have mark "headphone"
Also pulseaudio didn't see different devices (no way to select it) it only shows "headphones" and it means - output on line out.
Ouch. Was wrong folder name. Now i have following: E: [pulseaudio] alsa-ucm.c: [Speaker] Invalid JackControl value: "" E: [pulseaudio] alsa-ucm.c: Assertion 'jack' failed at modules/alsa/alsa-ucm.c:1783, function device_set_jack(). Aborting. Strange, the mixer mapping doesn't seem take effect at all. Could you apply the following debug patch and give the dmesg output? It should print more lines with "XXX: ...." Created attachment 288373 [details]
debug patch
Erm, scratch my previous comment, I looked at a wrong (old) entry. Now, checking the actual result, I found that HiFi.conf won't work as expected. Also it contained a spurious line that caused an error. Will update. Sorry, correcting my statement again. The latest output also doesn't look right. So please try the patch in comment 47 on top of the patch#5 and give dmesg output. Here it is:
[ 3483.835103] XXX mapping found for db00d64
[ 3483.835107] XXX find_map: no map matched for 7
[ 3483.836793] XXX find_map: no map matched for 19
[ 3483.838403] XXX find_map: no map matched for 19
[ 3483.855307] XXX find_map: map (null) matched 19
[ 3483.855312] XXX find_map: no map matched for 8
[ 3483.857271] XXX find_map: no map matched for 20
[ 3483.859163] XXX find_map: no map matched for 20
[ 3483.875538] XXX find_map: no map matched for 9
[ 3483.877657] XXX find_map: no map matched for 21
[ 3483.879656] XXX find_map: no map matched for 21
[ 3483.896284] XXX find_map: no map matched for 22
[ 3483.898277] XXX find_map: no map matched for 22
[ 3483.916152] XXX find_map: no map matched for 16
[ 3483.916158] XXX find_map: no map matched for 23
[ 3483.918153] XXX find_map: no map matched for 23
[ 3483.934774] XXX find_map: no map matched for 17
[ 3483.934781] XXX find_map: no map matched for 24
[ 3483.936773] XXX find_map: map (null) matched 18
[ 3483.937300] usbcore: registered new interface driver snd-usb-audio
Am i right that
{ /* MSI TRX40 Creator */
.id = USB_ID(0x0db0, 0x0d64),
.map = trx40_mobo_map,
},
must be added to usbmix_ctl_maps?
I have to apply this patch manually since i use 5.6.0 and i failed to apply
Created attachment 288375 [details]
Fixed HiFi conf
With this HiFI.conf pulseaudio starts and shows different devices for each output.
(In reply to Denis from comment #50) > Am i right that > { /* MSI TRX40 Creator */ > .id = USB_ID(0x0db0, 0x0d64), > .map = trx40_mobo_map, > }, > must be added to usbmix_ctl_maps? > I have to apply this patch manually since i use 5.6.0 and i failed to apply Damn, yes, that's mandatory! At best, pull for-linus branch of my sound.git tree onto your 5.6 git tree. Otherwise you might have missed some other bits. % cd linux-5.6.0-git % git checkout -b usb-audio-devel % git pull git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-linus Then apply the patch#5 on its top. So, please keep the code up-to-date. Otherwise we'll waste too long hours. And below is an almost full-featured HiFi.conf. This assumes that the mixer control renames and the jack detection working as expected. If the shown jack state doesn't match with the actual state, remove or comment out "JackControl" lines in HiFi.conf. Created attachment 288377 [details]
Revised HiFi.conf
Created attachment 288391 [details]
alsa-info after patch #5 on TRX40 AORUS PRO WIFI
(In reply to Takashi Iwai from comment #54) > Created attachment 288377 [details] > Revised HiFi.conf Pulseaudio shows following output devices: - S/PDIF out - Back Speaker (Front speaker/headphones is missing) and input: - Front microphone - Back microphone - Back line in Jack detection doesen't work. Selecting "S/PDIF out" works but the audio is stuttering. "aplay -D plughw:1,2 test.wav" works without any problems. I can't set "Back Microphone" and "Back line in" as input device. (In reply to acs from comment #56) > (In reply to Takashi Iwai from comment #54) > > Created attachment 288377 [details] > > Revised HiFi.conf > > > Pulseaudio shows following output devices: > - S/PDIF out > - Back Speaker > (Front speaker/headphones is missing) > > and input: > - Front microphone > - Back microphone > - Back line in OK, then could you try without "JackControl" lines in HiFi.conf? Doesn't it change the situation? If it's still same, try HiFi.conf in comment 51 instead. > Jack detection doesen't work. Does the plug/unplug trigger any event when you watching via "alsactl monitor"? At best check it with disabling PA, e.g. run it with "pasuspender -- " wrapper. > Selecting "S/PDIF out" works but the audio is stuttering. "aplay -D > plughw:1,2 test.wav" works without any problems. Get the /proc/asound/card1/pcm2p/sub0/* file contents during playback of both aplay and PA. The difference might depend on the parameters. > I can't set "Back Microphone" and "Back line in" as input device. Try modifying or replacing HiFi.conf as above. (In reply to Takashi Iwai from comment #57) > (In reply to acs from comment #56) > > (In reply to Takashi Iwai from comment #54) > > > Created attachment 288377 [details] > > > Revised HiFi.conf > > > > > > Pulseaudio shows following output devices: > > - S/PDIF out > > - Back Speaker > > (Front speaker/headphones is missing) > > > > and input: > > - Front microphone > > - Back microphone > > - Back line in > > OK, then could you try without "JackControl" lines in HiFi.conf? Doesn't it > change the situation? > > If it's still same, try HiFi.conf in comment 51 instead. > > > Jack detection doesen't work. > > Does the plug/unplug trigger any event when you watching via "alsactl > monitor"? > At best check it with disabling PA, e.g. run it with "pasuspender -- " > wrapper. > > > Selecting "S/PDIF out" works but the audio is stuttering. "aplay -D > > plughw:1,2 test.wav" works without any problems. > > Get the /proc/asound/card1/pcm2p/sub0/* file contents during playback of > both aplay and PA. The difference might depend on the parameters. > > > I can't set "Back Microphone" and "Back line in" as input device. > > Try modifying or replacing HiFi.conf as above. Removing JackControl doesn't help. I tried the config form comment 51 and PA displays the inputs and outputs correctly. Running "pasuspender -- alsactl monitor" and plugging/unplugging does not trigger any event. The front speaker has the same problem as S/PDIF. I will attach the contents of /proc/asound/card1/pcm2p/sub0/ Created attachment 288403 [details]
contents of /proc/asound/card1/pcm2p/sub0/
(In reply to acs from comment #59) > Created attachment 288403 [details] > contents of /proc/asound/card1/pcm2p/sub0/ The obvious difference is the sample rate. If you change PA setup to use 48kHz, does it change the behavior? I have two systems with ASRock TRX40 (AMD Ryzen Threadripper 3970x and 3990x), and I'm having the same issue. I can't get the Front Audio to Work. OS: Ubuntu 18.04 Server and CentOS 8.1. Initially, I taught was a kernel issue, and I tested Ubuntu Fedora 31 with kernel 5.5, and Ubuntu 20.04 Beta, and still, I couldn't get the front audio to work. Did you guys have a fix for this? Would you guys, please, give an overview of how to fix this problem. I appreciate. (In reply to Takashi Iwai from comment #60) > (In reply to acs from comment #59) > > Created attachment 288403 [details] > > contents of /proc/asound/card1/pcm2p/sub0/ > > The obvious difference is the sample rate. If you change PA setup to use > 48kHz, does it change the behavior? Changing the rate is not possible. The file overwrites it. I also tried it with a 48kHz file. Got the same error. Is there a way to force it? $ pacat --rate=48000 --file-format=wav --fix-format test.wav Warning: specified sample specification will be overwritten with specification from file. (In reply to acs from comment #62) > (In reply to Takashi Iwai from comment #60) > > (In reply to acs from comment #59) > > > Created attachment 288403 [details] > > > contents of /proc/asound/card1/pcm2p/sub0/ > > > > The obvious difference is the sample rate. If you change PA setup to use > > 48kHz, does it change the behavior? > > Changing the rate is not possible. The file overwrites it. I also tried it > with a 48kHz file. Got the same error. You need to change the PA setup and restart PA. It should be available via /etc/pulse/client.conf or the local one under home. Also, you may try 44.1kHz WAV file playing via aplay, too. Takashi, (In reply to Takashi Iwai from comment #52) > Damn, yes, that's mandatory! > > At best, pull for-linus branch of my sound.git tree onto your 5.6 git tree. > Otherwise you might have missed some other bits. > > % cd linux-5.6.0-git > % git checkout -b usb-audio-devel > % git pull git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > for-linus > > Then apply the patch#5 on its top. > > So, please keep the code up-to-date. Otherwise we'll waste too long hours. Thank you. I tryed this and now got following results: alsamixer got outputs and inputs renamed Tested pulseaudio with HiFi.conf from #51 Front panel headphones works fine. Back line-out works fine Back line-in works fine Back mic works fine Front mic untested Using latest HiFi.conf: Jack detection for front headphones don't work. alsactl monitor says: node hw:1, #8 (0,0,0,Line Jack,0) VALUE -> remove node hw:1, #8 (0,0,0,Line Jack,0) VALUE -> insert Front mic: Remove: node hw:1, #16 (0,0,0,Front Mic Jack,0) VALUE node hw:1, #23 (0,0,0,Speaker Jack,0) VALUE Insert: node hw:1, #16 (0,0,0,Front Mic Jack,0) VALUE node hw:1, #23 (0,0,0,Speaker Jack,0) VALUE Back line-out + line-in: Remove: node hw:1, #8 (0,0,0,Line Jack,0) VALUE node hw:1, #23 (0,0,0,Speaker Jack,0) VALUE Insert: node hw:1, #8 (0,0,0,Line Jack,0) VALUE node hw:1, #23 (0,0,0,Speaker Jack,0) VALUE Back line-out alone: (insert only) node hw:1, #8 (0,0,0,Line Jack,0) VALUE node hw:1, #23 (0,0,0,Speaker Jack,0) VALUE Created attachment 288421 [details]
alsa-info
Card moved to Card1
Found another issue.
When PA set to S32LE got a lot of stuttering.
When it set to S24LE - it some kind of works in headphones, but on back line out it switches right to S16LE.
Syslog full of following messages from PA:
(I grabbed it from source since it's not in english in system log)
"pa_log(_("ALSA woke us up to write new data to the device, but there was actually nothing to write.\n"
"Most likely this is a bug in the ALSA driver '%s'. Please report this issue to the ALSA developers.\n"
"We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail."),
My configuration for PA demon if it matters: avoid-resampling = yes default-sample-format = S24LE default-sample-rate = 192000 alternate-sample-rate = 48000 deferred-volume-safety-margin-usec = 1 According to /proc/asound/card1/stream[0-1] this card support S32LE with 192000kHz (In reply to Takashi Iwai from comment #63) > (In reply to acs from comment #62) > > (In reply to Takashi Iwai from comment #60) > > > (In reply to acs from comment #59) > > > > Created attachment 288403 [details] > > > > contents of /proc/asound/card1/pcm2p/sub0/ > > > > > > The obvious difference is the sample rate. If you change PA setup to use > > > 48kHz, does it change the behavior? > > > > Changing the rate is not possible. The file overwrites it. I also tried it > > with a 48kHz file. Got the same error. > You need to change the PA setup and restart PA. It should be available via > /etc/pulse/client.conf or the local one under home. > > Also, you may try 44.1kHz WAV file playing via aplay, too. Adding "default-sample-rate = 48000" in "/etc/pulse/daemon.conf" fixes the problem with S/PDIF. Front speakers have no sound. Aplay worked with both files 44100 and 48000. Before the front speakers also worked with aplay. Right now it's not working at all. It changed from stuttering to no sound. Undoing the changes doesn't change anything. According to Wikipedia 48 kHz and 44.1 kHz is the usual sample rate of this standard and 48kHz being the most common. It seems that my end device only supports 48 kHz and not 44.1 kHz. This made it stutter. Thank you for your feedback. So it's a problem with 44.1kHZ that happens with PA, which indicates a problem being specific to a small period and buffer size. Looking at stream* proc contents, it seems that only SPDIF output shows the support of 44.1kHZ. This looks already suspicious. We can reduce the 44.1kHZ support there. Also, the support of S32_LE is doubtful. Usually USB-audio device doesn't support this format but only S24_3LE (3 bytes format). This needs another quirk. And, the matching of the jack event and the actual I/O looks strange, too. It implies that my guess work isn't quite right. Could you check the rest mixer elements? That is, run "alsamixer -c3" (or other card number to fit with yours), adjust the mixer element there, and check whether the name really matches. e.g. mute "Front Headphone" and whether the headphone gets muted. If the mapping of those elements is also wrong, at least it's consistent and we can correct them logically. So, please try to figure out which unit id corresponds to actually what I/O. That's the interesting part. alsamixer looks like it have correct names: speaker front -> controls line-out front headphone -> controls headphone Mic -> controls back microphone I'll recheck other controls later, but I think I checked it couple of days ago and all other controls works correctly. Then the incorrect mapping is only about the input/output terminals? Interesting. It might be that the firmware submits values that aren't compliant?
Please try the patch below and check what raw values are reported from the device per different plug/unplug.
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -3258,6 +3258,8 @@ static void snd_usb_mixer_interrupt_v2(struct usb_mixer_interface *mixer,
__u8 channel = value & 0xff;
unsigned int count = 0;
+ pr_info("XXX mixer interrupt: index=0x%04x, control=0x%04x\n",
+ index, value);
if (channel >= MAX_CHANNELS) {
usb_audio_dbg(mixer->chip,
"%s(): bogus channel number %d\n",
Great, thanks Iwai & Denis. ;-) I finally discover the audio sound quality of this USB-card. Front: headphone in/out: dmesg: [ 1182.258851] XXX mixer interrupt: index=0x0700, control=0x0202 [ 1182.274845] XXX mixer interrupt: index=0x0b00, control=0x0202 [ 1183.186662] XXX mixer interrupt: index=0x0700, control=0x0202 [ 1183.202654] XXX mixer interrupt: index=0x0b00, control=0x0202 Alsactl: node hw:3, #8 (0,0,0,Line Jack,0) VALUE node hw:3, #8 (0,0,0,Line Jack,0) VALUE Back: front speaker, center speaker, rear speaker got same results: [ 1260.738832] XXX mixer interrupt: index=0x0700, control=0x0202 [ 1260.754821] XXX mixer interrupt: index=0x1000, control=0x0202 node hw:3, #8 (0,0,0,Line Jack,0) VALUE node hw:3, #23 (0,0,0,Speaker Jack,0) VALUE line-in input: [ 1435.087240] XXX mixer interrupt: index=0x0700, control=0x0202 [ 1435.103234] XXX mixer interrupt: index=0x1000, control=0x0202 node hw:3, #8 (0,0,0,Line Jack,0) VALUE node hw:3, #23 (0,0,0,Speaker Jack,0) VALUE mic in: [ 1492.275567] XXX mixer interrupt: index=0x0800, control=0x0202 [ 1492.291561] XXX mixer interrupt: index=0x1000, control=0x0202 node hw:3, #12 (0,0,0,Mic Jack,0) VALUE node hw:3, #23 (0,0,0,Speaker Jack,0) VALUE Thanks. It indicates that the detection is reported against the PCM terminal. And reading from the PCM terminal caused errors as already found in the report, so we disabled them. What a broken device. Below is another workaround. This should delegate the jack detection to the associated terminal, so the real jack should be triggered. It'll still show the notification of the unrelated jack like Speaker Jack, but it must be basically harmless as long as the reading value works. Try the patch below on top of other patches (modulo the previous debug one), and check alsactl monitor. Also, please check the output of "amixer -c1 contents" (the 1 is the card number you need to specify), and verify whether the value of the corresponding Jack control changes or not. If the Jack value doesn't change per plug/uplug, basically we can forget about the jack detection. OTOH, if it reports the proper state, we still have a chance for a full feature. Created attachment 288463 [details]
Patch for delegated jack detection
Will check it later, thank you. For now I found another issue with headphones. After some time it becomes to made robovoice. At start (pulseaudio -k) all goes fine but with time I start getting noise in headphones that becomming worse with the time. If I switch to front speakers (in rear line-out) all start to sound well. Created attachment 288485 [details]
dmesg snd-usb-audio crash
Got crash on latest patch.
Oops sorry there was one place I overlooked about the NULL check. Try the revised patch below instead. Created attachment 288493 [details]
Revised patch for delegated jack detection
Tryed with latest patch. alsactl still shows incorrect events but amixer -c3 correctly shows Jack alsactl: node hw:3, #8 (0,0,0,Line Jack,0) VALUE node hw:3, #8 (0,0,0,Line Jack,0) VALUE amixer -c3 contents | grep Jack -A2 numid=27,iface=CARD,name='Front Headphone Jack' ; type=BOOLEAN,access=r-------,values=1 : values=off numid=27,iface=CARD,name='Front Headphone Jack' ; type=BOOLEAN,access=r-------,values=1 : values=on And the current state is correct: numid=27,iface=CARD,name='Front Headphone Jack' ; type=BOOLEAN,access=r-------,values=1 : values=on numid=16,iface=CARD,name='Front Mic Jack' ; type=BOOLEAN,access=r-------,values=1 : values=off -- numid=8,iface=CARD,name='Line Jack' ; type=BOOLEAN,access=r-------,values=1 : values=off numid=12,iface=CARD,name='Mic Jack' ; type=BOOLEAN,access=r-------,values=1 : values=on numid=23,iface=CARD,name='Speaker Jack' ; type=BOOLEAN,access=r-------,values=1 : values=on Also looks like pulseaudio correctly captures current jack state (In reply to Denis from comment #81) > Tryed with latest patch. > alsactl still shows incorrect events but amixer -c3 correctly shows Jack > alsactl: > node hw:3, #8 (0,0,0,Line Jack,0) VALUE > node hw:3, #8 (0,0,0,Line Jack,0) VALUE Hm, showing this spurious Line Jack event is expected, but it seems still missing the real event for Front Headphone Jack. Could you apply the debug patch on top and get the kernel log while plugging/unplugging different jacks? Created attachment 288505 [details]
Yet more debug patch
Just to clarify. I use kernel from comment 52(5.6.0 + branch you pointed me at) and didn't made any updates from monday. All patches applyed. If I need to update kernel at some point - please point me. Also I only installed sound related modules from new kernel and use 5.6.0 as main kernel and all other modules. Headphone remove+insert: node hw:3, #8 (0,0,0,Line Jack,0) VALUE node hw:3, #8 (0,0,0,Line Jack,0) VALUE [26974.656259] XXX creating a phantom ctl for 13 -> 7 [26974.670633] XXX creating a phantom ctl for 14 -> 8 [26974.685254] XXX creating a phantom ctl for 15 -> 9 [26974.717478] usbcore: registered new interface driver snd-usb-audio [26995.419512] XXX mixer interrupt: index=0x0700, control=0x0202 [26995.435507] XXX mixer interrupt: index=0x0b00, control=0x0202 [26997.163151] XXX mixer interrupt: index=0x0700, control=0x0202 [26997.179145] XXX mixer interrupt: index=0x0b00, control=0x0202 Regarding robovoice in headphones. Looks like 192kHz don't work with front panel connectors. Once I switched to 48kHz s24le - sound goes fine. Can this be related to some driver issues? Thanks for the test result. Now I found that the logic I used isn't fully applicable to all phantom terminals; the PCM input terminal has no associated terminal ID. I'll work on another way to solve it. About the remaining workarounds: - Looks like we should apply only 48kHz for the stable operations; one may leave 192khz support for the back line-out, but maybe it's simpler to apply to all streams - Also support of S32 format should be dropped, only S16 and S24_3LE - The last stream#3 is for the USB format type III, aka IEC958 streams mostly for AC3/DTS/etc. This isn't clear yet whether the normal SPDIF PCM stream can be used for that purpose, too (I guess so). We can leave this for now. I'm going to check what is supported on windows for this card. Is there anything that I can collect from windows system that may help us here? One thing we haven't tested at all is the multi-channels in the back line-out. The back line-out declares the support up to 8 channels. Could you try to play with more channels via speaker-test? pasuspender -- speaker-test -Dhw:x,0 -c8 -b 100000 Below are the revised patch set, patch #5, #6 and #7. It replaces the patches in comment 40 and 80. You can drop other debug patches. The whole patches are found in topci/usb-trx40 branch of sound.git tree https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/ Created attachment 288517 [details]
Patch #5
Created attachment 288519 [details]
Patch #6
Created attachment 288521 [details]
Patch #7
Takashi, am I correct that I can just use https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/ and don't apply any patches to it? Yes, the topic/usb-trx40 branch of that git repo can be used without any patches (not for-linus branch). At best, pull the branch into the upstream 5.6 tree as mentioned in comment 52, but use topic/usb-trx40 instead of for-linus. Still no luck Front headphones: alsactl monitor node hw:3, #8 (0,0,0,Line Jack,0) VALUE node hw:3, #8 (0,0,0,Line Jack,0) VALUE amixer show correct state -c8 front right is a lineout front-left lfe is on lineout front-right and rear right front right - rear left rear right - center left front right center - center right -c6 channel - jack FR - CR RR - CL RR - RR LFE - RL FR - FL LFE - FR Also this driver is completly broken. Even on headphones it provides some creepy sounds Also it somehow affects nvidia driver so it freezes. And i see strange messages in dmesg: [ 43.527629] retire_capture_urb: 46 callbacks suppressed [ 48.615592] retire_capture_urb: 32 callbacks suppressed [ 53.681552] retire_capture_urb: 884 callbacks suppressed [ 58.918478] retire_capture_urb: 1015 callbacks suppressed [ 63.944446] retire_capture_urb: 24 callbacks suppressed [ 68.996413] retire_capture_urb: 33 callbacks suppressed [ 74.159355] retire_capture_urb: 26 callbacks suppressed [ 79.567248] retire_capture_urb: 27 callbacks suppressed [ 84.696196] retire_capture_urb: 16 callbacks suppressed [ 89.702177] retire_capture_urb: 24 callbacks suppressed [ 94.811127] retire_capture_urb: 10 callbacks suppressed On previous: -c8 FL = FL FR = FR C = CL (Center jack left channel) LFE = CR RR = RR RL = RL Checked on windows: 1) Headphones supports 32bit 192kHz 2) Line-in is a configurable jack that can be configured to side-speaker out I'll try to reapply patches, maybe something goes wrong on my side Grabbed 5.6.0 + for-linus branch. Applyed all patches - got same issues.Patches 5,6 and 7 makes driver unusable Then try drop only patch#7. It's the patch that restricts most things, and patch#5 is almost identical with the old patch. Yes, it works without patch#7 no changes regarding jack detection Could you give alsa-info.sh output from the latest state without patch#7? Created attachment 288545 [details]
alsa-info.txt withou patch#7
Thanks. Now I found the culprit of the non-working patch#6. I changed the code only for UAC1, while yours is UAC2. The revised patch#6 is attached below. Also another patch is attached for printing the channel mapping in stream* proc file. Those have been updated in topic/usb-trx40 branch of sound git tree, too. Created attachment 288547 [details]
Revised patch #6
Created attachment 288549 [details] All patches Just to make sure - attach is a full set of patches applyed to 5.6.0 after pulling https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound into snd_testing Created attachment 288551 [details]
Patch to print channel map on stream proc files
(In reply to Denis from comment #107) > Created attachment 288549 [details] > All patches > > Just to make sure - attach is a full set of patches applyed to 5.6.0 after > pulling > https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound into snd_testing You don't need to apply patches after the pull, except for some test debug patches. The procedure is: % git checkout -b snd_testing v5.6 % git pull https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound topic/usb-trx40 Then you have all patches already there. The first command creates a new branch "snd_testing", switches to the new branch and resets to v5.6 commit state. Then it pulls the changes in topic/usb-trx40 onto the current branch (snd_testing). To reset from the beginning, % git reset --hard v5.6 % git pull https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound topic/usb-trx40 I have TRX40 Designare and I also have similar issues with audio. Once time permits I will test all the patches here and try to help as well. (I even contributed my own 0.2 cents to alsa once) I so far also mapped the sound devices that alsa exposes and I have the similar mapping as you (LINEIN/SIDE) (SPEAKERS) (MIC) (CENTER+SUBW) (REAR) [SPDIF] FRONT: (HEADPHONES) (MIC/LINEIN) DACs: hw0:0 - speakers (8 channels, but side speakers need retasking) hw0,1 - front headphones (2 channels) hw0,2 - SPDIF (S16_LE/S24_3LE) hw0,3 - SPDIF (S16_LE only) ADCs: hw0,0 - line-in hw0,1 - back mic h20,2 - front mic I don't have SPDIF receiver yet, but I'll buy one of the cheap ones once that virus panic ends. In terms of USB IDS, my sound card has the same IDs as other gigabyte cards it seems: Bus 007 Device 003: ID 0414:a002 Giga-Byte Technology Co., Ltd USB Audio Also just note about the HDA audio codec thing - there is some misunderstanding that it is used or so. My take on this is that the CPU does have a HDA controller but it is just not connected to anything. It might be buggy and thus AMD decided not to use it or so. The USB device is a pair of devices (codec + usb bridge) and it is IMHO just an ordinary USB device which I can even pass through to a VM (both using USB pass-though and passing the whole USB controller it is attached to). And it does work very well in the VM in both cases. Also note that latest BIOS (F4C) adds an option to disable the HDA controller, which I enabled to get rid of this non functional device - otherwise it just takes an interrupt without any function. I wonder how hard it would be to reverse engineer the jack re-tasking. Not that I am planning to have 7.1 sound any time soon, but a part inside me wants everything to work and the fact that you can't retask currently the line-in to side output bothers me. I'll try to look at that once time permits too. The disablement of unused HD-audio controller has been already handled in other patchset found in 5.7-rc1. They'll be backported to stable trees soon later. But the lack of jack retasking is an open question. There is an Extension Unit (id 25), and this might play some role. Or Input Gain Pad in FU 19 that was disabled by the patch. BTW, it might be interesting to give the patch below try for the playback quality issue. It should influence on the behavior of PulseAudio. Created attachment 288563 [details]
Low latency test patch for USB-audio
Looks like patch#6 causes inability to return from S3 state. 2 of 3 wakes returned in system freez in nvidia driver (this doesn't happened before and driver doesn't changed). Will try with reverted #6. (In reply to Takashi Iwai from comment #113) > Created attachment 288563 [details] > Low latency test patch for USB-audio Please note that pulseaudio enables tsched for all USB devices for years: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/commit/810aa36189f82f77403826defa76a4f9f1f01454 (In reply to Alexander Tsoy from comment #115) > (In reply to Takashi Iwai from comment #113) > > Created attachment 288563 [details] > > Low latency test patch for USB-audio > Please note that pulseaudio enables tsched for all USB devices for years: Oh thanks, I didn't notice it beforehand. My patch was made years ago, and the PA's workaround wasn't there at that time :) The corresponding part was dropped from the latest patch in topic/usb-trx40 branch. (In reply to Denis from comment #114) > Looks like patch#6 causes inability to return from S3 state. 2 of 3 wakes > returned in system freez in nvidia driver (this doesn't happened before and > driver doesn't changed). Will try with reverted #6. Did you get the result? I don't see any obvious problem in that patch (it's merely a simple redirection of the notification call), so I wonder what's the cause. In anyway, I updated topic/usb-trx40 branch, and the patches from #1 to #5 in this thread have been already merged in for-linus branch, destined to 5.7-rc. (In reply to Takashi Iwai from comment #117) > (In reply to Denis from comment #114) > > Looks like patch#6 causes inability to return from S3 state. 2 of 3 wakes > > returned in system freez in nvidia driver (this doesn't happened before and > > driver doesn't changed). Will try with reverted #6. > Did you get the result? I don't see any obvious problem in that patch (it's > merely a simple redirection of the notification call), so I wonder what's > the cause. > > In anyway, I updated topic/usb-trx40 branch, and the patches from #1 to #5 > in this thread have been already merged in for-linus branch, destined to > 5.7-rc. Finally I got same issue with wake from S3 today without patch #6. Also I tryed latest patch #6 and got following result on alsa monitor. Speaker out node hw:2, #8 (0,0,0,Line Jack,0) VALUE node hw:2, #23 (0,0,0,Speaker Jack,0) VALUE Speaker in node hw:2, #8 (0,0,0,Line Jack,0) VALUE node hw:2, #23 (0,0,0,Speaker Jack,0) VALUE Back mic out node hw:2, #12 (0,0,0,Mic Jack,0) VALUE node hw:2, #23 (0,0,0,Speaker Jack,0) VALUE Back mic in node hw:2, #12 (0,0,0,Mic Jack,0) VALUE node hw:2, #23 (0,0,0,Speaker Jack,0) VALUE Fron headphone out node hw:2, #8 (0,0,0,Line Jack,0) VALUE node hw:2, #27 (0,0,0,Front Headphone Jack,0) VALUE Fron headphone in node hw:2, #8 (0,0,0,Line Jack,0) VALUE node hw:2, #27 (0,0,0,Front Headphone Jack,0) VALUE So except for bogus line jack event - other events are valid. OK, then it's a signal green. The bogus event comes from the USB audio device itself, but this is merely the notification, and the actual read of the state works. I submitted the patch #6 and merged, ready for 5.7-rc3 inclusion. About S3 problem: it might be some side-effect of the recent fix in HD-audio side. I also queued another fix in topic/usb-trx40 branch. Could you guys retest with that one? (In reply to Takashi Iwai from comment #119) > OK, then it's a signal green. The bogus event comes from the USB audio > device itself, but this is merely the notification, and the actual read of > the state works. > > I submitted the patch #6 and merged, ready for 5.7-rc3 inclusion. > > About S3 problem: it might be some side-effect of the recent fix in HD-audio > side. I also queued another fix in topic/usb-trx40 branch. Could you guys > retest with that one? Tryed with this one. Jack detection still works. Also was able to wake from S3 today, will continue testing for S3. Got another issue (I think it happened before, just forgot to mention). At some point after wake sound in left channel muted. It fixes by moving volume up and down in alsamixer. Happened for both - headphones and back speaker. Also sometimes microphone muted until pulseaudio -k called. Created attachment 288697 [details]
/usr/share/alsa/ucm2/USB-Audio/Realtek-ALC1220-VB-Desktop.conf
Created attachment 288699 [details]
/usr/share/alsa/ucm2/USB-Audio/HiFi.conf
The dummy input is not really dummy - but using alsa 'null' input makes pulseaudio use 100% cpu sadly.
I tested the latest Linus's tree with topic/usb-trx40 merged and it looks like the jack detection does work - only speakers jacks that correspond to 'extra' outputs (like back speakers/subwoofer/etc) are not detected, this I think is by design S3 works as well thankfully. I added very basic hacked-together UCM2 profiles that sort of work but need lot of work to make them fully usable (currently for example pulseaudio is not aware of the hardware mixer volumes, thus you have to ramp up the volume in alsamixer) And about the 'dummy' input - it looks like pulseaudio doesn't like situation when there are no inputs and doesn't like the UCM2 profile at all, so I added a dummy input instead. I use Fedora 31 - it seems like ucm folder is there as well but it looks like it is ignored. Wrong files attached? They look like for the dual-codec HD-audio. Sorry about that! I am still learning on how to deal with UCM Created attachment 288701 [details]
Realtek-ALC1220-VB-Desktop.conf
Created attachment 288705 [details]
/usr/share/alsa/ucm2/USB-Audio/HiFi.conf
The volume and mute controls are basically enable / disable sequences for each device definition. So basically you'd set 0dB to the volume and toggle mute. One uncertain thing is that whether PA can deal with only the first two channels out of eight channels. IIRC, either speaker or line output has eight channels. Also, another possible device set up is for 4.0, 5.1 and 7.1 channels. Those are declared as exclusive and conflicting with each other, also conflicting with the retasking. But this can be implemented later, if any. I noticed that, but I wasn't able yet to make it work using the ucm2 syntax. However does it mean that the enable will only set the volume to 100% and disable to 0%. I remember that pulseaudio was able to actually pass through its main volume to the alsa mixer, thus using the hardware volume. About 8 channels, I understand that the issue is with the mixer providing a volume for each channel since otherwise pulseaudio has no issue using this - it acutually always worked in 5.1 mode (that is to get side output we need to reverse-engineer the jack retasking). Created attachment 288735 [details]
ASRock TRX40 Creator patch
ASRock TRX40 Creator is another board with the strange PCI + USB HDA audio arrangement. The attached patch avoids creating the dummy audio device and gets at least the front panel headphones and read panel front speaker outputs working. It's awkward for me to test the other connectors, but I'm guessing it's the same as other boards.
Hm, PCI SSID 1022:d102 looks suspicious. It's the SSID vendor AMD, indicating a broken BIOS. So it's safe to not to add this entry at first. Could you submit your patch to alsa-devel ML with the correction? (In reply to Maxim Levitsky from comment #130) > I noticed that, but I wasn't able yet to make it work using the ucm2 syntax. > However does it mean that the enable will only set the volume to 100% and > disable to 0%. > > I remember that pulseaudio was able to actually pass through its main volume > to the alsa mixer, thus using the hardware volume. Yes, but PA doesn't take the mixer volume from UCM for now, as it seems. > About 8 channels, I understand that the issue is with the mixer providing a > volume for each channel since otherwise pulseaudio has no issue using this - > it acutually always worked in 5.1 mode (that is to get side output we need > to reverse-engineer the jack retasking). OK. Meanwhile, it's better to provide the already more-or-less working profile to upstream. Could you send a PR to alsa-ucm-conf git repo? It'll need also the alsa-info.sh output for validation, too. (In reply to Takashi Iwai from comment #133) > I remember that pulseaudio was able to actually pass through its main volume > > to the alsa mixer, thus using the hardware volume. > Yes, but PA doesn't take the mixer volume from UCM for now, as it seems. Use "PlaybackMixerElem" and "PlaybackMasterElem" values (simple mixer element syntax) and latest PA (13.99 or GIT) for the hardware volume support. @Takashi Iwai I will gladly do. So far the profile is basically 99% what you shared, I just hammered it till something worked. Does ucm/ucm2 have a documentation? Other than https://github.com/alsa-project/alsa-ucm-conf/tree/master/ucm2 This does documents few things https://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=include/use-case.h I can also read the source here: https://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=src/ucm/parser.c Anything else? @Takashi Iwai I just found another thing that don't work on this device in linux. Windows driver provides ability to enable back line-out as headphones out with several levels of headphone power (and actually it looks like it have more power then front headphones output). Regarding S3 - all works fine from your branch. Also issue with only one channel working has dissapeared. It only appear now when I return device from virtual machine to host. @Denis - indeed, I noticed it too! @Takashi Iwai I tried my best to understand the UCM2 profiles based on the info I mentioned above, and I got something more or less reasonable working. This is the pull request https://github.com/alsa-project/alsa-ucm-conf/pull/25 Thanks a lot for helping making it work! Since the sound card works superb when passed through to a VM using usb passthrough (basically using libusb) I can sniff the usb traffic and try to figure out how they do jack retasking and the headphone power levels thing as well. I explained most of the issues in the git commit that is in the pull request. I also understand that UCM/UCM2 is somewhat new and not fully supported in pulseaudio which itself has alsa profiles. @Takashi Iwai Is it true that the direction is to deprecate the pulseaudio profiles and replace them with UCM2 profiles provided by alsa? It is a good idea IMHO. Some more observations as I fine tune the UCM2 profiles. 1. The sound in front headphones is muted if I unplug and plug them back (this is without pulseaudio running, and just doing cat /dev/urandom | aplay -D hw:2,1 -f S16_LE -c 2 If I nudge the volume and/or mute/unmute the sound cames back. Restarting the above aplay command also helps. This breaks pulseaudio since it doesn't let go of the playback channel on such an event. The same doesn't happen with back speaker. SPDIF I can't yet test. 2. When I play something on SPDIF interface, I hear clicks once in a while in the front headphones and the volume of these clicks is proportional to front headphones volume. Right now it seems like SPDIF (TOSLINK) sometimes works and sometimes doesn't. Messing with volume, mute, etc. doesn't seem to help when it's not working, just silence. But then it will come back seemingly randomly. Any logs I can get that would help? Same here (I did buy a cheap SPDIF receiver to test it). It seems that suspend to ram "fixes" most of the time. Also the same can be said about the front headphones. They also sometimes miss one of the channels or both until I mess with the volume. I still haven't had time to figure out the pattern of when it stops working. It's hard to say what can be wrong. Possibly the firmware problem, as the audio stream on USB-audio is rather simple. I also confirm the non restoring volumes on resume sometimes, and sometimes non working SPDIF. I am keeping an eye on both (I don't need SPDIF, but I bought a cheap dongle and I poke it once in a while). Note that on 5.11 kernel, pulseaudio stopped working with the device (works fine on 5.10). I'll bisect this at the weekend. The bisection might point a bug that has been already fixed but there were a couple of other regressions for certain devices. Please try for-linus branch of my sound git tree for testing such a USB audio device: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git I ended up bisecting anyway (I didn't read your response here) and it was due to 'ALSA: usb-audio: Fix hw constraints dependencies' sound.git branch does work fine though, now that I tested. Thank you very much! OK, then the fix was already merged in Linus tree yesterday. On 5.11 another regression happens. After resume sometimes (actually most of the times) I got "white noise" instead of sound after switching from front panel headphones to back panel speakers. In log I have following: pulseaudio[102875]: Doing resync pulseaudio[102875]: Playback too far ahead (10517), drop source 4032 pulseaudio[102875]: ALSA woke us up to write new data to the device, but there was actually nothing to write. pulseaudio[102875]: Most likely this is a bug in the ALSA driver 'snd_usb_audio'. Please report this issue to the ALSA developers. pulseaudio[102875]: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. pulseaudio[102875]: ALSA woke us up to read new data from the device, but there was actually nothing to read. pulseaudio[102875]: Most likely this is a bug in the ALSA driver 'snd_usb_audio'. Please report this issue to the ALSA developers. pulseaudio[102875]: We were woken up with POLLIN set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. Sometimes it goes away if following actions taken: 1) pulseaudio -k 2) switch to speaker 3) suspend to ram 4) wake up 5) pulseaudio -k And then it can work fine most of the time. Issue was reproduced on: 5.11.4-lowlatency 5.11.5-lowlatency 5.11.6-lowlatency 5.11.0-20.1-liquorix Will try on 5.12.4 Tested on 5.12.4 - same issue. Noise after wakeup when sink switched to speakers from front panel headphones I am using a Gentoo Linux with currently 5.12.3 kernel on an ASUS Zenith II Extreme Alpha mainboard, and I also cannot get the SPDIF output to work.
I have tried with pure ALSA (no pulseaudio started) to play something via aplay or speaker-test, which works on all outputs but the SPDIF.
The same if I use pulseaudio and any application.
I have tried all kernels from 5.9 onwards, with the same result.
The SPDIF output is working without any problem on windows.
What confuses me a bit: The USB sound device is recognized as 2 USB devices, 1 of them having 2 SPDIF outputs, the other 1, for a total of 3. Is this expected:
qon@qon ~ $ cat /proc/asound/cards
[...]
3 [Audio ]: USB-Audio - USB Audio
Generic USB Audio at usb-0000:47:00.3-5, high speed
4 [Audio_1 ]: USB-Audio - USB Audio
Generic USB Audio at usb-0000:47:00.3-6, high speed
qon@qon ~ $ aplay -L
[...]
iec958:CARD=Audio,DEV=0
USB Audio, USB Audio
IEC958 (S/PDIF) Digital Audio Output
iec958:CARD=Audio,DEV=1
USB Audio, USB Audio #1
IEC958 (S/PDIF) Digital Audio Output
[...]
iec958:CARD=Audio_1,DEV=0
USB Audio, USB Audio
IEC958 (S/PDIF) Digital Audio Output
I tried all of them, but no success. From what I have seen SPDIF has been fixed for several TRX40 boards, but I couldn't find anything for the ASUS Zenith II Extreme Alpha, except for some forum posts of people who have the same problem, but no solution.
Anyone has an idea?
Hello I'm new to kernel.org and have never had to patch a kernel before but am encountering the same issues. I don't have any way to test S/PDIF, but my microphone jack doesn't work. Alsa knows when the port is... Vacant or occupied... But alsa never actually captures audio coming in from the mic. I cannot tell by reading this forum if the issue is solved or not. I am running the most up to date kernel I could find for my OS (Manjaro xfce) 5.14.rs1.d0711.ge73f0f0-1 hoping that the patch was pushed to the kernel. But it is still not working. Any help would be appreciated. I am more willing to pay a dev to patch the kernel before spending money on a PCIe sound card or a cheap plastic USB external DAC. But I have no idea how to achieve paying a dev either so I'm just looking for help on many different forums. Thanks! Crackling sound issue still present on 5.13.4 S/PDIF doesn't work anymore in 5.13 I'm having same issue with Rocky 8.4 (kernel 4.18.0). MB: ASUS PRIME TRX40-PRO S, BIOS 1402 Can not get the front audio to work. dmesg shows: [ 16.058732] usb 5-6: cannot get ctl value: req = 0x83, wValue = 0xc00, wIndex = 0x1300, type = 4 [ 16.058735] usb 5-6: 19:0: cannot get min/max values for control 12 (id 19) [ 16.058980] usb 5-6: cannot get ctl value: req = 0x81, wValue = 0xc00, wIndex = 0x1300, type = 4 [ 16.114854] usb 5-6: cannot get ctl value: req = 0x83, wValue = 0xc00, wIndex = 0x1300, type = 4 [ 16.114856] usb 5-6: 19:0: cannot get min/max values for control 12 (id 19) [ 16.115104] usb 5-6: cannot get ctl value: req = 0x81, wValue = 0xc00, wIndex = 0x1300, type = 4 [ 16.254481] usb 5-6: cannot get ctl value: req = 0x83, wValue = 0xc00, wIndex = 0x1300, type = 4 [ 16.254483] usb 5-6: 19:0: cannot get min/max values for control 12 (id 19) Operating System: Arch Linux KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.2 Kernel Version: 5.14.5-zen1-1-zen (64-bit) Graphics Platform: X11 Processors: 64 × AMD Ryzen Threadripper 3970X 32-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: Radeon RX 580 Series I have sound through the front output but despite having the volume at maximum it is very low. |