Thanks, it almost works now !
Actually it requires the AZX_DCAPS_NO_MSI (otherwise dma doesnt work) and AZX_DCAPS_POSFIX_LPIB (otherwise sound is stuttered) and no snoop. There is still an issue with the sound volume : it's very low, I have to put my speakers to 100% of their power to actually hear something. Otherwise sound is ok, no more crakling as with single_cmd mode.
Dmesg also complains about a db Mismatch, I suspect it's related to the issue. If I remove the patching ops in snd_hda_codec_build_controls the error goes away but there is no more sound and the digital output control disappear too. I dont know which patch is applied (cmedia ?).
[ 2.483128] snd_hda_intel 0000:01:00.1: enabling device (0000 -> 0002) [ 2.483238] snd_hda_intel 0000:01:00.1: Handle VGA-switcheroo audio client [ 2.483282] snd_hda_intel 0000:01:00.1: irq 50 for MSI/MSI-X [ 2.483454] snd_hda_intel 0000:02:00.0: enabling device (0000 -> 0002) [ 2.483494] snd_hda_intel 0000:02:00.0: Disabling MSI [ 2.489701] snd_hda_intel 0000:01:00.1: no codecs initialized [ 2.511016] sound hdaudioC1D1: autoconfig: line_outs=4 (0xc/0xe/0xd/0xf/0x0) type:line [ 2.511018] sound hdaudioC1D1: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 2.511019] sound hdaudioC1D1: hp_outs=1 (0x10/0x0/0x0/0x0/0x0) [ 2.511020] sound hdaudioC1D1: mono: mono_out=0x0 [ 2.511021] sound hdaudioC1D1: dig-out=0x14/0x0 [ 2.511021] sound hdaudioC1D1: inputs: [ 2.511022] sound hdaudioC1D1: Mic=0x12 [ 2.511023] sound hdaudioC1D1: Line=0x15 [ 2.511024] sound hdaudioC1D1: Aux=0x13 [ 2.523844] ALSA sound/pci/hda/hda_codec.c:2792 hda_codec: Mismatching dB step for vmaster slave (-100!=1000)
Regards, Vincent
Le Lundi 4 août 2014 13h28, Takashi Iwai tiwai@suse.de a écrit :
At Sun, 3 Aug 2014 14:05:44 -0700, Vincent Lejeune wrote:
Hi,
I just found this thread http://thread.gmane.org/gmane.linux.alsa.devel/116096 I'm trying to find what can make the CMI8888 not work in non single_cmd mode and it looks more and more like a DMA issue. I don't have an "iommu mode" option in my bios like Geoffrey McRae, it looks like an AMD only option, and using bigger page size/alignement constraint didnt solve the issue. However I added some code to dump the content of the rirb buffer in the update_rirb() function and I copied it below.
The first command seems to be correctly handled the second time it is send to the hardware. As the AZX_DCAPS_*DELAY_RIRB doesnt change anything, I'm starting to think that the corb engine may require some delay to be processed. Is there a way to spy the dma transfer request from the device point of view ? I'd like to know when the cmi8888 request a dma read from the corb buffer and when it requests a dma write to the rirb buffer to determine if it parses the corb buffer correctly or not.
Well, if the CORB RP is updated, it essentially means that the CORB has been updated. Did you already try snoop=false option? Also, AZX_DCAPS_RIRB_PRE_DELAY might be worth to try.
In addition the first value returned is very odd : 13f68888. The pci id of the phoebus is 13f6:5011. What does the 100f0001 cmd mean ? hda-decode-verb tells me the verb is "0x0"...
This is the codec IDs, which is often different from the PCI IDs.
thanks,
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel