Temragon

This issue has been solved. Remaining issues are likely buffer issues (See below)



So we don't get more varied threads here, Russ dug up a old post explaining the problem: http://www.hardwareheaven.com/general-...ml#post1168448

This affects ALL versions of windows.
XP x86, however, is less likely. It is not guaranteed to happen, but is very likely with more than 2gb of ram.

Problem:
"The card's hardware does not recognize addresses above 2 GB (uses a 31 bit (=2GB) DMA mask or something like that), so if Windows happens to create the buffers below that 2 GB barrier than it will work, if not, it will not work."

Symptoms:
Scratchy sound
Clicking/randomness
No sound at all (Except from inputs, such as Mic)

Solutions:
The only known solution is to go down to 2gb.
(If you only have scratchy - but all there - sound, increase the length of your buffers. KX tray -> settings -> setup buffers)


Existing threads:
http://www.hardwareheaven.com/bug-repo...-3-gb-ram.html
http://www.hardwareheaven.com/bug-repo...7-x64-rc1.html
http://www.hardwareheaven.com/bug-repo...tuttering.html
http://www.hardwareheaven.com/bug-repo...kes-noise.html

Mentioned in release threads:
http://www.hardwareheaven.com/general-...ha-3546-a.html
http://www.hardwareheaven.com/general-...ta-3547-a.html
http://www.hardwareheaven.com/general-...64-builds.html

Mentioned in bug threads:
http://www.hardwareheaven.com/bug-repo...gs-issues.html

If anyone knows of any more relevant posts I can link to, post them.

Solutions are what we need, so if you're a programmer, read over Eugene's post and see if you come up with anything.

If you've found a workaround, please post it for verification (Once you're sure this is the problem you were experiencing)


Other than that, please keep "Yes, this happens to me too", and other posts out of the thread so that it will be easy for E to review.



If this could get stickied, it'd be great... Or a Known Issues thread put up.

Russ

Good post, but it is not Windows 7 specific. As Max said in one of the other threads, it is with any OS (but WinXP x86 is more likely to work, due to the way it handles memory).

Temragon

Indeed, and I forgot I that I omitted Vista and XP when I overwrote what I had as a summary with what you wrote for a problem.

I gave it the title I did, though, to catch the rushed newbies who only check for things that seem like it is their exact problem. Most of them seem to be using 7, so I put that in with brackets.
I figured the other people would read it anyway, since they were more likely to try to find a solution first. Especially if it is stickied.

LyyNx

just to let you know, win2k3 x86 and 4gb of ram works perfectly with 3545 (too lazy to install the latest just yet) and my audigy 2 plat, haven't noticed any problems in the last month

Temragon

And I have Vista x64 with 8gb, and it works fine. But 7 doesn't, for me.

Like I said, it's confirmed, but doesn't happen all the time- it seems more or less random where it gets established in memory- See E's post.

Let's keep it to suggestions or abnormal reports (Say, you get it to work reliably over multiple computers by doing something different)

RPGWiZaRD

Of what I've read by several users it seems Windows 7 is affected the most where you usually get no sound at all and on Vista you get clicks or distortions and tweaking buffer size usually helps.

I'd be more than happy if Windows 7 would be able to get to Vista-compability so tweaking buffer size would help already and you'd be able to hear sound.

In near future many people will be using 4 - 8GB ram and prefer Windows 7 which looks to be the next "XP", that's why I think this is such a critical bug... I know it certainly scares me from upgrading to an upcoming Intel i7 (Lynnfield) CPU and 4GB ram if this incompability strikes me as well. Buying a new sound card isn't really a solution as I prefer an Audigy card + kX drivers over X-Fi or the new ASUS cards...

Russ

The only related info that I have seen talks about creating your own DMA-channel object instead of using the one created by NewMasterDmaChannel. The custom IDmaChannel implementation can use IDmaChannel::AllocateBuffer which includes a PhysicalAddressConstraint parameter which can be used to place a constraint on the physical address of the buffer. This sounds like what is needed, but maybe it is more complicated than it sounds (or maybe I am looking in the wrong place)... and I am sure E. must have read the same information, so...

Chester01

which buffer is causing the problem? if it is the X-Tram, that can be set to 0 kb, perhaps that would change things... probably a different buffer though? Is there any word on the creative drivers; do they have the issue also?

EDIT/idea: I am not very familiar with ASIO4ALL, however could we use this program as an intermediary step for machines with >4gb? so for example, asio4all would be the default audio device and that would then be routed (via asio) into the kx drivers...

EDIT2: after looking further into things, ASIO4ALL does not work that way... it appears to do the 'opposite' of what I wanted to do... If we can find an intermediary 'driver' to accept the WMM audio that could output ASIO to the KX card we would be golden

__________________
COMP: Dual Intel PIII 733 Mhz; GeForce 4 Ti 4600; 1.128 Gb RAM; SB0350 (Audigy 2 ZS Platnium)
STEREO(I UPGRADED):Crown Audio K1 and K2 amplifiers (4000 watts at .1% THD ), JL 13w7 Subwoofer (6.5 CF) (2) 18" PR's, Klipsch SB-1's, some cement blocks for speaker stands...

LyyNx

worked fine for me on win7 x64 with 4gb ram

Chester01

I cannot believe I am saying this but I may have to use the creative driver till this gets fixed on one of my computers :/ (just died a little inside)

__________________
COMP: Dual Intel PIII 733 Mhz; GeForce 4 Ti 4600; 1.128 Gb RAM; SB0350 (Audigy 2 ZS Platnium)
STEREO(I UPGRADED):Crown Audio K1 and K2 amplifiers (4000 watts at .1% THD ), JL 13w7 Subwoofer (6.5 CF) (2) 18" PR's, Klipsch SB-1's, some cement blocks for speaker stands...

SithBoxer

Creative is supposedly making/ made new drivers for W7, if those are out you could try and reverse them and see how creative solved the 2GB problem (somebody that has a non-OEM card that will work with official drivers that is). Even daniel_k was having problems with the SB Lives and the 2GB+ issue on his win7 pack but hes certain creative can fix it.

Edit: Creative beta drivers for w7 (Sb Live):

Chester01

I have been using the creative drivers on my laptop (audigy 2 zs notebook) which had been having issues with direct sound (2 gb of ram, but something to do with direct sound 'erroring' out and making loud screeching sounds); that works just fine with the creative drivers, I need direct sound because I am going to be using RoomEQWizard which usually after running a test causes the beep/screechy sound

I also am using the creative drivers on my desktop with 5 gb of ram, they work fine.

Still using kX on my parents computer once the other issues are fixed ill definately be going back to kX on my computers...

__________________
COMP: Dual Intel PIII 733 Mhz; GeForce 4 Ti 4600; 1.128 Gb RAM; SB0350 (Audigy 2 ZS Platnium)
STEREO(I UPGRADED):Crown Audio K1 and K2 amplifiers (4000 watts at .1% THD ), JL 13w7 Subwoofer (6.5 CF) (2) 18" PR's, Klipsch SB-1's, some cement blocks for speaker stands...

SithBoxer

I only wish i could test the creative drivers out. I have an SB0220 though (Oem SB Live Digital) and any time i have tried official creative drivers i get BSODs.

thrillhouse82

Yes, that should be the way to make this work. I also did some research and according to MS's DDK documentation, a driver is allowed to implement its own flavor of IDmaChannel that better suits the device's needs if need be. In other words, you don't _have_ to use IPortWaveCyclic::NewMasterDmaChannel to allocate DMA memory. Instead, you can also provide your own implementation of IDmaChannel and return it to the IPortWaveCyclic object when it calls IMiniportWaveCyclic::NewStream (which would be the place where NewMasterDmaChannel would be called). So to fix this issue, the kx driver would have to implement IDmaChannel and use the mentioned MmAllocateContiguousMemorySpecifyCache in IDmaChannel::AllocateBuffer (and/or in its constructing method) which can be told to only return memory blocks within specific memory boundaries.

Eugene Gavrilov

The driver does not allocate memory by itself. Whenever the driver's audio stream instance is allocated, its CMiniportWaveOut(in)Stream::Init() function is called.
This function needs to return PDMACHANNEL pointer to the PortClass driver.
Microsoft suggest I use Miniport->Port->NewMasterDmaChannel function for allocating PDMACHANNEL. And this function won't allow to specify the boundaries.

Perhaps I can use IDmaChannel interface directly and allocate it. But it is not clear how. Do you think it is a good idea to do the following?

* call NewMasterDmaChannel "as is"
* free the buffer by calling IDmaChannel::FreeBuffer
* re-allocate the buffer by using IDmaChannel::AllocateBuffer, this time specifying constraints accordingly

If I'm not mistaken, there is no convenient method of instantiating IDmaChannel in a different way, except for NewMasterDmaChannel.

Please let me know what do you think.

E.

Russ

Again, I am not a driver developer and do not know much about it, but it seems (from what I have read) that no matter what solution you come up with, it is going to be using some kind of double buffering. If that is the case, how much difference would it be to just treat it as a subordinate device and use NewSlaveDMAChannel and AllocateBuffer instead?

Eugene Gavrilov

Russ,

No, if we managed to use the proper AllocateBuffer function, no copying would be necessary. I will check this next week and will release a new version of the driver for testing (I only have 2Gb of RAM, so, cannot verify this solution).

E.

thrillhouse82

First of all, thanks @Eugene for having a look into this issue! While I'm not familiar with audio driver development, I do have some experience in the mass storage driver corner of Windows. Therefore, my thoughts could be wrong but I'll share them with you anyways :P

While that is correct, an audio driver - as far as I understood the DDK docs about this - is not required to use this function to allocate IDmaChannel. This function is merely provided to give driver developers the opportunity to create a stock implementation of IDmaChannel that will work for most of the hardware out there.

In our case, however, we have stricter DMA memory requirements that are not fulfilled since NewMasterDmaChannel will only return objects that work for hardware that use the full 32 or 64 address lanes. In this case, we are allowed to implement IDmaChannel ourselves by providing a custom object that is returned on IMiniportWaveCyclic::NewStream. This object can use whatever memory function Windows has to create the memory area that fits the silicon's needs.

Further readings can be found at DMA Channel Objects. There is a paragraph that reads: "Port drivers provide miniport drivers with functions that they can use to create DMA channels. Unless otherwise noted in the description of the port driver, it is not absolutely necessary to use DMA objects allocated from the port driver. The port driver simply requires a pointer to an IDmaChannel interface that supports the methods it needs. Check the documentation for each port driver for a list of the DMA channel methods that the port driver requires."

The documentation of NewStream (which is the documentation we have to check) only has a list of methods of IDmaChannel that need to be implemented but doesn't state that it needs an IDmaChannel object returned by NewMasterDmaChannel so we should be fine there.

I also thought about this approach. If the object returned by NewMasterDmaChannel behaves as specified, this should lead to a working driver. However, AllocateBuffer is not in the list of functions needed by IMiniportWaveCyclic::NewStream, so it can happen that it is simply not implemented and returns an error. We have to try this to know if this is the case...

While this is not the cleanest solution on earth, it wouldn't require double-buffering and is easy to implement and test and will make a lot of users happy if it works Imho we should give this approach a try.

I'm afraid you're right. Besides re-implementing IDmaChannel or freeing-then-reallocating, there seems to be no way of creating an IDmaChannel that immediately fits the card's needs.

Russ

I am probably wrong, but it seems to me as though it works something like the following:

NewMasterDMAChannel checks to see if the device supports 64 bit addressing.
If it does support 64 bit addressing then it just creates the buffer to use for DMA.
If it does not support 64 bit addressing and the system has less than 4 GB RAM, then it acts similarly (nothing special needs to be done).
However, if the device does not support 64 bit addressing, and the system has more than 4 GB RAM, then it also creates a common buffer (below 4 GB) and uses double buffering.

If Windows uses double buffering with devices that can do 32 bit PCI addressing (on systems with more than 4 GB RAM), then it seems likely that you would have to do the same with a device that only supports 31 bit PCI addressing... unless you implement your own IDMChannel interface, and thus your own memory handing routines, etc (which as we know, is not so easy without knowing what exactly is supposed to happen in (and the most efficient way to implement) each and every function IDMAChannel needs to support).

From the way I have seen AllocateBuffer used (in example code used with NewSlaveDMAChannel (which is the only place I have seen it used), etc), it seems that it's purpose may be to create a common buffer (for double buffering), in which case, what you want to do with NewMasterDMAChannel may not work the way you are thinking it will, because it is 2 different buffers.

i.e.
By specifying that the device cannot do 64 bit addressing, it seems that (on systems with more than 4 GB RAM) you are going to get an IDMAChannel object that is already using a common buffer (setup for double buffering), and by freeing that buffer, and re-allocating it, all you are going to do is recreate the common buffer (except this time it will be below 2 GB instead of 4 GB). This might work (assuming the IDMAChannel object that you get does implement AllocateBuffer), but I think it will still be using double buffering, and there is some gray area as to what might happen on systems with less then 4 GB RAM (or systems with RAM between 2 GB and 4 GB).

Again, I am probably wrong, so take it with a grain of salt, but I thought I would mention it just in case.

RPGWiZaRD

Eugene, do you got a DDR2 system? If so I'd be willing to donate one of my spare RAM kits (I have 3 CellShock 2x1GB DDR2 kits atm and use only 1 of them), a 2x1GB CellShock PC2-6400 4-4-4-12 kit so you could troubleshoot it yourself as well. That's the least I could do if this means I could possibly continue to enjoy my SB Audigy + kX driver in the future.

Drop me a message if interested.

patches11

I think this is ReactOS's implementation of IDmaChannel (and some other related interfaces):

Doxygen - ReactOS Website

thrillhouse82

I just reviewed the ReactOS implementation and found that it doesn't respect the physical address constraint at all. Hopefully the original MS implementation does a better job there. I then had a look at the MS docs of this method and now I'm unsure if it will really be the solution we're looking for...

The doc at IDmaChannel::AllocateBuffer says:

"PhysicalAddressConstraint
Specifies an optional constraint to place on the physical address of the buffer. If this parameter is non-NULL, only the bits that are set in the constraint address will vary from the beginning to the end of the buffer. For example, to request a buffer that does not cross a 64-kilobyte boundary, specify the physical address constraint 0x000000000000FFFF."

IOW: You can tell this function which bits may change their values from the beggining to the end of the buffer but you cannot zero-force any bits of the returned physical address as required by the emu10k1/2. I sincerely hope that I'm wrong but imho the wording is quite clear

Russ

You are right, it does sound that way, but what useful purpose would that serve? That would seem to only limit the size of the buffer, so then what is the purpose of the BufferSize parameter?

patches11

The purpose that it was thought it could serve was to keep the allocated buffer under the 2GB mark. This information indicates that the function isn't capable of such.

BufferSize is just how big the buffer is, and has nothing to do with where it is located.

I wonder how Creative pulls this off in their own driver... Presumably it has to work around the card's limitation as well. Unfortunately, I know almost nothing about reverse engineering (driver speak is already beyond me for the most part).

thrillhouse82

You are right, it will indeed limit the maximum size of the buffer. For example, there are certain IDE controllers that require the DMA buffers to not cross a 64KB boundary. Therefore, we would request a DMA buffer with the memory constraint set to 0x000000000000FFFF. This requests a buffer whose upper 48 bits do not change from the buffer's beginning to its end and we have a buffer that doesn't cross the 64K boundary. Otherwise, the memory manager could just as well return a buffer that starts at 0x10000F00 and ends at 0x10010EFF, which would as well be 64K but it would also cross the 64K boundary and therefore it would not fulfill all the requirements of the device. Result would be read/write errors or data corruption

This will also mean that the maximum buffer size is limited to 64K. However, it is still necessary to provide the BufferSize parameter to be able to request smaller sizes that are not powers of 2.

Bit OT here but maybe it helps us to understand the method better.

Russ

Thanks for the explanation

Does Creative offer a full featured driver for Vista x64 or Windows 7 x64 for these cards?

MS makes mention of the possibility of using the PcNewDmaChannel function (which I thought I read somewhere can be used to put additional constraints on the buffer, but now I cannot seem to find where I saw that (err, nevermindl)), but also states that it is more complicated to use, is obsolete, and would kill hardware acceleration on 64 bit versions of Windows (except Windows XP and Windows Server 2003).

Aside from the above, they obviously have more resources (i.e. they can probably afford the cost of using MS support channels to find a solution, etc).

LyyNx

i tried creative's driver for my audigy2 platinum a while back (win7 x64, 4gb ram) and it worked flawlessly. i would probably use it if i didn't need the dsp of kx

patches11

These are the most recent Creative-authored drivers that I've found: http://support.creative.com/downloads/?h=7

When I had 4GB of RAM installed, those drivers worked without much issue. No audio glitching or crashing like I had seen with the driver that came with Windows 7's beta. But as LyyNx says, gotta have the DSP!

thrillhouse82

I think in the long run it is necessary to implement IDmaChannel if the free-and-reallocate approach doesn't work. If we do this, we are allowed to use MmAllocateContiguousMemory and MmGetPhysicalAddress. While MS doesn't recommend these functions for DMA operations these are the only one that allow us to specify exact memory boundaries. AllocateCommonBuffer - which is the recommended function for DMA buffers - suffers from the same limitations as NewMasterDmaChannel.

I can provide a sample implementation of IDmaChannel using these functions if that would help. Hell, if I had the driver sources, I would be keen on implementing and testing it right away! As for the Creative drivers: Besides not being full-featured, they don't seem to support the good old SoundBlaster Live! and Live! Value models, so this is not an option for a lot of users.

Eugene Gavrilov

thrillhouse82,

yes, please write a sample implementation and the functions necessary to instantiate the object - this would be very useful. you can test these functions by using any sample WDK driver, e.g. a 'toaster' driver

all,
please have a look at the debug logs of 3549-b build, they should dump the physical address of the buffer allocated

E.