Bug 206873

Summary: No sound output via SPDIF (toslink) on AMD TRX4 motherboard (TRX40 AORUS XTREME) - Realtek ALC1220-VB USB Audio
Product: Drivers Reporter: vitkor (vik)
Component: Sound(ALSA)Assignee: Jaroslav Kysela (perex)
Status: NEW ---    
Severity: normal CC: alexander, andrew, andrew, chris, decedion, dunc4n, kernel-org, maximlevitsky, messengerofdeath, nlopes, noslin005, qjvRVVuBRnYHkuWQNVACHf, scorpio, spam, tavianator, tiwai, vik
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 5.5.9 Subsystem:
Regression: No Bisected commit-id:
Attachments: No sound output via SPDIF (toslink) on AMD TRX4 motherboard (TRX40 AORUS XTREME)
alsa-info
Patch to ignore ctl error
lsusb -v
lsusb -v 2>&1
Revised patch to ignore ctl error
/proc/asound/card3/stream*
alsactl
Patch #1
Patch #2
Patch #3
Patch #4
alsa-info
/proc/asound/card3/stream*
alsa-info from TRX40 AORUS PRO WIFI
Patch #5 (testing)
Realtek-ALC1220-VB-Desktop.conf
HiFi.conf
alsa-info
debug patch
Fixed HiFi conf
Revised HiFi.conf
alsa-info after patch #5 on TRX40 AORUS PRO WIFI
contents of /proc/asound/card1/pcm2p/sub0/
alsa-info
Patch for delegated jack detection
dmesg snd-usb-audio crash
Revised patch for delegated jack detection
Yet more debug patch
Patch #5
Patch #6
Patch #7
alsa-info.txt withou patch#7
Revised patch #6
All patches
Patch to print channel map on stream proc files
Low latency test patch for USB-audio
/usr/share/alsa/ucm2/USB-Audio/Realtek-ALC1220-VB-Desktop.conf
/usr/share/alsa/ucm2/USB-Audio/HiFi.conf
Realtek-ALC1220-VB-Desktop.conf
/usr/share/alsa/ucm2/USB-Audio/HiFi.conf
ASRock TRX40 Creator patch

Description vitkor 2020-03-18 04:07:33 UTC
Created attachment 287965 [details]
No sound output via SPDIF (toslink) on AMD TRX4 motherboard (TRX40 AORUS XTREME)

TRX40 AORUS XTREME motherboard with TRX4 chipset and Threadripper 3970x processor.
No sound output via SPDIF (toslink)
All analog outputs and inputs works fine.
In dmesg I'm see following:
dmesg | grep snd
snd_hda_intel 0000:21:00.1: Disabling MSI
snd_hda_intel 0000:21:00.1: Handle vga_switcheroo audio client
snd_hda_intel 0000:23:00.4: enabling device (0000 -> 0002)
snd_hda_intel 0000:23:00.4: no codecs found!
usbcore: registered new interface driver snd-usb-audio

If I select USBAUDIO in alsamixer, then alsamixer crashes with an error:
Cannot load mixer control panel: Channel break

Alsa-info output in attachment. 
There is also the same problem on other motherboards with this chipset:
https://www.phoronix.com/forums/forum/hardware/general-hardware/1147545-realtek-alc1220-vb-usb-audio

Tell me please what additional information is needed to solve the problem.
Comment 2 Denis 2020-04-09 15:35:27 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?
Comment 3 Denis 2020-04-09 15:36:04 UTC
Created attachment 288301 [details]
alsa-info
Comment 4 Takashi Iwai 2020-04-09 15:42:37 UTC
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.
Comment 5 Denis 2020-04-09 15:50:24 UTC
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
Comment 6 Takashi Iwai 2020-04-09 16:11:47 UTC
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.
Comment 7 Denis 2020-04-09 16:12:15 UTC
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?
Comment 8 Takashi Iwai 2020-04-09 16:14:38 UTC
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.
Comment 9 Denis 2020-04-09 16:15:06 UTC
aplay -Dhw:3,0 ./1.wav - is a front output (line out)
Comment 10 Denis 2020-04-09 16:16:07 UTC
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
Comment 11 Takashi Iwai 2020-04-09 16:17:54 UTC
(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.
Comment 12 Denis 2020-04-09 16:18:13 UTC
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
Comment 13 Takashi Iwai 2020-04-09 16:22:16 UTC
(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...
Comment 14 Denis 2020-04-09 16:38:17 UTC
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?
Comment 15 Denis 2020-04-09 16:44:50 UTC
Looks like it was applied correctly:
cat /sys/module/snd_usb_audio/parameters/ignore_ctl_error 
Y
Comment 16 Takashi Iwai 2020-04-09 17:13:33 UTC
Then try the patch below.  This should make the option effective.
Comment 17 Takashi Iwai 2020-04-09 17:13:58 UTC
Created attachment 288303 [details]
Patch to ignore ctl error
Comment 18 Denis 2020-04-09 17:40:30 UTC
It doesn't help. Still no file and same error.
Comment 19 Denis 2020-04-09 17:41:06 UTC
Created attachment 288305 [details]
lsusb -v

Attaching lsusb -v
Audio is 
Bus 007 Device 003: ID 0db0:0d64 Micro Star International USB Audio
Comment 20 Denis 2020-04-09 17:43:10 UTC
Created attachment 288307 [details]
lsusb -v 2>&1

Reuploaded lsusb. To include errors that happens.
Comment 21 Takashi Iwai 2020-04-09 20:34:54 UTC
OK, try the following one instead of the previous patch.

Also, please give the contents of /proc/asound/card3/stream* files, too.
Comment 22 Takashi Iwai 2020-04-09 20:35:21 UTC
Created attachment 288313 [details]
Revised patch to ignore ctl error
Comment 23 Denis 2020-04-10 06:21:31 UTC
Created attachment 288325 [details]
/proc/asound/card3/stream*
Comment 24 Denis 2020-04-10 06:37:52 UTC
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
Comment 25 Takashi Iwai 2020-04-11 10:17:16 UTC
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.
Comment 26 Takashi Iwai 2020-04-11 10:17:56 UTC
Created attachment 288339 [details]
Patch #1
Comment 27 Takashi Iwai 2020-04-11 10:18:20 UTC
Created attachment 288341 [details]
Patch #2
Comment 28 Takashi Iwai 2020-04-11 10:18:41 UTC
Created attachment 288343 [details]
Patch #3
Comment 29 Takashi Iwai 2020-04-11 10:19:06 UTC
Created attachment 288345 [details]
Patch #4
Comment 30 Denis 2020-04-11 12:11:58 UTC
Created attachment 288347 [details]
alsa-info

Alsa info. No errors while running.
Comment 31 Denis 2020-04-11 12:12:21 UTC
Created attachment 288349 [details]
/proc/asound/card3/stream*
Comment 32 Denis 2020-04-11 12:24:36 UTC
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
Comment 33 Takashi Iwai 2020-04-11 13:09:46 UTC
Thanks!

One more favor: try to run "alsactl monitor" and plug/unplug the jacks.
Do you see any events shown?
Comment 34 acs+kernel 2020-04-11 14:15:20 UTC
Created attachment 288353 [details]
alsa-info from TRX40 AORUS PRO WIFI
Comment 35 acs+kernel 2020-04-11 14:20:31 UTC
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.
Comment 36 Denis 2020-04-11 14:45:51 UTC
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
Comment 37 dunc4n 2020-04-11 16:58:48 UTC
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.
Comment 38 acs+kernel 2020-04-11 17:12:33 UTC
(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
Comment 39 Takashi Iwai 2020-04-12 07:55:39 UTC
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.
Comment 40 Takashi Iwai 2020-04-12 07:56:51 UTC
Created attachment 288363 [details]
Patch #5 (testing)
Comment 41 Takashi Iwai 2020-04-12 07:57:47 UTC
Created attachment 288365 [details]
Realtek-ALC1220-VB-Desktop.conf
Comment 42 Takashi Iwai 2020-04-12 07:58:09 UTC
Created attachment 288367 [details]
HiFi.conf
Comment 43 Takashi Iwai 2020-04-12 08:00:14 UTC
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.
Comment 44 Denis 2020-04-12 08:35:20 UTC
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.
Comment 45 Denis 2020-04-12 08:37:32 UTC
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.
Comment 46 Takashi Iwai 2020-04-12 09:23:23 UTC
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: ...."
Comment 47 Takashi Iwai 2020-04-12 09:23:50 UTC
Created attachment 288373 [details]
debug patch
Comment 48 Takashi Iwai 2020-04-12 09:29:22 UTC
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.
Comment 49 Takashi Iwai 2020-04-12 09:33:35 UTC
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.
Comment 50 Denis 2020-04-12 09:43:21 UTC
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
Comment 51 Denis 2020-04-12 09:49:12 UTC
Created attachment 288375 [details]
Fixed HiFi conf

With this HiFI.conf pulseaudio starts and shows different devices for each output.
Comment 52 Takashi Iwai 2020-04-12 09:51:33 UTC
(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.
Comment 53 Takashi Iwai 2020-04-12 09:56:48 UTC
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.
Comment 54 Takashi Iwai 2020-04-12 09:57:59 UTC
Created attachment 288377 [details]
Revised HiFi.conf
Comment 55 acs+kernel 2020-04-12 17:06:41 UTC
Created attachment 288391 [details]
alsa-info after patch #5 on TRX40 AORUS PRO WIFI
Comment 56 acs+kernel 2020-04-12 17:47:43 UTC
(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.
Comment 57 Takashi Iwai 2020-04-12 21:14:47 UTC
(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.
Comment 58 acs+kernel 2020-04-12 23:03:44 UTC
(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/
Comment 59 acs+kernel 2020-04-12 23:06:18 UTC
Created attachment 288403 [details]
contents of /proc/asound/card1/pcm2p/sub0/
Comment 60 Takashi Iwai 2020-04-13 06:24:18 UTC
(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?
Comment 61 Nilson Lopes 2020-04-13 14:28:40 UTC
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.
Comment 62 acs+kernel 2020-04-13 16:00:52 UTC
(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.
Comment 63 Takashi Iwai 2020-04-13 16:14:51 UTC
(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.
Comment 64 Denis 2020-04-13 17:00:52 UTC
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
Comment 65 Denis 2020-04-13 17:02:32 UTC
Created attachment 288421 [details]
alsa-info

Card moved to Card1
Comment 66 Denis 2020-04-13 17:47:23 UTC
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."),
Comment 67 Denis 2020-04-13 17:48:58 UTC
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
Comment 68 acs+kernel 2020-04-13 17:51:33 UTC
(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.
Comment 69 acs+kernel 2020-04-13 18:36:46 UTC
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.
Comment 70 Takashi Iwai 2020-04-13 21:45:19 UTC
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.
Comment 71 Denis 2020-04-14 06:15:45 UTC
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.
Comment 72 Takashi Iwai 2020-04-14 08:19:57 UTC
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",
Comment 73 scorpio 2020-04-14 19:48:17 UTC
Great, thanks Iwai & Denis. ;-)
I finally discover the audio sound quality of this USB-card.
Comment 74 Denis 2020-04-15 06:29:00 UTC
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
Comment 75 Takashi Iwai 2020-04-15 08:05:28 UTC
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.
Comment 76 Takashi Iwai 2020-04-15 08:06:20 UTC
Created attachment 288463 [details]
Patch for delegated jack detection
Comment 77 Denis 2020-04-15 08:23:09 UTC
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.
Comment 78 Denis 2020-04-15 12:20:46 UTC
Created attachment 288485 [details]
dmesg snd-usb-audio crash

Got crash on latest patch.
Comment 79 Takashi Iwai 2020-04-15 13:07:43 UTC
Oops sorry there was one place I overlooked about the NULL check.
Try the revised patch below instead.
Comment 80 Takashi Iwai 2020-04-15 13:08:21 UTC
Created attachment 288493 [details]
Revised patch for delegated jack detection
Comment 81 Denis 2020-04-15 17:02:00 UTC
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
Comment 82 Takashi Iwai 2020-04-15 19:04:17 UTC
(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?
Comment 83 Takashi Iwai 2020-04-15 19:04:46 UTC
Created attachment 288505 [details]
Yet more debug patch
Comment 84 Denis 2020-04-15 20:19:42 UTC
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?
Comment 85 Takashi Iwai 2020-04-16 07:39:47 UTC
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.
Comment 86 Denis 2020-04-16 07:45:10 UTC
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?
Comment 87 Takashi Iwai 2020-04-16 07:52:42 UTC
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
Comment 88 Takashi Iwai 2020-04-16 12:23:22 UTC
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/
Comment 89 Takashi Iwai 2020-04-16 12:23:55 UTC
Created attachment 288517 [details]
Patch #5
Comment 90 Takashi Iwai 2020-04-16 12:24:21 UTC
Created attachment 288519 [details]
Patch #6
Comment 91 Takashi Iwai 2020-04-16 12:24:45 UTC
Created attachment 288521 [details]
Patch #7
Comment 92 Denis 2020-04-16 12:54:00 UTC
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?
Comment 93 Takashi Iwai 2020-04-16 12:58:35 UTC
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.
Comment 94 Denis 2020-04-16 14:35:14 UTC
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
Comment 95 Denis 2020-04-16 14:46:09 UTC
-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
Comment 96 Denis 2020-04-16 14:53:31 UTC
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
Comment 97 Denis 2020-04-16 14:57:23 UTC
On previous:
-c8
FL = FL
FR = FR

C = CL (Center jack left channel) 
LFE = CR

RR = RR
RL = RL
Comment 98 Denis 2020-04-16 15:16:28 UTC
Checked on windows:
1) Headphones supports 32bit 192kHz
2) Line-in is a configurable jack that can be configured to side-speaker out
Comment 99 Denis 2020-04-16 15:34:43 UTC
I'll try to reapply patches, maybe something goes wrong on my side
Comment 100 Denis 2020-04-16 16:19:08 UTC
Grabbed 5.6.0 + for-linus branch. Applyed all patches - got same issues.Patches 5,6 and 7 makes driver unusable
Comment 101 Takashi Iwai 2020-04-16 16:31:27 UTC
Then try drop only patch#7.  It's the patch that restricts most things, and patch#5 is almost identical with the old patch.
Comment 102 Denis 2020-04-16 16:41:10 UTC
Yes, it works without patch#7 no changes regarding jack detection
Comment 103 Takashi Iwai 2020-04-17 07:47:01 UTC
Could you give alsa-info.sh output from the latest state without patch#7?
Comment 104 Denis 2020-04-17 08:20:43 UTC
Created attachment 288545 [details]
alsa-info.txt withou patch#7
Comment 105 Takashi Iwai 2020-04-17 08:22:40 UTC
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.
Comment 106 Takashi Iwai 2020-04-17 08:23:23 UTC
Created attachment 288547 [details]
Revised patch #6
Comment 107 Denis 2020-04-17 08:23:45 UTC
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
Comment 108 Takashi Iwai 2020-04-17 08:26:28 UTC
Created attachment 288551 [details]
Patch to print channel map on stream proc files
Comment 109 Takashi Iwai 2020-04-17 08:30:27 UTC
(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
Comment 110 Maxim Levitsky 2020-04-17 13:11:17 UTC
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.
Comment 111 Takashi Iwai 2020-04-17 15:18:53 UTC
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.
Comment 112 Takashi Iwai 2020-04-17 15:42:33 UTC
BTW, it might be interesting to give the patch below try for the playback quality issue.  It should influence on the behavior of PulseAudio.
Comment 113 Takashi Iwai 2020-04-17 15:43:23 UTC
Created attachment 288563 [details]
Low latency test patch for USB-audio
Comment 114 Denis 2020-04-18 08:09:25 UTC
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.
Comment 115 Alexander Tsoy 2020-04-20 20:07:38 UTC
(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
Comment 116 Takashi Iwai 2020-04-21 06:15:02 UTC
(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.
Comment 117 Takashi Iwai 2020-04-21 06:17:19 UTC
(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.
Comment 118 Denis 2020-04-22 07:16:32 UTC
(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.
Comment 119 Takashi Iwai 2020-04-22 13:08:58 UTC
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?
Comment 120 Denis 2020-04-23 08:48:20 UTC
(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.
Comment 121 Maxim Levitsky 2020-04-24 08:25:10 UTC
Created attachment 288697 [details]
/usr/share/alsa/ucm2/USB-Audio/Realtek-ALC1220-VB-Desktop.conf
Comment 122 Maxim Levitsky 2020-04-24 08:26:09 UTC
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.
Comment 123 Maxim Levitsky 2020-04-24 08:28:59 UTC
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)
Comment 124 Maxim Levitsky 2020-04-24 08:30:41 UTC
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.
Comment 125 Takashi Iwai 2020-04-24 10:39:26 UTC
Wrong files attached?  They look like for the dual-codec HD-audio.
Comment 126 Maxim Levitsky 2020-04-24 11:59:50 UTC
Sorry about that! I am still learning on how to deal with UCM
Comment 127 Maxim Levitsky 2020-04-24 12:01:40 UTC
Created attachment 288701 [details]
Realtek-ALC1220-VB-Desktop.conf
Comment 128 Maxim Levitsky 2020-04-24 12:02:35 UTC
Created attachment 288705 [details]
/usr/share/alsa/ucm2/USB-Audio/HiFi.conf
Comment 129 Takashi Iwai 2020-04-24 12:35:36 UTC
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.
Comment 130 Maxim Levitsky 2020-04-24 18:05:57 UTC
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).
Comment 131 Andrew Oakley 2020-04-26 11:18:07 UTC
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.
Comment 132 Takashi Iwai 2020-04-27 08:09:55 UTC
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?
Comment 133 Takashi Iwai 2020-04-27 08:16:32 UTC
(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.
Comment 134 Jaroslav Kysela 2020-04-27 08:26:26 UTC
(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.
Comment 135 Maxim Levitsky 2020-04-28 20:24:56 UTC
@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?
Comment 136 Denis 2020-04-29 08:34:32 UTC
@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.
Comment 137 Maxim Levitsky 2020-05-03 19:53:48 UTC
@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.
Comment 138 Maxim Levitsky 2020-05-03 19:56:03 UTC
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.
Comment 139 Maxim Levitsky 2020-05-04 23:26:08 UTC
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.
Comment 140 Tavian Barnes 2020-08-05 17:32:04 UTC
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?
Comment 141 Maxim Levitsky 2020-08-20 22:08:31 UTC
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.
Comment 142 Takashi Iwai 2021-01-08 11:56:12 UTC
It's hard to say what can be wrong.  Possibly the firmware problem, as the audio stream on USB-audio is rather simple.
Comment 143 Maxim Levitsky 2021-01-24 13:42:56 UTC
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.
Comment 144 Takashi Iwai 2021-01-25 07:54:28 UTC
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
Comment 145 Maxim Levitsky 2021-01-29 10:31:01 UTC
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!
Comment 146 Takashi Iwai 2021-01-29 10:38:26 UTC
OK, then the fix was already merged in Linus tree yesterday.
Comment 147 Denis 2021-05-17 17:35:19 UTC
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.
Comment 148 Denis 2021-05-17 17:37:16 UTC
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
Comment 149 Denis 2021-05-19 17:03:27 UTC
Tested on 5.12.4 - same issue. Noise after wakeup when sink switched to speakers from front panel headphones
Comment 150 David Rohr 2021-06-06 21:01:30 UTC
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?
Comment 151 qjvRVVuBRnYHkuWQNVACHf 2021-07-22 18:33:38 UTC
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!
Comment 152 Denis 2021-08-04 17:21:12 UTC
Crackling sound issue still present on 5.13.4
S/PDIF doesn't work anymore in 5.13
Comment 153 Nilson 2021-08-04 20:19:34 UTC
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)
Comment 154 Juan Simón 2021-09-17 14:21:32 UTC
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.