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).
(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.
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?
I have gathered some experience with verbs that probably give us more functionality Also made some changes at the driver and rebuild the modules but there is no ca0132 module. I don't know what's wrong, can someone please give me some infos how to build and load the ca0132 module?.Thanks
I've been at this for two months now, and as far as I can tell, just getting generic audio without the DSP shouldn't be too difficult. Just remove the init params, flags, the verb sequences and fix the pin configs. Also, by default, the CA0132 driver has the outputs wrong. Line-out for the SBZ is widget 0x0B, and the headphone out is 0x0F, not the front out like is currently configured. I haven't gotten to it yet, but to get it to work, I think you'd have to setup that front headphone gets output from DAC node 0x03, and node 0x02 only drives rear headphone and lineout. I'm pretty close to having the DSP's configuration under Windows worked out, and have been able to borrow the DSP firmware from the Windows file and confirm that it loads under Linux. All I have left to do is put it all together in the driver, compile it and see if it works. Of course, that's only just to test if it works, there's a lot of loose ends I'll have to tie up. I can give more info if anyone is interested.
Not sure if double posting is against the rules, but since I can't edit my last comment, I will just post again. I've written a program that dumps the HDA verbs from QEMU in real time. I've got all of the outbound verbs and responses from Windows, and have isolated what Windows does when switching inputs, enabling the EQ, etc. I've deciphered almost all of them, and only have a few left to figure out. If anyone is interested in seeing these, just let me know. The only thing I've yet to really look into is the MMIO space Region 2. Region 0 is obviously for HDA related stuff, but region 2 quite a few times under Windows. I'm not sure if it's necessary to get audio working, but if it is, it could make things a little more complicated. Anyways, if anyone has any insights, it'd be nice to hear. Thanks.
(In reply to Connor M from comment #43) > Not sure if double posting is against the rules, but since I can't edit my > last comment, I will just post again. > > I've written a program that dumps the HDA verbs from QEMU in real time. I've > got all of the outbound verbs and responses from Windows, and have isolated > what Windows does when switching inputs, enabling the EQ, etc. I've > deciphered almost all of them, and only have a few left to figure out. If > anyone is interested in seeing these, just let me know. > > The only thing I've yet to really look into is the MMIO space Region 2. > Region 0 is obviously for HDA related stuff, but region 2 quite a few times > under Windows. I'm not sure if it's necessary to get audio working, but if > it is, it could make things a little more complicated. > > Anyways, if anyone has any insights, it'd be nice to hear. Thanks. Hi Connor M, it would be cool if you could share your findings. I also try to figure out how to initialise the DSP. I'm a macOS user where i can use 5.1. front, rear headphones and microphones. Can you please tell what i need to compile the CA0132 module @Linux? Thanks
Ok, so i've made some progress. Since we know that the firmware is for the ChromeBook Pixel and does not work properly on desktops, i've made some adaptations. Until now i can switch between speakers and both headphones, no mute while disabling surround, activated the Equalizer, working analogue microphone. I have no 5.1 speakers for testing, but I will try to adapt the firmware to external cards. Yet another silly question. Is there a way to unload the sound module, and load the newly builded?. Every time i build the sound module, i have to install them all, which takes some time :-(. Here the pictures of the alsa mixer. https://www2.pic-upload.de/img/34699677/Bildschirmfotovom2018-01-2117-14-06.png https://www2.pic-upload.de/img/34699695/Bildschirmfotovom2018-01-2117-15-06.png
I've got sound working now with the DSP enabled. I'm currently cleaning up the driver, and I'll figure out where to put it up once I'm done.
Thank you for the effort in fixing this 7 years problem. Creative could fix this easily but they don't care. I'm curious to know if a solution is found for the nosound problem if this will eventually get integrated in mainline kernel?
Once I've got my version of the driver cleaned up, I'll go through the process of submitting it. Shouldn't take me more than a week.
Not sure if link sharing is allowed here, but, I've got an early version of the firmware and the driver available. You'll have to compile it on your own, and put the firmware file in your /lib/firmware folder. Replace the ctefx.bin file with the one I've got. So far, it has only been tested on Sound Blaster Z's with the subsys number 0023. You have to go into alsamixer on startup and select the auto detect speaker function, and then you get audio. Only works with rear lineout and rear headphone so far, but the DSP works with it. It's taking me a little longer than I thought to get it all sorted, but a final version shouldn't take more than a week or two. I may need testers for the other models of SBZ. Here's my Google Drive with the files included: https://drive.google.com/open?id=1r-X8g6It5AO7SwgJc1JQfJ8KCOyqrr_d
If anyone downloaded yesterday, I uploaded an older version. Fixed version is up now.
(In reply to Connor M from comment #50) > If anyone downloaded yesterday, I uploaded an older version. Fixed version > is up now. may you tell how compile this ?
Have microphone working now, will upload to my Google drive once my code is a little cleaner. Getting closer day by day.
Here are some findings regarding Sound Blaster. I have tried both Z and AE-5. They behave exactly the same: - Front audio port works with HP Mode enabled in alsamixer. - Back microphone works if mic1 is enabled. Sometimes however the front audio port does not work when booting, and I need to re-insert the cable for it to work. I am pretty certain the AE-5 is just a Z with LED features (I upgraded because the red LED on the Z was incredibly annoying, the AE-5 has all LED features disabled by default, thankfully). So any fixes applied to the Z series should apply for the AE-5. I can provide any information regarding the card or do tests if needed.
I would also like to know how to compile this so I can test this on Debian.
I wonder where Connor is? I hope he is fine. You can try the following link to compile the kernel https://kernelnewbies.org/KernelBuild Alternatively, I can give you my precompiled binaries from Ubuntu Kernel 4.14.3, but I'm not sure if they're compatible.
Created attachment 274673 [details] Sound BlasterX AE-5 dmesg
Created attachment 274675 [details] Sound BlasterX AE-5 lshw
Operating system fails to load with the following error messages: hdaudio hdaudioC0D0: Unable to bind the codec hdaudio hdaudioC1D1: Unable to bind the codec Tested with Creative Sound BlasterX AE-5 which behaves the same as my previous Sound Blaster Z (front port audio works, back port microphone works). Included lshw and dmesg as attachments. Feel free to ask me if you want me to run commands.
Just sent you an email Wern, didn't see your last one. Frederique, it looks like you're probably using an early version of the driver or the stock one, because the DSP downloads twice. I fixed that in newer versions. Also, it makes sense that the front headphone port would be similar across the devices, which is why it works on just about all of them. But the Sound BlasterX AE-5 has a different DAC than the Sound Blaster Z, and the Sound Blaster Z has a different DAC than the Recon3D. The connections to that DAC are where the issues come in. The SBZ reroutes ConnPoint's to deal with this, specifically 0x48 to 0x91. The stereo direct option, which supposedly bypasses the DSP and goes straight to the DAC, does even different routing, 0x41 to 0x91. So it wouldn't be surprising if the SBX AE-5 has a similar system, maybe with different ConnPoint's. The only way for me to really know would be to have someone with one run my QemuHDADump program with a virtual machine using windows with VFIO on the card. I'll happily help once I've finished getting full functionality on my own card, but all I can offer until then is to answer questions.
If you provide me a step by step on the QemuHDADump / VFIO I would be more than happy to do it.
Also those logs were made with the default driver as the system would not boot with your driver and firmware.
If you're not running a Sound Blaster Z, I would not advise trying my current driver. The QemuHDADump is kind of a process, if you give me a day or two I can write a guide on how to do it. I'm kind of busy currently.
Okay, I now have full functionality with the DSP. All inputs work, front mic, rear mic, and then line-in on the rear port. Both digital in and out work, front and rear headphone auto-detect works, line out works and surround works too. Input effects work, and so do the output effects. I'm going to write a guide on how to create the dumps for the other cards in order to get full functionality across all the Sound Blaster Z variants in a couple of days hopefully, I'll post it on the Creative Forums. I've updated my Google drive with the current patch. Once again, if you do not have a Sound Blaster Z, I would not try it. It shouldn't break like it used to, but I can't say it won't. Hopefully I can find people who have the other variants willing to help. I would like to get this fully solved and over with.
One of the side concerns I am having. What license can be attached to this? The modified firmware, you grabbed this from a setup intended for a Google notebook device? This falls under Creative copyright restrictions. If there is no source for the binary it can only be spread as non-free. And this would require a license that permits modification and distribution. Please keep this in mind before a lot more effort is put into this. A lot of finished work might go to waste simply due to license issues. Thank you for the work so far, regardless!
One of the side concerns I am having. What license can be attached to this? The modified firmware, you grabbed this from a setup intended for a Google notebook device? If there is no source for the binary it can only be spread as non-free. And this would require a license that permits modification and distribution. Please keep this in mind before a lot more effort is put into this. A lot of finished work might go to waste simply due to license issues. On Sun, 2018-04-01 at 00:06 +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=109191 > > --- Comment #63 from Connor M (Conmanx360@gmail.com) --- > Okay, I now have full functionality with the DSP. All inputs work, > front mic, > rear mic, and then line-in on the rear port. Both digital in and out > work, > front and rear headphone auto-detect works, line out works and > surround works > too. Input effects work, and so do the output effects. I'm going to > write a > guide on how to create the dumps for the other cards in order to get > full > functionality across all the Sound Blaster Z variants in a couple of > days > hopefully, I'll post it on the Creative Forums. > > I've updated my Google drive with the current patch. Once again, if > you do not > have a Sound Blaster Z, I would not try it. It shouldn't break like > it used to, > but I can't say it won't. > > Hopefully I can find people who have the other variants willing to > help. I > would like to get this fully solved and over with. >
I have thought of this, and am not entirely sure on the distribution issue. The firmware was taken from the Windows driver, which is distributed freely, but I am not 100% sure about the legality of redistributing it. I asked on the mailing list awhile ago and got no response, but I probably just poorly worded my email. Honestly, I'm fine if I'm only able to use it and can't distribute it. Anyone could download the Windows driver and extract the firmware. I wanted to get sound working for myself, and I did. The firmware for the Chromebook is similar, and honestly I haven't tried it with the Chromebook firmware, I just suspect it wouldn't work. Maybe I should see what it does. I guess Creative could make a big deal out of it, but if that's the case then they could have just made the friggen driver themselves. It's been almost six years since the Sound Blaster Z was released, and they seemingly have no motivation to help Linux users. This only took me so long because I'm inexperienced. They have the documentation, and could've written this driver in no time. The core driver is literally 80-90% of the work already done. I just don't see them caring. I'll probably find out if I post about it on their forums pretty quickly.
Usually the driver package where you obtained it from should contain license information, or the download page should refer to a copyright. If none, it is by default under copyright by Creative without permission to modify or distribute, sadly.
I have emailed Creative, hopefully they get back to me. If not, there are other drivers where you have to extract the firmware yourself. It is still possible for others to use it if Creative makes a big deal, they'll just have to get the firmware themselves.
I had no luck with contacting Creative in this regard. They have always been horrible with drivers, even trying to charge people for Windows XP to Windows Vista driver upgrade. Only the X-Fi releasing as free software was exceptionally surprising. One thing you can do is load the firmware from the hardware.
Hi, I'd like to report an issue with the driver for this audio card, specifically for the one on my motherboard. My motherboard is a Gigabyte Z370 Aorus Gaming Wifi. It has the Creative Recon3Di for the audio. My problem is that, seemingly randomly, the audio stops working after a reboot. I no longer get any output from the motherboard audio on the rear or front panels. Although, everything LOOKS to be working fine, I just get now audio. The device shows up properly in KDE Plasma and in alsamixer (I'm using Pipewire btw). The ONLY fix that I've found so far is booting into Windows 10 (I dual boot on my PC) and changing around the drivers for my motherboard audio in the device manager. BTW, when this issue happens, usually the audio ALSO does not work in Windows and has the exact same symptoms. Actually I made a bug report for this issue with Pipewire, because I thought that might be the issue. Here's the issue: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3498 A reply to that issue is how I got here. My kernel version is 6.4.12-arch1-1
(In reply to Sean Ramey from comment #73) > Hi, I'd like to report an issue with the driver for this audio card, > specifically for the one on my motherboard. > > My motherboard is a Gigabyte Z370 Aorus Gaming Wifi. It has the Creative > Recon3Di for the audio. > > My problem is that, seemingly randomly, the audio stops working after a > reboot. I no longer get any output from the motherboard audio on the rear or > front panels. Although, everything LOOKS to be working fine, I just get now > audio. The device shows up properly in KDE Plasma and in alsamixer (I'm > using Pipewire btw). > > The ONLY fix that I've found so far is booting into Windows 10 (I dual boot > on my PC) and changing around the drivers for my motherboard audio in the > device manager. BTW, when this issue happens, usually the audio ALSO does > not work in Windows and has the exact same symptoms. > > Actually I made a bug report for this issue with Pipewire, because I thought > that might be the issue. Here's the issue: > https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3498 > > A reply to that issue is how I got here. > > My kernel version is 6.4.12-arch1-1 Oh forgot to mention, this issue sounds like it is similar to my issue: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1658528