3538J: Noise level on input LINE3 above acceptable value!

Shinco

I am using 3538 I/J versions of the driver. A month ago I bought a new synth module and started to use the line3 input om my SB0280 module. It all seems to work well, however sometimes the noise level goes sky high for no apparent reason. I disconnected the synth, tried other versions of the driver. Nothing seems to work.

For example the last time after a system start, levels were high. A lot of noise comes out of the speaker (50/45dB). The only thing I did was power down the system and power up again. Then levels were at normal values (80/85dB). Sometimes this happens at other times when working with the card through software. It looks as if the KX driver forgets to initialize registers in the DSP?! I haven't got a clue. Reloading settings from a file or setting the unit to it's defaults does not elliminate the problem. Muting the LINE3 input kills all the noise.

Also it seems like the occurence of this is more frequent with the 3538J driver en the 3538I driver.

I have read the other articles on noise, but they do not seem to apply here.

Anny suggestions are appreciated!

Shinco

Max M.

well, there were a few threads on this. It's quite old but still not fixed issue: "Random noise on inputs of all Platinum EX models". Currently there's no solution available (except rebooting when noise level is high). Just keep reminding this issue to Eugene from time to time.

Shinco

Thank you very much Max. At least I know now that it is not a local problem!

Eugene Gavrilov

currently, there's no way to fix this. probably, some kind of undocumented initalization code..

Shinco

That's a pitty. I have to reboot about 15% of the time to get rid of the noise.

Shinco

Could I get a peek at the init code and schematics? I could try to search for gaps...

Eugene Gavrilov

the code is quite complex and was retrieved by spying creative labs drivers' I/O
this code is 'black box' for me, since it just sets/clears the bits in some order, but I don't know what sequence is required and why

the main idea is to set/clear GPIO bits (hardware register 0x18 for 10k2, see 8010.h)
this register is accessible via kX API, so, you can write a sample application

please review ALSA drivers for details (they program GPIO bits in a very simplified manner)
let me know (by -e-mail-!) if you manage to figure out anything -- I don't browse the forums often, so my reply here won't be fast enough

sometimes disable/enable in the devman fixes the problem (don't forget to unload kxmixer)
sometimes you need to disconnect/reconnect the external module (don't forget to execute kxctrl -dbr to re-initialize the module)
sometimes just kxctrl -dbr solves the problem

at the moment, we have no reliable information about this topic...

E.

Eugene Gavrilov

also, pls get the ALSA drivers and review the lines referring to 'enabling alice3'
alsa-driver/alsa-kernel/pci/emu10k1/emu10k1_main.c:

find the function snd_emu10k1_init()
and check (emu->card_capabilities->ca0151_chip) /* audigy2 */
initialization code

in their previous version (released 2 years ago or so), there was a message from CL:

//Hacks to work independent of haP16V driver
CTDWORD dwTemp;

//Setup SRCMulti_I2S SamplingRate
dwTemp = crOsReadPtrDword(m_crosid, EHC);
dwTemp &= 0xfffff1ff;
dwTemp |= (0x2<<9);
crOsWritePtrDword(m_crosid, EHC, dwTemp);

(this corresponds to iKX:tr_write(0x76,0,...)

//Setup SRCSel (Enable Spdif,I2S SRCMulti)
crOsWriteDword(m_crosid, 0x20, 0x600000);
crOsWriteDword(m_crosid, 0x24, 0x14);

this correponds to iKX:16v_write(0x60,0x14);

//Setup SRCMulti Input Audio Enable
crOsWriteDword(m_crosid, 0x20, 0x6E0000);
crOsWriteDword(m_crosid, 0x24, 0xFF00FF00);

note: kX uses differen value

//Setup I2S ASRC Enable
dwTemp = crOsReadDword(m_crosid, HC);
dwTemp |= 0x00000070;
crOsWriteDword(m_crosid, HC, dwTemp);

// Unmute Analog now. Set GPO6 to 1.
// This has to be done after init I2SOut beyond 48KHz.
// So, sequence is important.
CTDWORD dwValue = crOsReadDword(m_crosid, GPIO);
dwValue |= 0x0040;
crOsWriteDword(m_crosid, GPIO, dwValue);

this corresponds to iKX::fn0_write(0x18,value);
kX does always set GPIO the very last register in the initialization sequence...
----

by using kX API, you can re-set GPIO, I2SOut etc. registers to their power-on values and try to initialize the registers in some particular order...

E.