No sound or continuous beep w or w/o original sound on top on EMU APS

Eugene Gavrilov

>> a former bug

no, this is a known bug with spy.exe
it doesn't clean the window sometimes

>> Nothing strange with the other registers except

yep, the mapping isn't set correctly, thus, producing a 'looped beep'
btw, what about 0xa?

---
in 3534a I added double-init of 0xc/0xd registers (just to be sure), but they are updated by the hardware, not the driver --
that is, as soon as voice playback is started, the 10k1 chip is responsible for initializing them correctly...

there might be a problem with voice startup function (if it is a driver issue...)

but I still consider it to be a PCI-related bug

/Eugene

XDread

About the 0xa register, the value are the same all the time whether there is sound playing or there is beep. The value(s) is(/are) 0xed100c28.

I have looked at the other registers that you linked to, but I am not sure what all of them does. It seems like the important registers are those you have already pointed out.

I assume that the define list is arranged in this way:
define for register 0x0 // description
define for mask 1 // description
define for mask 2 // description
(...)

define for register 0x1 // description
define for mask 1 // description

etc...

"/* DO NOT PROGRAM THIS REGISTER!!! MAY DESTROY CHIP */"
Uh oh! Debug registers that can destroy your soundcard?? Haha!

Eugene Gavrilov

are 6,7 ok?

anyway, here's the list:

(all values assume you playback 48000/stereo/16bit)

0: 4000xxxx
1: 4000ff00 or 400000ff (left & right)
2,3: ffffffff or ffff0000 (make sure wave volume / wave pcm slider are set to maximum)
4,5: ignore -- but report if the values are too different (during 'normal' and 'beeping' playback)
6,7,8: buffer addresses [logical] -- should be identical (normal=beeping) if you have the same amount of directX clients currently running
9: ignore
10: I'm unsure. just notice any changes
11: should be equal
12, 13: the mapping registers -- the faulty ones
14,15 ignore

16 - 31: should be identical for beeping and normal sounds

use any kx version you like

/Eugene

XDread

6,7 seems ok. They stay the same regardless. See below.

I made a 48k/stereo/16 bit file to test so that values are close to what you expect.

These values are exactly as described during music and beep.

Actually there is a difference. The values are changing so fast, it's hard to see, but when I get a loud beep the 0xffxxxxxx is more constant than when music is playing at full volume or when I get a lower sounding beep. Also I get a feeling that the values are looping when there is beep. Again, it's hard to say, and I have thought that this is of low significance, but now I am almost sure that the values here are looping.

Update:
I have looked at this thing a little more, and I am sure that this is not something that I am imagining. Is there a way or can you make a tool that samples these values and save them to a file so that I can take a look at each of the values more closely?

6 = 0x00000400 for both channels
7 = 0x00000c28 for both channels
8 = 0x00000xxx for both channels, x being a continous changing number that is hard (impossible) to see.

These values are regardless og beep or sound.


10 and 11 is equal both between registers and channels regardless of sound or beep.
The value is 0xed100c28.

when playing, registers are 0x00036002 and 0x03561fff for register 12.
when beeping, registers are 0x03561fff for both voices for register 12.

when playing, registers are 0x00034001 and 0x03561fff for register 13.
when beeping, registers are 0x03561fff for both voices for register 13.

Register 16 does change from sound to sound regardless of beep or normal sound. 0x0000xxxx, x being the part that is changing.
So does bit 16 from register 17.

Other than that all the last values stay the same.

For reg 16, the values that are showing may be the same for a beep as for a normal playing sound.

Anyway: reg 16+ does not seem to have anything to do with the beep.

Rox271

May be. But the original Creative driver doesn't beep on my PC.
So either it is not a hardware issue, either there is a nasty trick in the original drivers that kind a fix the issue on the fly?

What about implementing a full reset feature? Most of the time when I start the PC, everything is ok and problems would only occur after a while. So if there was a possibility to come back to the initial clean state that would be nice. (ok, poor fix but still a fix ).

Eugene Gavrilov

a small test:
run the spy
produce any sound
write down the 12,13 values
re-produce the beeping bug
now, in the console, execute: 'kxctrl -sptr 0xc <voice_number_in_hex> <value> '
for instance, "kxctrl -sptr 0xc 0 0x00036002"

- you need to do this for -one- voice only

does this solve the problem?..

/Eugene

Eugene Gavrilov

[XDread]

btw, almost forgot, do NOT tweak the buffer settings. it seems you like to change them to non-default values - this should not be necessary because these settings don't affect any latencies...

/Eugene

XDread

Ah.. haha! You are right! But then I do not use to change the buffer settings either... It's just me saying the wrong thing for changing the latency in the control panel for the ASIO. Thanks for pointing out!

XDread

Hi!

This method did update the registers, but no difference in beeping sound.

New discovery:
Register 9 (0x09):
Cache Control Register, mask CCR_LOOPINVALSIZE (0x0000fe00):

Register 9 masks:

<pre>
fe000000: 1111.1110.0000.0000.0000.0000.0000.0000 CCR_CACHEINVALIDSIZE_MASK
01000000: 0000.0001.0000.0000.0000.0000.0000.0000 CCR_CACHELOOPFLAG
00800000: 0000.0000.1000.0000.0000.0000.0000.0000 CCR_INTERLEAVEDSAMPLES
00400000: 0000.0000.0100.0000.0000.0000.0000.0000 CCR_WORDSIZEDSAMPLES
003f0000: 0000.0000.0011.1111.0000.0000.0000.0000 CCR_READADDRESS_MASK
0000fe00: 0000.0000.0000.0000.1111.1110.0000.0000 CCR_LOOPINVALSIZE
00000100: 0000.0000.0000.0000.0000.0001.0000.0000 CCR_LOOPFLAG
000000ff: 0000.0000.0000.0000.0000.0000.1111.1111 CCR_CACHELOOPADDRHI
</pre>

Normal play voice 2 (regitser 9):
<pre>
04c61000: 0000.0100.1100.0110.0001.0000.0000.0000
</pre>

Info from this:
Cacheinvalidsize_mask = 0x02
Interleaved and wordsized samples = True
Readaddress_mask = 0x06
Loopinvalidsize = 0x08

Other values for this voice are: 0cf21000, 08e81000, 04d61000, 0cc21000, 06ef1000, 0edb1000, 0ecb1000, ...

Suggesting the value for Cacheinvalidsize_mask and readaddress_mask are changing the others not.

Beep for voice 2:

<pre>
8be90000: 1000.1011.1110.1001.0000.0000.0000.0000
7de25000: 0111.1101.1110.0010.0101.0000.0000.0000
39c08000: 0011.1001.1100.0000.1000.0000.0000.0000
</pre>

Differences between normal play and beeping:
Cache loop flag is set. Loopinvalidsize value does change.


I have to do some more testing, but suggestions is appreciated!

Eugene Gavrilov

hmm interesting
and if you clear the bit by using kxctrl?..

(the cache loop should be disabled by default!)

/E

XDread

Since some of the values are constantly changing, it's hard to know what would be smart to set for the changing parts. Therefore I try to set the register to 0x00000000.

When doing so, the beep does change slightly in character, not much, just a little bit, but it does not remove the beep.

I also tried to set the register to 0xffffffff, but the value is rewritten by the driver or by some other process. I can see for a brief moment that the value is set to 0xffffffff, but immediately after it is reset to what it is "supposed" to read. "Supposed" since Cache Loop is set when beeping.

When trying this while music is playing, it is hardly noticeable. Sometimes I get a sort of whisteling noise on top of the music.

There is one difference though (and a strange thing):
First the difference:

Voice 0, normal music (everything here is register 9):
The values that does continuously change are "CCR_CACHEINVALIDSIZE_MASK" and "CCR_READADDRESS_MASK"

When beeping for that voice:
The values that does continuously change are the same, but this thime also with "CCR_LOOPINVALSIZE"

Then the strange thing:
For voice 1, normal music:
a random value: 0xc9e44e00
Here "CCR_LOOPINVALSIZE" is continually changing and "CCR_CACHELOOPFLAG" is set.

One last thing:
While beeping and trying to write to register 9 for voice 0, nothing seems to happen, but when beeping and doing so, the value of "CCR_LOOPINVALSIZE" does change.

XDread

Another last thing:
I haven't managed to reproduce the beep from music playing or to get rid of the beep by writing to the register.

Eugene Gavrilov

so, even re-writing all the registers doesn't help...
btw, have you tried to modify them all simultaneously?.. (that is, both 12,13 and the CCR during the same playback)

you may find the '--gui' option of the kxctrl tool useful -- it will work in 'console' mode
[note that the commands won't require the '-' symbol -- just 'sptr', 'gptr', ...]

if after the tests you get (practically) the same values for beeping & normal playback -- and you still hear the beeping -- ... hmmm... we are again in the very beginning then

/Eugene

XDread

Wich resulted in instant blue screen of death, at least on build 3514. (Probably fixed in later versions.)

I've tested writing to all the registers at once. (The ones you mentioned + some more in different tests.)

I have one question regarding kxctrl:

When you write to the registers using the -sptr switch, where does kxctrl really write?
The reason why I ask this is that if it just writes to the registers, then I would be tempted to believe that the driver itself would remove what I just set the register to since the driver won't know what I just wrote. (If you understand what I mean.)

Some registers might be updated in certain situations, other registers perhaps "all the time"? Just asking...

Eugene Gavrilov

'--gui' option is not supported for 3514
(well, but it should not give BSODs either)

kxctrl writes a hardware register regardless of the driver internal state

most registers used for wave playback are set-up by the driver only once (at the beginning of the playback)
the hardware, however, updates some of them
so, it is the hardware, not the driver, updating the registers

>> I've tested writing to all the registers at once

no luck? still beeping even with all the registers set-up correctly?..

/Eugene

XDread

No difference at all... beep=beep when setting the registers, music=music when doing the same.

(Can hear a slight alteration in the beep or music when actually doing the register setting, but just after that the sound is still the same.)

Eugene Gavrilov

hmm

bad news

probably, the issue is not register-related

what is strange is that the same hardware works fine under win98se and winxp/2k without ACPI (as far as I've figured out according to the postings)

how about turning ACPI off?..

/Eugene

hung_lo

Hi!

First of all, I'm new here and would like to thank the KX-crew for a great job!
Super!!!

I have the same beeping on my Win2K system as described in this thread even though I disabled ACPI at installation time.

Thanks.

XDread

It has never been turn on, but I notice that W2k reports my graphics adapter, network interface adapter and EMU APS card all to be using IRQ 9. I'll try to see what happens if I change so that the audio card is on its own IRQ.

Eugene Gavrilov

>> I'll try to see what happens if I change so that the audio card is on its own IRQ

you will need to disable ACPI for that
(and re-install Windows or re-configure all the installed hardware)

/E

TWidXugA

I've got the same bugs that's been described.

Sometimes I only get no sound, sometimes a earbreaking noise!

I get around it by playing and stoping winamp

I've kx 3533b (3534a has an huge asio problem with cubase sx or nuendo 2.0)
and an audigy 1 platinum
my mobo is an Asus a7a266 with an ALI MAGICK 1 chipset.
i've got acpi turned off since the windows installation.
also have 512 mb ram
msi g4 ti4200
hauppage wintv tv tuner
My onboard audio is off and I have directx 9.
its the only bug i have with kx and i don't give it much notice, because its not that frequent, anyway its a nag!!

Thanks in advance for your answers and in particular to Eugene for this wonderful project!

Rox271

Depends on your BIOS. On my Dell Dimension 8100, I can reassign IRQs in the BIOS and then Win XP takes the change into account. But the IRQ choice is limited by the PCI slot and you have no choice but share some of them.

I did that already. Now the SBLive has its own IRQ 10. No improvement.

I don't think this bug is related to hardware. As I already mentioned before, I can imagine that the original creative drivers would beep if it was a hardware issue wouldn't them? Or may be the kx driver is very sensitive to timing and requires a specific very optimized hardware setup?

Also, I was thinking about something else. So far we've been focusing on the EMU 101k chip when we have also the AC97 codec fitted on the card. As far as I understand the AC97 is mainly taking care of analog aspects but can we ignore it? Since I'm using the SPDIF output only, is it possible to have the kx driver running without the AC97?

Well, don't know if my comment is stupid or not, juts looking for clues...

XDread

I couldn't agree more, but it seems a hard problem to solve if the cause can not be found.

Regarding timings, that is something I have been thinking about lately too, but who knows? Perhaps there are some signals or something that needs just another cycle more to settle or a task just needs a little more time to finish its task before a register is rewritten or something.

Who knows? Not me!

Eugene Gavrilov

this seems to be a good idea
unfortunately, there are a lot of places in the driver code where series of registers are programmed one-by-one -- it might take months to understand which sequence is causing problems

moreover, I still cannot be sure this is purely 'kX' problem -- perhaps, Creative drivers simply have a built-in workaround

and, finally, the bug cannot be reproduced under Win98SE -- and that sounds strange...

/Eugene

Rox271

I agree but this situation is quite common during the development cycle.
When I face such a situation I'm used to comment large pieces of code and just play with the program in order to figure out what part is actually causing the problem.
Eugene, the main remaining question is : could you eventually experience this beep issue?

So, let´s do the same ;-)

That´s right. But on the other hand, I never used Win98SE on my PC. I started with Millenium with quite an old version of kx drivers. So I cannot gurarantee that kx drivers would run on my PC using Win98SE.

I'm quite concerned with this issue cos sooner or later it may cause the death of this nice kx project.
We also have very little idea about how often this issue happens. It could be a good idea to start a poll to all kx users to figure out how critical this issue actually is and if it is related to hardware or operating system.

Just ideas...

Eugene Gavrilov

>> When I face such a situation I'm used to comment large pieces of code and just play with the program in order to figure
>> out what part is actually causing the problem

imagine you have the following code:
voice_start()
{
write reg 1,2,3,4,5,6,7,8,9,... 24
};

every register is more or less important
what will you try? swap 1& 5? or 2&10? or remove #24?..

>> could you eventually experience this beep issue

no, never
even after I've upgraded to nForce2-based motherboard ...

>> Win98SE

and what about Millenium? if the bug can be reproduced under Millenium, but not under Win98SE, the problem is definitely related to ACPI or Windows memory management...
one more thing might: it might be related to the PCI latency setting
kX driver doesn't set it at all; Creative driver seems to tweak PCI settings a little

>> it may cause the death of this nice kx project

I doubt perhaps we need to start a poll anyway

/Eugene

XDread

Hmmm... Wonder if there are any latency settings on my mainboard... Let me see...


...no...

Rox271

The PCI latency question deserves some exploration.

XDread, you may be interested in an interesting article here

The guy who wrote it is very enthousiastic.
On my side, I noticed that the video card is very demanding. I reduced the video card PCI latency and increased the SBLive one. On my PC it keeps beeping ( and I can't tell if it is a better beep )


Eugene, there's a bug in your code. Never use ';' after } when it is the end of a function. Now I know why U don't want to publish kx sources

Eugene Gavrilov

>> Eugene, there's a bug in your code. Never use ';' after } when it is the end of a function. Now I know why U don't want to publish kx
>> source


oops! I'll review my sources -- if I find '};' sequences and fix them, probably, this will solve the beeping issue!..



/E

Rox271

Hehe
That's a good start I guess...