Created attachment 197091 [details] alsa-info.sh output Following Takashi Iwai’s request from https://bugzilla.kernel.org/show_bug.cgi?id=55541#c178 where he asks for a separate bug report for each non-working device. Attached is the alsa-info.txt Note that the non-working board is the third one listed, aka 2 [Creative ]: HDA-Intel - HDA Creative HDA Creative at 0xfe504000 irq 18 The issues are (at least): - Probably non-working analogic Microphone input (rear, first pin) - Non-working Headphone analogic output (rear, second pin) - Non working Front analogic output (rear, third pin) “Non-working” as in “no sound comes out of it”. Although it’s recognized by pulseaudio and the “volume” bar in pavucontrol moves with the music. Please let me know if you need any more details on the hardware, or if you need me to do some tests. Thank you very much for you time on this issue.
I've got the same thing, no sound comes out of my SBZ. Not from Front Panel nor from Rear. But card is detected as SB Recon3D and i can change volume etc. But on Windows everything works fine. I've tried kernel 4.4rc4 and now DSP loads fine but i'm still getting no sound. My alsa-info: http://pastebin.com/YRMGrzXf
Sound Blaster Z here, analog mic input is working (with the correct mixer setup using alsamixer), but the playback does not work. Note that the playback stream can be captured using 'CA0132 What U Hear' capture device so PCM / DMA interface is fine. It's something in the DSP / mixer / amplifier settings. The big question is if the DSP firmare is compatible with the last fw revision (firmware date is Wed Apr 3 16:42:28 2013). I found that some widget default configs changes when the DSP is loaded: def_conf: 0b:010140f0 dsp 0x01014010 def_conf: 0c:014580f0 dsp 0x014580f0 def_conf: 0d:014570f0 dsp 0x014570f0 def_conf: 0e:01c530f0 dsp 0x01c530f0 def_conf: 0f:422000f0 dsp 0x0221401f *** def_conf: 10:022160f0 dsp 0x02216011 def_conf: 11:028120f0 dsp 0x02012014 def_conf: 12:37a791f0 dsp 0x37a791f0 def_conf: 13:50d000f0 dsp 0x908700f0 *** def_conf: 18:500000f0 dsp 0x500000f0 It appears that the codec should be reconfigured when the DSP is loaded. Digging more, but I welcome any ideas.
(In reply to Jaroslav Kysela from comment #2) > settings. The big question is if the DSP firmare is compatible with the last > fw revision (firmware date is Wed Apr 3 16:42:28 2013). It should be 'with the last hw revision'.
Created attachment 197401 [details] A test (non-working patch) showing ideas for futher tests
PID list based on pin sensing for Sound Blaster Z: 0x0d - line out 1 0x0f - headphone 0x11 - line out 2 0x12 - microphone ... missing line out 3 The 0x0d sensing seems wrong ?
I think we just need to find the right pin configs, look guys: Alsa-info of Alienware 15: http://mailman.alsa-project.org/pipermail/alsa-devel/2015-April/091142.html Look at this: /sys/class/sound/hwC1D0/init_pin_configs: 0x0b 0x901701f0 0x0c 0x434510f0 0x0d 0x414510f0 0x0e 0x50c600f0 0x0f 0x432110f0 0x10 0x432110f0 0x11 0x038110f0 0x12 0xb7a601f0 0x13 0x50d000f0 0x18 0x500000f0 and now look at Takashi Iwai pin config for alienware 15: { 0x0b, 0x90170110 }, /* Builtin Speaker */ { 0x0c, 0x411111f0 }, /* N/A */ { 0x0d, 0x411111f0 }, /* N/A */ { 0x0e, 0x411111f0 }, /* N/A */ { 0x0f, 0x0321101f }, /* HP */ { 0x10, 0x411111f0 }, /* Headset? disabled for now */ { 0x11, 0x03a11021 }, /* Mic */ { 0x12, 0xd5a30140 }, /* Builtin Mic */ { 0x13, 0x411111f0 }, /* N/A */ { 0x18, 0x411111f0 }, /* N/A */ But how did he found the right address? Like for headphone output: 0x432110f0 --> 0x0321101f or speaker: 0x901701f0 --> 0x90170110 Any ideas?
I tried all (or I think all) DAC -> PIN connections and I don't have any output even with DAC 6 -> PIN 0x0d connection which appearently works in FreeBSD. The pin configurations describes the jack configuration and you may trace the DAC -> PIN connections using the /proc codec file or hda-analyzer, but we need to find something which blocks the analog output path which might be unrelated to pinconfigs.
A really dirty hack (configuration) to make 'line out 1' (middle jack) work (like in FreeBSD): Add 'model=generic' to /etc/modprobe.d for snd-hda-intel module and run this script (correct C0D1 - replace 0 with your card number): Cold boot (off / on) and verify model: # cat /sys/module/snd_hda_intel/parameters/model generic,generic,(null),(null),(null),(null),(null),(null),(null),(nul),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) ---- #!/bin/bash SYSFS=/sys/devices/virtual/sound/hdaudioC0D1/hwC0D1 echo "0x0b 0x411111f0" > $SYSFS/user_pin_configs echo "0x0c 0x411111f0" > $SYSFS/user_pin_configs echo "0x0d 0x90170110" > $SYSFS/user_pin_configs echo "0x0e 0x411111f0" > $SYSFS/user_pin_configs echo "0x0f 0x0321101f" > $SYSFS/user_pin_configs echo "0x10 0x411111f0" > $SYSFS/user_pin_configs echo "0x11 0x03a11021" > $SYSFS/user_pin_configs echo "0x12 0xd5a30140" > $SYSFS/user_pin_configs echo "0x13 0x50d000f0" > $SYSFS/user_pin_configs echo "0x18 0x500000f0" > $SYSFS/user_pin_configs echo 1 > $SYSFS/reconfig ----
Thanks Jaroslav, it's what I expected. (BTW you can use patch module option for this.) So, either CA0132-specific verb or the firmware makes the output broken? What if you build without CONFIG_SND_HDA_CODEC_CA0132_DSP? Some fixes would be needed in addition to patch_ca0132.c like: --- a/sound/pci/hda/patch_ca0132.c +++ b/sound/pci/hda/patch_ca0132.c @@ -4654,8 +4654,8 @@ static void ca0132_config(struct hda_codec *codec) spec->unsol_tag_amic1 = 0x11; } else { spec->num_outputs = 2; - spec->out_pins[0] = 0x0b; /* speaker out */ - spec->out_pins[1] = 0x10; /* headphone out */ + spec->out_pins[0] = 0x0d; /* speaker out */ + spec->out_pins[1] = 0x0f; /* headphone out */ spec->shared_out_nid = 0x2; spec->unsol_tag_hp = spec->out_pins[1]; @@ -4704,13 +4704,13 @@ static int ca0132_prepare_verbs(struct hda_codec *codec) spec->spec_init_verbs[1].verb = AC_USRSP_EN | spec->unsol_tag_amic1; /* config EAPD */ - spec->spec_init_verbs[2].nid = 0x0b; + spec->spec_init_verbs[2].nid = 0x0d; spec->spec_init_verbs[2].param = 0x78D; spec->spec_init_verbs[2].verb = 0x00; /* Previously commented configuration */ /* - spec->spec_init_verbs[3].nid = 0x0b; + spec->spec_init_verbs[3].nid = 0x0d; spec->spec_init_verbs[3].param = AC_VERB_SET_EAPD_BTLENABLE; spec->spec_init_verbs[3].verb = 0x02;
Created attachment 197421 [details] HDA patch to reconfigure generic driver for line out 1
@Takashi: The above changes does not work. Even when I change the dac[0] to 6 (the NID 0x0d is connected to DAC 6). Note that even with the patched generic driver, I can output only noise - the samples are delivered to the analog path, but the output is very distorted (like when you use an incompatible sample format). I think that we should revert to the pre-DSP code which seems to work (at least I have some reports that the Recon3D hw works with very old kernels). It means create a new ca0132 model which won't load DSP and handle chipio initialization differently (old way). Also, I think that HP should be initialized to NID 0x0f by default. It's connected to DAC 2. But I don't know, if NID 0x10 is not for the DSP processing - it's really a bad thing to do something with the completely undocumented hardware. By the way, is Ian Minett still working for Creative?
I quote old Ian's reply from bug#55541: "The CA0132 codec was originally intended for and designed to support the Chromebook Pixel hardware architecture. I'm sorry to say that this means that the current codec isn't expected to work on other products that have different architectures, such as the Z series. Thank you very much for all the information and details you provided though, it is much appreciated, and I hope they may come in useful at a later date." I really think that the current DSP code is not designed for Recon3D / Z variants. I sent an e-mail to him. Let's see..
(In reply to Jaroslav Kysela from comment #11) > @Takashi: The above changes does not work. Even when I change the dac[0] to > 6 (the NID 0x0d is connected to DAC 6). Note that even with the patched > generic driver, I can output only noise - the samples are delivered to the > analog path, but the output is very distorted (like when you use an > incompatible sample format). OK, that was what I've been afraid of :-< > I think that we should revert to the pre-DSP code which seems to work (at > least I have some reports that the Recon3D hw works with very old kernels). > It means create a new ca0132 model which won't load DSP and handle chipio > initialization differently (old way). Yes. Or, maybe it's easier to use the generic parser. A quick test patch is attached below. It assumes that your board is 1102:0010. If not, let me know. > Also, I think that HP should be initialized to NID 0x0f by default. It's > connected to DAC 2. But I don't know, if NID 0x10 is not for the DSP > processing - it's really a bad thing to do something with the completely > undocumented hardware. It's really for the fixed mapping. At least, the current configuration works for a Recon3D I have and Chromebook Pixel. The latter was the very reason Google wanted to push the whole DSP stuff. > By the way, is Ian Minett still working for Creative? Honestly speaking, no idea. Let's try ping him.
Created attachment 197431 [details] Test fix patch
Thanks Takashi Iwai and Jaroslav Kysela, compiling the kernel now for ubuntu now but my SBZ device id is 1102:0023, but i've updated snd_pci_quirk ca0132_gen_fixup_tbl[] with: static const struct snd_pci_quirk ca0132_gen_fixup_tbl[] = { SND_PCI_QUIRK(0x1102, 0x0010, "Sound Blaster Z", CA0132_GEN_FIXUP_SBZ), SND_PCI_QUIRK(0x1102, 0x0023, "Sound Blaster Z", CA0132_GEN_FIXUP_SBZ), SND_PCI_QUIRK(0x1102, 0x0024, "Sound Blaster Z", CA0132_GEN_FIXUP_SBZ), SND_PCI_QUIRK(0x1102, 0x0027, "Sound Blaster Z", CA0132_GEN_FIXUP_SBZ), SND_PCI_QUIRK(0x1102, 0x0025, "Sound Blaster Zx", CA0132_GEN_FIXUP_SBZ), }; Let's see if it works...
You need to add ca0132_quirks[] for the same entries pointing CA0132_QUIRK_GENERIC_PARSER, too. Yes, it's a bit redundant. ca0132_quirks[] defines which mode to use (either DSP or generic parser) and ca0132_gen_fixup_tbl[] defines the additional fixups like pin configs.
FWIW, Recon3D I'm testing is 1102:0018. This seems working with DSP.
Wow. It's working. Thats for the first time ever i hear something out of my SBZ on linux. Nice job.
(In reply to Takashi Iwai from comment #17) > FWIW, Recon3D I'm testing is 1102:0018. This seems working with DSP. Perhaps, it might be wise to create a white list for these known as working devices. Test status: no functional change from the patched generic driver (distorted analog output) for PCI vendor IDs: 1102:0010 .. But at least something for the start.
Well it's only the line out that works. The rest stuff doesn't, no front panel, no headphones, and some white noise instead of a microphone. I think all 'Z' will work with this, and Zx should too. I'm not sure about ZxR since it has a different hadrware. I found the device id list for those soundblasters: http://www.driveridentifier.com/scan/sound-blaster-z/driver-detail/2CA0FFA4163A4571ABA716536248E5C7/1425131/28c90272498ec565b7734a40acf8a9e4/1198367637/HDAUDIO%5CFUNC_01%26VEN_1102%26DEV_0011%26SUBSYS_11020023
Hey, i've got the rear mic working with the generic parser using this pin config: static const struct hda_fixup ca0132_gen_fixups[] = { [CA0132_GEN_FIXUP_SBZ] = { .type = HDA_FIXUP_PINS, .v.pins = (const struct hda_pintbl[]) { { 0x0b, 0x411111f0 }, /* N/A */ { 0x0c, 0x411111f0 }, /* N/A */ { 0x0d, 0x90170110 }, /* lineout */ { 0x0e, 0x411111f0 }, /* N/A */ { 0x0f, 0x411111f0 }, /* N/A */ { 0x10, 0x411111f0 }, /* N/A */ { 0x11, 0x411111f0 }, /* N/A */ { 0x12, 0x01a190f0 }, /* mic */ { 0x13, 0x50d000f0 }, /* ? */ { 0x18, 0x500000f0 }, /* ? */ {} }, }, }; I've disabled headphone outputs because they are not working (for now).
The front headphone out is working: static const struct hda_fixup ca0132_gen_fixups[] = { [CA0132_GEN_FIXUP_SBZ] = { .type = HDA_FIXUP_PINS, .v.pins = (const struct hda_pintbl[]) { { 0x0b, 0x411111f0 }, /* N/A */ { 0x0c, 0x411111f0 }, /* N/A */ { 0x0d, 0x90170110 }, /* lineout */ { 0x0e, 0x411111f0 }, /* N/A */ { 0x0f, 0x411111f0 }, /* N/A */ { 0x10, 0x0221401f }, /* hp */ { 0x11, 0x411111f0 }, /* N/A */ { 0x12, 0x01a190f0 }, /* mic */ { 0x13, 0x411111f0 }, /* N/A */ { 0x18, 0x411111f0 }, /* N/A */ {} }, }, }; But it doesn't show as a separate device, e.g blocks the line out when i connect headphones.
Ok, seems to work fine at the moment: static const struct hda_fixup ca0132_gen_fixups[] = { [CA0132_GEN_FIXUP_SBZ] = { .type = HDA_FIXUP_PINS, .v.pins = (const struct hda_pintbl[]) { { 0x0b, 0x411111f0 }, { 0x0c, 0x411111f0 }, { 0x0d, 0x01017010 }, /* lineout */ { 0x0e, 0x411111f0 }, { 0x0f, 0x411111f0 }, { 0x10, 0x411111f0 }, { 0x11, 0x411111f0 }, { 0x12, 0x01a170f0 }, /* mic */ { 0x13, 0x50d000f0 }, { 0x18, 0x500000f0 }, {} }, }, }; I got distorted audio after booting to just compiled kernel but I turned PC off and removed the power, turned it back on and everything works fine, audio is crystal clear. Btw, I can't seems to get multi-channel audio to work. When I added pins for 0x11 (2nd jack) or front headphones (0x10), I get audio from them only if the rest are disabled. The rear hp out (0xf) does not work at all. It seems like it needs some kind of switch like its done on windows (you can't have simultaneous output from speakers and hp on windows either).
Yours is not 1102:0010? Please always put the PCI SSID and the board name as a comment. There are way too many different variants, and basically this bug is dedicated for 1102:0010 board, as the subject stands.
(In reply to Takashi Iwai from comment #24) > Yours is not 1102:0010? Please always put the PCI SSID and the board name > as a comment. There are way too many different variants, and basically this > bug is dedicated for 1102:0010 board, as the subject stands. Yeah, sorry, mine is 1102:0027 "Sound Blaster Z". ( But I checked the outputs and they report the same initial pin config and sensing so I think there is no colossal differences between 0010 and 0027 and most likely the rest of 'Z' boards, please excuse me if I,m wrong though, I'm still pretty new to this stuff and just trying to help).
My 2015 New Year’s resolution was to read more, and I can say, for the first time in my life, that I kept that resolution (I swear, next year, I will go to the gym more!). http://1tour.vn/ http://1tour.vn/khach-san/ http://1tour.vn/tour/ http://blog.1tour.vn/ http://1tour.vn/khach-san/sai-gon/ http://1tour.vn/khach-san/sapa/
(In reply to voron00 from comment #23) > Ok, seems to work fine at the moment: > > static const struct hda_fixup ca0132_gen_fixups[] = { > [CA0132_GEN_FIXUP_SBZ] = { > .type = HDA_FIXUP_PINS, > .v.pins = (const struct hda_pintbl[]) { > { 0x0b, 0x411111f0 }, > { 0x0c, 0x411111f0 }, > { 0x0d, 0x01017010 }, /* lineout */ > { 0x0e, 0x411111f0 }, > { 0x0f, 0x411111f0 }, > { 0x10, 0x411111f0 }, > { 0x11, 0x411111f0 }, > { 0x12, 0x01a170f0 }, /* mic */ > { 0x13, 0x50d000f0 }, > { 0x18, 0x500000f0 }, > {} > }, > }, > }; > > I got distorted audio after booting to just compiled kernel but I turned PC > off and removed the power, turned it back on and everything works fine, > audio is crystal clear. > Btw, I can't seems to get multi-channel audio to work. When I added pins for > 0x11 (2nd jack) or front headphones (0x10), I get audio from them only if > the rest are disabled. The rear hp out (0xf) does not work at all. It seems > like it needs some kind of switch like its done on windows (you can't have > simultaneous output from speakers and hp on windows either). Possibly the channel copying doesn't work on this codec (though I thought it rather specific to controller). If so, setting spec->gen.no_share_stream = 1 might be needed after snd_hda_gen_spec_init() line. What if you enable only each pin? For example, set the line out pinconfig to 0x0f and disable others. Then you get the output from 0x0f properly? Similar for other output pins?
(In reply to Takashi Iwai from comment #27) > (In reply to voron00 from comment #23) > > Ok, seems to work fine at the moment: > > > > static const struct hda_fixup ca0132_gen_fixups[] = { > > [CA0132_GEN_FIXUP_SBZ] = { > > .type = HDA_FIXUP_PINS, > > .v.pins = (const struct hda_pintbl[]) { > > { 0x0b, 0x411111f0 }, > > { 0x0c, 0x411111f0 }, > > { 0x0d, 0x01017010 }, /* lineout */ > > { 0x0e, 0x411111f0 }, > > { 0x0f, 0x411111f0 }, > > { 0x10, 0x411111f0 }, > > { 0x11, 0x411111f0 }, > > { 0x12, 0x01a170f0 }, /* mic */ > > { 0x13, 0x50d000f0 }, > > { 0x18, 0x500000f0 }, > > {} > > }, > > }, > > }; > > > > I got distorted audio after booting to just compiled kernel but I turned PC > > off and removed the power, turned it back on and everything works fine, > > audio is crystal clear. > > Btw, I can't seems to get multi-channel audio to work. When I added pins > for > > 0x11 (2nd jack) or front headphones (0x10), I get audio from them only if > > the rest are disabled. The rear hp out (0xf) does not work at all. It seems > > like it needs some kind of switch like its done on windows (you can't have > > simultaneous output from speakers and hp on windows either). > > Possibly the channel copying doesn't work on this codec (though I thought it > rather specific to controller). If so, setting spec->gen.no_share_stream = > 1 might be needed after snd_hda_gen_spec_init() line. > > What if you enable only each pin? For example, set the line out pinconfig > to 0x0f and disable others. Then you get the output from 0x0f properly? > Similar for other output pins? The spec->gen.no_share_stream = 1; didnt work, kerenl build failed, but i've searched through kernel source tree and found spec->gen.multiout.no_share_stream = 1; but that didn't change anything. What i tried: Line out 1 and 2: 0x0d, 0x01017010 0x11, 0x01017014 or 0x01017011 Not working: when i try to set speaker mode to quad - audio gets distorted from line out 1 and and no audio comes from line out 2. Line out 1 and front hp: 0x0d, 0x01017010 0x10, 0x022140f0 or 0x02214011 or 0x02214014 Not working: no audio from both. The rear hp (0xf) not working at all, even when i disable others. There is still no line out 3, no sense for it, like its not even exists..but should be. And i cant test digital in/outs, don't have any digital hardware.
(In reply to voron00 from comment #23) > Ok, seems to work fine at the moment: > > static const struct hda_fixup ca0132_gen_fixups[] = { > [CA0132_GEN_FIXUP_SBZ] = { > .type = HDA_FIXUP_PINS, > .v.pins = (const struct hda_pintbl[]) { > { 0x0b, 0x411111f0 }, > { 0x0c, 0x411111f0 }, > { 0x0d, 0x01017010 }, /* lineout */ > { 0x0e, 0x411111f0 }, > { 0x0f, 0x411111f0 }, > { 0x10, 0x411111f0 }, > { 0x11, 0x411111f0 }, > { 0x12, 0x01a170f0 }, /* mic */ > { 0x13, 0x50d000f0 }, > { 0x18, 0x500000f0 }, > {} > }, > }, > }; > > I got distorted audio after booting to just compiled kernel but I turned PC > off and removed the power, turned it back on and everything works fine, > audio is crystal clear. > Btw, I can't seems to get multi-channel audio to work. When I added pins for > 0x11 (2nd jack) or front headphones (0x10), I get audio from them only if > the rest are disabled. The rear hp out (0xf) does not work at all. It seems > like it needs some kind of switch like its done on windows (you can't have > simultaneous output from speakers and hp on windows either). from windowz driver's inf there are pin tables and codec configs for gpio,dac mapping and configuration, Max Volume Clamp, Alternate Endpoint Names vb... microsoft(generic hda) and creative drivers have same values on registry registry for example 1102:0023 there are front panel detect ad front mute pin ;GPIO Configuration ;Z Series HKR,CodecConfig\11020023,AntiPop_MutePin, 0x00010001,0x00000000 HKR,CodecConfig\11020023,ExternalDACReset_Pin, 0x00010001,0x00000005 HKR,CodecConfig\11020023,ExternalDAC_192KSR_SelPin, 0x00010001,0x00000001 HKR,CodecConfig\11020023,FP_DetectPin, 0x00010001,0x03010002 HKR,CodecConfig\11020023,Front_MutePin, 0x00010001,0x00010007 HKR,CodecConfig\11020023,HPAMP_SHDNPin, 0x00010001,0x02010004
Can we at least merge that stuff to get the line out/mic working on Z/Zx? It's been a while and better than nothing i guess.
I have a PCIID for the Sound Blaster Z not yet listed here (1102:0012). Device works if the correct IDs are added to the patch.
(In reply to Michael Holmes from comment #31) > I have a PCIID for the Sound Blaster Z not yet listed here (1102:0012). > Device works if the correct IDs are added to the patch. Oh, interesting. Same ID here.
(In reply to Christian Mertes from comment #32) > (In reply to Michael Holmes from comment #31) > > I have a PCIID for the Sound Blaster Z not yet listed here (1102:0012). > > Device works if the correct IDs are added to the patch. > > Oh, interesting. Same ID here. Same ID for me! 02:00.0 Audio device [0403]: Creative Labs SB Recon3D [1102:0012] (rev 01)
Update: In Manjaro, kernel 4.8RC8 makes front panel audio working out of the box.
If I patch kernel 4.8.1 with voron00's patch, front panel audio is gone but rear mic and rear speakers work.
Comment on attachment 197091 [details] alsa-info.sh output The issues are (at least): - Probably non-working analogic Microphone input (rear, first pin) - Non-working Headphone analogic output (rear, second pin) - Non working Front analogic output (rear, third pin) “Non-working” as in “no sound comes out of it”. Although it’s recognized by pulseaudio and the “volume” bar in pavucontrol moves with the music. Please let me know if you need any more details on the hardware, or if you need me to do some tests. Thank you very much for you time on this issue. http://maylocnuocviet.org http://www.thuoc-la-dien-tu.com http://thanhlycuongphat.com http://thanhlycuongphat.com/thanh-ly-phong-net/ http://thanhlycuongphat.com/mua-may-tinh-cu/ http://thanhlycuongphat.com/linh-kien-may-tinh/ http://thanhlycuongphat.com/sang-tiem-net/ https://goo.gl/maps/YpszJ9Si2j72 https://www.facebook.com/thanhlycuongphat https://tourhalong1ngay.com https://toursapagiatot.com http://vnco.net http://www.cantho60s.com https://maylocnuocviet.org/may-loc-nuoc/may-loc-nuoc-kangaroo/ https://maylocnuocviet.org/may-loc-nuoc/may-loc-nuoc-geyser/ https://maylocnuocviet.org/may-loc-nuoc/may-loc-nuoc-karofi/ https://maylocnuocviet.org/may-loc-nuoc/may-loc-nuoc-nano/
would it be possible to use some program that would try all possible ids until it finds one that works?
I have a Sound Blaster Z, pci-id [1102:0012] . Audio through the front headphone port works by default in Linux Mint 18 with kernel 4.4.0. As far as I can gather, it seems as if the DSP code is what is causing the problems, which has already been established. It works for the front headphone port, but when switched to speakers, whatever command is sent to the DSP keeps the audio from going to the line out. If I toggle the EAPD while my speakers are connected to line out, I get a popping noise, so the pins seems to be correctly identified. I also checked each pin with the hdajacksensetest tool, and all pins detect properly except for the center/sub output and front mic port. The SPDIF ports don't detect, but I'm not sure if they ever do. Earlier in this chain, it was said that the DSP is from a chromebook? From looking through the driver, and I may be incorrect, but it seems like the DSP is loaded at every boot up. Could the DSP for the Sound Blaster Z be borrowed from the Windows driver, or are they likely the same code? Is there a way to run the Sound Blaster Z inside of a Windows virtual machine with vt-d, and capture the commands sent to the dsp from there? I'm just now learning all of this stuff, and I'm willing to put time into solving this. If anyone has any info on whether or not it's possible to capture communications through a virtual machine, I think that's probably the best way to definitively get the commands that need to be sent to the DSP. I have found some articles on people reverse engineering Nvidia's drivers that way. Anyways, if anyone has any more insights or ideas, it'd be nice to hear them. Thanks.
Update since my previous post, not sure if this is the appropriate place to post or if anyone is still reading this, but I feel like I've made a bit of progress. Inside of the windows registry there is a list of pin configurations for each variation of the card, they're grouped by pci sub-id's. I have been able to track the commands coming from the PCI port, but they're just pointers sent to the card for DMA. I either need to find out where windows stores DMA info or try to get the info from the program through debugging. I'm currently doing the debugging route. Anyways, here's what I've gotten from the registry for pin configs. [OriginalPinConfig\11020023] It says this is the original pin config for my card. "Config_0B"=dword:410140f0 "Config_0C"=dword:014520f0 "Config_0D"=dword:010171f0 "Config_0E"=dword:01c510f0 "Config_0F"=dword:412000f0 "Config_10"=dword:022140f0 "Config_11"=dword:418120f0 "Config_12"=dword:01a190f0 "Config_13"=dword:50d000f0 "Config_18"=dword:500000f0 [0000\PinConfig] "Config_0B"=dword:01014110 "ConfigEx_0B"=dword:00000002 "Config_0C"=dword:014510f0 "ConfigEx_0C"=dword:00000004 "Config_0D"=dword:014510f0 "ConfigEx_0D"=dword:00000006 "Config_0E"=dword:01c520f0 "ConfigEx_0E"=dword:00000005 "Config_0F"=dword:0221401f "ConfigEx_0F"=dword:00000002 "Config_10"=dword:01016011 "ConfigEx_10"=dword:00000014 "Config_11"=dword:01013014 "ConfigEx_11"=dword:00000083 "Config_12"=dword:01a190f0 "ConfigEx_12"=dword:00000051 "Config_13"=dword:908700f0 "ConfigEx_13"=dword:00000000 [PinConfig\11020016] "Config_12"=dword:02a190f0 "ConfigEx_12"=dword:00000051 [PinConfig\11020023] "Config_0B"=dword:01017010 "ConfigEx_0B"=dword:00000002 "Config_0F"=dword:0121701f "ConfigEx_0F"=dword:00000002 "Config_10"=dword:01017011 "ConfigEx_10"=dword:00000014 "Config_11"=dword:01017014 "ConfigEx_11"=dword:00000083 "Config_12"=dword:01a170f0 "ConfigEx_12"=dword:00000051 [PinConfig\11020024] "Config_0B"=dword:01017010 "ConfigEx_0B"=dword:00000002 "Config_0F"=dword:0221701f "ConfigEx_0F"=dword:00000002 "Config_10"=dword:01017012 "ConfigEx_10"=dword:00000014 "Config_11"=dword:01017011 "ConfigEx_11"=dword:00000083 "Config_12"=dword:01a170f0 "ConfigEx_12"=dword:00000051 [PinConfig\11020025] "Config_0B"=dword:01017010 "ConfigEx_0B"=dword:00000002 "Config_0F"=dword:0221701f "ConfigEx_0F"=dword:00000002 "Config_10"=dword:01017012 "ConfigEx_10"=dword:00000014 "Config_11"=dword:01017011 "ConfigEx_11"=dword:00000083 "Config_12"=dword:01a170f0 "ConfigEx_12"=dword:00000051 [PinConfig\11020033] "Config_0B"=dword:01047110 "ConfigEx_0B"=dword:00000002 "Config_0C"=dword:414510f0 "ConfigEx_0C"=dword:00000004 "Config_0D"=dword:014510f0 "ConfigEx_0D"=dword:00000006 "Config_0E"=dword:41c520f0 "ConfigEx_0E"=dword:00000005 "Config_0F"=dword:0122711f "ConfigEx_0F"=dword:00000002 "Config_10"=dword:01017111 "ConfigEx_10"=dword:00000004 "Config_11"=dword:01017114 "ConfigEx_11"=dword:00000083 "Config_12"=dword:01a271f0 "ConfigEx_12"=dword:00000051 "Config_13"=dword:908700f0 "ConfigEx_13"=dword:00000000 There's also a set of "PinConfigOverrideVerbs" that may prove useful in getting audio output out of the rear line out. I will try them eventually. Does anyone know anything about the DSP? Does it have to be loaded in on startup, is it a file? I guess using the generic HD audio would work well enough, but it would be interesting to at least be able to get Dolby live and stuff working. If there's a better place to put all this, let me know. Thanks.
(In reply to Connor M from comment #39) > ... > If there's a better place to put all this, let me know. Thanks. Hello! Any updates on this?