midi synth +sf produces rattling/chattering sound on 3553

[kreksoverzum]

I encountered exactly the same problem with soundfonts as mole2old in this post: Hardware heaven forum and, possibly Hardware heaven forum #2 On 3552 version and before there was a complete silence. This is a first version that produced ANY sounds. I tried several soundfonts but result is the same. I recorded audio directly from synth output (FXBus12 & FXBus13) soundcloud In this particular sample simple sequence C-E-G-E-C is played with different instruments My hardware: PCI\VEN_1102&DEV_0004&CC_040100 (SB0160) What else information can i provide?

[kreksoverzum]

Just tried v3550 - same result

[pmghub]

It works with Win7 x86, but not with x64!

Same problem here, tested my SB0220 card, with 3550-3553 drivers on multiple platforms (Intel, AMD), Win7, Win10, etc., audio fine but midi always bugged (soundcloud sample, yes, exactly that). Then I pulled out a fresh install of Win7 Pro SP1, this time x86, and it worked like charm (although midi synth volume slider is still missing from kx mixer). For verification, fresh OS install from the same media, this time x64, midi synth bug came back.

[linnaea]

My hunch is that given how old the cards are, they probably cannot perform 64-bit addressing and ends up reading garbage from system RAM (which is where the soundfonts are stored).

Should be fixable by changing the driver to force allocations to be below 4GB, but that would break digital signature and the fixed driver would require the OS to be put into test mode to be loaded.

[kreksoverzum]

@linnaea , i found some information about the roots of the problem. I guess you knew that, but what if not? https://bugs.launchpad.net/ubuntu/+source/awesfx/+bug/183456/comments/10

I place the quote just in case source will become unavailable:

The problem with this goes a bit deeper. The reason for all this trouble is that the emu10k1 chipset requires DMA from main memory to pick up the samples, and - unfortunately - the DMA engine of the chip is broken. Instead of using the full range of 32 bit DMA available on the PCI bus, it only addresses 31 bit of the 32 available.

To work around this problem, the kernel driver first allocates a page of main memory, signaling the 32 bit DMA memory "zone", i.e. indicating the kernel that it requires 32 bit memory in a 64 bit memory system. However, if now the returned memory happens to have bit 31 set, the emu10k1 wouldn't be able to address the memory. Then, the driver releases the memory again, and requests memory in the 16MB "ISA" memory region, which is clearly suitable for the chip. Unfortunately, this type of memory runs out easily, and then the chip is left with no usable memory at all.

The problem is that the kernel isn't smart enough to provide memory that is "just right" for the chip, i.e. the "DMA zone" allocation isn't quite sufficient for this situation. There seem to be plans on the LKLM to address this, but it's unclear how long this will take - after all, the complete kernel page allocator must be re-structured to fix this.

How to work around? Oh well, the easiest is to lower the 32bit PCI DMA zone from 4G to 2G. This means that some non-broken devices will require to allocate pages in the 2GB region (bad enough), and the memory layout might be sub-optimal for those devices, but at least the hack will work.

For that, download the kernel, and edit arch/x86/include/asm/dma.h, locate the line:

define MAX_DMA32_PFN ((4UL 1024 1024 * 1024) >> PAGE_SHIFT)

and replace the 4UL by a 2UL, which will shrink the 32-bit DMA zone by half. This is not a permanent solution - it's an ugly bad hack that is "good enough for me". There is no kernel boot option to do this AFAIK.

So long, happy hacking,

Thomas

[mirh]

https://github.com/torvalds/linux/commit/7241ea558c6715501e777396b5fc312c372e11d9 and/or https://github.com/torvalds/linux/commit/04f8773a3e980f60953e7aeb36ec6c2631e11f10 should have handled it neatly.. Could you actually confirm it's still a problem even on linux?

[kreksoverzum]

Thank you for your reply, i will recheck it in a week i hope