Eugene Gavrilov

[this is a new thread created instead of http://www.hardwareheaven.com/showthre...threadid=12095]

========
quick bug description:
when you click 'play' in your audio application you hear a constant noise / beep instead of music
the system keeps functioning correctly
the bug is (usually) solved after 30-40 play/pause clicks
========
the bug seems to be rather rare, so, make sure the problem you might be experiencing is really =this= bug
do NOT post any unrelated questions in this thread
========

so, guys, I suggest we start a new topic called something like 'constant beeping instead of audio playback' and try to re-test all the information we currently have concerning this issue

that is, whether the bug depends on the amount of RAM, on any particular hardware configuration, whether it can be solved by changing the PCI latency, whether it is OS-dependent and so on

so, everybody should try to perform the following tests and post the following info:

1. your OS/chipset/CPU/memory/BIOS version
2. whether you have a Win98/WinMe installation -- if yes, have you tried to reproduce the bug?
[ it is preferred to power-down the PC before switching between WinXP(2k) and Win98/Me ]
3. whether you have a PCI latency-related settings in the BIOS (and the current values)
-- the setting can be called 'PCI clock autodetection' and so on...
4. whether you can reduce the amount of RAM to 128 or 256Mb (and, if yes, does it solve the issue?)
5. whether the bug is solved by clicking n-times play/pause
(well, it is more important to check, if the bug is solved when the whole 64-voices cycle is over -- via the Analyzer)
6. whether the bug affects ASIO/WinMM/DirectX/Synth playback
(btw, check if synth playback solves the beeping issue and if the midi notes are simultaneously affected by the bug when wave playback is invalid)
7. (perform any tests you might find useful -- even crazy ideas!)
8. if you have Linux, try opensource.creative.com drivers (they were reported to be affected by the same bug, too)
9. try enabling/disabling different PCI devices and their modes
such as unused USB controllers
or changing (temporarely) the DMA mode for the harddrives
10. is the beeping sound affected by 'pan' and 'volume' sliders of your audio player? of the kxmixer?
11. if clicking play/pause doesn't solve the issue, what's the situation in the analyzer window?
[note that there's an extended indication of the present voice state on the top of each bar -- 'white' is 'free voice', 'dark blue' is 'midi voice' and so on...]

required software:
1. monitor (btw, pls check if monitor somehow affects the issue!) -- http://kxdev.narod.ru
2. sisoft sandra (latest release)
3. all tests are to be performed using 3534 or 3535 releases! // do NOT test previous versions
if there's any newer version available, use it instead unless there's a special notice in this thread

NOTE: please repeat the tests even if their results were already discussed in the prev. thread
(it is important)

/Eugene

p.s.
ufff

I'll think about 'global reset' button meanwhile

mikeyj

Hi Eugene,

Sorry you're going through all this. As a programmer, I understand how frustrating bug squashing can be!

So, has anyone mentioned that the pitch of the beeps is directly related to the sample rate of the files that are playing during the beep? I can play 11, 22, and 44k wav files back to back and get 3 different octaves played back (which would make sense given the sample rates). Don't know if that info means anything in this situation.

Also, I've been using version 3534 since they came out, running on an PIII 800, WinXp SP1, 384mb, GeForceDDR, SB Audigy. Didn't have any problems....until I just got some new hardware and did a clean install. Still running WinXP SP1, SB Audigy. Motherboard is now Shuttle MN31N with NForce2 chipset w/AthlonXP 2100+. Integrated GeForce 4 MX, Integrated NIC, 1Gb RAM. Now I get the beeping regularly. The same 16 note beep pattern before solving itself until the next time, which doesn't seem to have a pattern. I've counted 5-30+ non-beep playbacks before causing it again. The beeping also causes any game I might be playing to crash and most of the time completely reboots my machine. Speaking of the 16 note pattern, there is also a relation of beep pattern length to file sample rate as follows:

44k file = pattern of 16
22k file = pattern of 32

Here's where the math actually breaks:
11k file = pattern of 32

I'd have expected another multiple of 16.


Here's some more funky weirdness. If I get the beep pattern started by playing one wav and then play the kx speaker test, then go back to the original wav that started the beeping, this is the pattern I get. For example, if I playback a wav until I get a beep and then I play that wav 2 more times for a total of 3 times, then play the speaker test, then go back and play the original wav again (it will still be beeping), I will get 10 more beeps out of the original wav. This is reproducable 100% of the time for me.

15 original = 14 more after 1 speaker test playback
14 = 15
13 = 16
12 = 1
11 = 2
10 = 3
09 = 4
08 = 5
07 = 6
06 = 7
05 = 8
04 = 9
03 = 10
02 = 11
01 = 12

Here's another angle on the pattern. If I play the test more than once in between the playbacks of the original wav, this is what I get:

03 original = 10 more after 1 test playback
03 original = 07 more after 2 test playbacks
03 original = 04 more after 3 test playbacks
03 original = 01 more after 4 test playbacks
etc...

With the speaker test playing back 6 wavs, I'd think that if I played 8 original beeps and then 1 speaker test (6), that I'd get 2 more from the original wav for a total of 16, but it doesn't happen that way. Maybe it's because my original is a 44k file and the speaker test is 22k or something? It's definitely lower and slower than the Windows version of the Chimes.wav. I'm sure there's some freaky math in there but being that I suck at math AND it's 4:30am, I'll leave that up to you!

(PS...after another couple of experiments, I think it IS related to the two files having different sample rates that affects the beep pattern. Funny how it's smart about what sample rate is playing at what point in the pattern.)

One more thing to mention is that during the beep pattern, the speaker test hardly ever makes a sound while it's playing but when it does, it's VERY quiet AND it's pitch is a 4th below the original which is playing back at 44k. So it's not playing back at 22k. It's somewhere in the middle. More math.... ;-(

Well, these were fun experiments but for some reason, I'm doubting they'll have alot to do with the problem! ;-)

Thx,
Mike

vikflash

------- (added by Eugene) -------
[b]new forum users: note that the following information is not necessarily correct or applicable at the present. please read the FIRST posting in this thread[b]
also, as I've already mentioned above, I suggest all the users re-run the tests as mentioned in the first posting
the following info is provided only for people who wish to save their time reading previous topics
------- (added by Eugene) -------

This summerize what Eugene said interesting about this bug in the past
I'm not sure it's a good idea
Hope it will help some people and don't bother the others.

Vik

Apr 26, 2003 12:07 AM
so, to summarize the present observations:

the bug happens randomly after some voice re-allocation occurs

it is manifested as 'continuous beeps' instead of 'sound'
the incorrect behaviour keeps on until the -same- voices are re-allocated (according to the analyzer window); that is, one need to start/stop x16x or x32 times (depending on the number of reallocated voices per start/stop action)

if no voice re-allocation occurs (non-directsound applications) the problem is very rare or even doesn't happen

/Eugene

04-29-2003 01:36 AM
concerning the issue:

pls download and execute the "spy.exe" program from here (<http://kx.maincore.nl/spy.exe>)

dbgview.exe (debugview) works too

it should display you all the hardware registers and their values when an audio channel is active

start audio playback
now simply make a 'snapshot' (print screen)

reproduce the bug
make a snapshot

restart the playback 8 times (you should be still experiencing 'beeping')
make a snapshot

restart the playback until the issue is 'solved'
make a snapshot
/Eugene

p.s.
set your console window size to 100x35!

04-30-2003 12:15 AM
giveio is a special driver that enables direct I/O access. the 'spy.exe' is our own tool, while giveio is bundled with certain software (such as MBM5)

the problem happens because audio data isn't correctly mapped into the audio card address space
it is unclear what is the reason: either Windows incorrectly allocates the buffers, or the hardware registers get re-written incorrectly...

I'll prepare a special version of kx.sys that might facilitate the debugging...
/Eugene

05-06-2003 06:33 AM
>> I used to be on Win98SE with kxdrivers and never had any such issue

a very intersting fact
so, the problem is definitely in Windows XP memory management, because it is Windows that is responsible for the correct memory mapping...

anyway, a debug version of kx.sys to be included in 3533 development release


/Eugene

05-11-2003 09:28 PM
resetting the DSP should not affect the problem
well, according to the logs, the buffers are mapped absolutely identically for bad/good playback
I'll download winamp3 to test this issue

anyway, the problem might be related to your hardware [PCI bus]
there were linux people experiencing similar problems [running linux drivers, of course]

----- for all people experiencing the bug: -------

what is your chipset? nVidia/Via?
[pls give a full description. CPU/Memory (FSB)/Mainboard]


/Eugene

06-04-2003 01:06 AM
[3533 installation issues]:

pls test 3533 release with monitor running
--
start the monitor
start the setup application
proceed until you are asked to reboot
say 'no'
run 'msconfig' --> startup/autorun tab
uncheck 'kxmixer --startup'
reboot
run monitor
run 'kxmixer --startup' from the command line

paste both logs (if the problem is still there, of course)

/E


Jun 25, 2003 01:41 AM
>> 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

Jul 8, 2003 01:20 AM
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

Jul 10, 2003 01:49 AM
hmmbad 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

Jul 11, 2003 04:47 AM
>> 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

Jul 18, 2003 02:22 AM
>>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.

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...




>> 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

/Eugene

Jul 23, 2003 10:35 PM
unfortunately, at the moment there are no clues / ideas concerning the 'beeping issue', except, probably, ACPI/PCI stuff and Win98SE/WinXP difference...

/Eugene

Jul 26, 2003 01:05 AM
the issue we are solving can be related to practically anything...
it seems to be a minor -hardware- issue that is 'triggered' by not-100%-correct driver code

the possible hardware reason might be: unstable PCI power (power supply unit?), unstable connection in the PCI slot of the motherboard, invalid memory timings, special 'chipset optimizations' (such as 'high performance' setting), USB keyboard / mouse, TV Tuner or Video Card, resource sharing ... etc, etc, etc,

the possible OS/software reasons: incorrect CPU/PCI initialization, incorrect memory management, shadow memory enabled (BIOS), background applications / services, ....

I haven't experienced any similar bugs since 3501, so, this issue 100% isn't "software-only"

I think it is critical to prove if the issue doesn't exist under Win98SE
(however, even if it doesn't, this doesn't prove the issue is 100% software-related...)

once again, what is your software/hardware configuration? [please be as detailed as possible]

/Eugene

Jul 27, 2003 03:31 AM
btw, has anybody tried resetting BIOS settings? (such as DDR memory settings?)

/E

Jul 28, 2003 12:24 AM
>> Latency Timer : 152 clk

was it your manual setting?

how about installing Win98SE? [just for testing]

any special settings in your BIOS? [advanced chipset configuration?]
does resetting BIOS settings to 'Setup defaults' solve the problem?

try to change the latency timer to '32 clk'?..


/Eugene

Jul 29, 2003 12:26 AM
you know, a very strange (and fun) thing

after playing with Sandra and system information utilities (such as bios / chipset detectors) I've ... reproduced the bug you're experiencing!
(that is, I heard the 'looped' beep during 32 pause/resume cycles of WinAmp)

moreover, after re-running Sandra's 'PCI info' for some time, I managed to get the beeping sound once again
[btw, I used Audigy2Ex]

however, after reboot the bug became completely unreproducible...

before running Sandra I tried several motherboard utilities (that were bundled with it) -- such as LiveUpdate etc.. (they usually try to access PCI bus, SMB bus etc.. in order to get the BIOS revision/date/version and other stuff)

so, the problem seems to be [really] PCI-related and is triggered by [simultaneous?] PCI (re)configuration...

could you please test if running Sandra influences the bug: open 'System Summary', 'Mainboard information', 'PCI&AGP Cardbus info'
also let me know if you have any utilities running (such as hardware monitors / temperature sensors...

/Eugene

Jul 30, 2003 01:00 AM
the kX driver cannot directly set-up PCI latency under Windows OS
(but it is possible under Linux)

there's the following code in Linux driver:
pci_read_config_byte(pci, PCI_LATENCY_TIMER, &cmdb);
if (cmdb < 32)
cmdb = 32;
pci_write_config_byte(pci, PCI_LATENCY_TIMER, cmdb);

although WDM driver model doesn't permit pci bus configuration, Creative driver seems to have some functions to access the PCI bus directly (they use a separate .sys file for that)
so, probably (?) they configure some PCI parameters (perhaps, including the ones related to Via686B bridge, too)

the latency of 32clk is a 'standard' for Live/Audigy (provided Windows has configured the card correctly)
(note, however, that Linux driver uses '<', not '>' )

as far as I remember, PCI latency is the amount of time the card can 'hold' the bus
if it is too high, the card can 'capture' all the PCI activity for a long period of time
otherwise, the card's operation might be suspended

an idea: if the higher latency causes problems and, for instance, additional debugging info decreases the chance for the bug to appear, we could add a significant delay between register programming procedure on voice start-up...
(or, visa versa, we could try to minimize the time the driver spends in voice initialization)

-=-=- this was theoretical part of my message -=-=-

we should get more information on PCI latency / Sandra-related experiments before we can proceed

/Eugene

Aug 2, 2003 11:26 PM
so, Creative definitely re-configures the PCI latencies according to its 'undocumented' technical specifications
have you tried to tweak the PCI latency to a '64' value? did it solve the problem with kX?

btw, as far as I remember, there was a Linux guy interested in solving the same issue for Linux driver -- it is much easier to test if the issue can be fixed by modifying the Linux driver...

anyway, it is currently impossible to fix this PCI issue because kX Driver cannot tweak the PCI bus directly -- so, one needs a 3-rd party tools for that...

/Eugene

Aug 8, 2003 11:14 PM
unfortunately, we cannot be sure that Creative drivers don't experience the same issue simply because they use a different voice allocation scheme

well, I can change the allocation strategy for the kX driver (it will allocate the same voice pair each time -- the way it was in 351x releases)

I currently have no idea how to solve this issue
moreover, I haven't experienced it anymore...

/Eugene

Sep 17, 2003 01:09 AM
so, guys, I suggest we start a new topic called something like 'constant beeping instead of audio playback' and try to re-test all the information we currently have concerning this issue

here: <http://www.hardwareheaven.com/showthre...threadid=26491>

/E

------- (added by Eugene) -------
that's it
------- (added by Eugene) -------

XDread

Reply to mikeyj:

"So, has anyone mentioned that the pitch of the beeps is directly related to the sample rate of the files that are playing during the beep? I can play 11, 22, and 44k wav files back to back and get 3 different octaves played back (which would make sense given the sample rates). Don't know if that info means anything in this situation."

Hi! You are right that this may not have been mentioned, but this is expected. If the buffers are of the same size, but with half playbackrate, the sound will play one octave lower.

"The same 16 note beep pattern before solving itself until the next time, which doesn't seem to have a pattern."

Regarding the pattern thing I would like to say one thing:
Sometimes the bug follows a pattern, usually not. (That is my experience.)
Other people have reported a pattern (and it does happen), but I think it just that changes happens on a multiple of that pattern, and where the bug starts or ends may shift for some strange reason. (In other words the pattern thing is not absolute.)

"The beeping also causes any game I might be playing to crash and most of the time completely reboots my machine."

Whoops? This is NOT a symptom of this bug! While beeping EVERYTHING else should be working normal. I wan't to ask Eugene a question:
[COLOR=skyblue]Is it possible that if this is a latency bug, hardware components _could_ fail in such a way that the operating system can't recover?[/COLOR]

By the way how often does your computer crash when you are playing your game, and which games do you experience crashes upon?

"Speaking of the 16 note pattern, there is also a relation of beep pattern length to file sample rate as follows:
44k file = pattern of 16
22k file = pattern of 32
Here's where the math actually breaks:
11k file = pattern of 32"

This is probably just a coincidence. And depending on whether you are using direct music or not, the pattern may be 32/64 rather than 16/32.

(I'm not one of the developers of this project. I am just one poor guy who was the starter of the former thread that this one replaces. I have struggeled with this problem for more than a year now.)

(Oops.. Sorry Eugene, forgot...)

Eugene Gavrilov

btw, certain questions mentioned in the first posting, aren't answered still

/e/

Rox271

I just found something new regarding the beep that may be a clue.
The beep used to have a constant pitch until youy actually stop/start another sound.

I donwloaded a rollercoaster demo here :
http://www.nolimitscoaster.com/

There is an ambient sound of wind and wheels on rails playing during the simulation. Its picth varies according to the speed. I had the beep during the simulation and I noticed that the beep picth was still varying according to the speed!! This is very unsual so I decided to report this just in case...

By the way, I also noticed that some people were using the kx driver v3535. Where is it?

Also I read in the Issues section SB020x cards (Dell OEM SB Live!) contain different EMU10k1 chips and they aren't supported at the moment. My Sb Live actually came with a Dell computer. Could this explain why I get the beep??? How can I sort this out?

Eugene Gavrilov

>> SB020x cards (Dell OEM SB Live!)

if you had this card, you wouldn't have managed to install kX drivers
(since PCI id is different and the card is -absolutely- unsupported)

>> Its picth varies according to the speed

that's expected since the audio data is taken from the internal card's buffer or an invalid memory page
but all the audio controls are still available, including pitch, volume, pan etc...
(btw, try that by using any direct sound application such as winamp -- does tweaking pan/vol produce any results?)

====

btw, guys, as I've already mentioned in the first post [in this thread] -- some of the ideas/tests need to be re-verified
even if it was tested before...

/E

Nappylady

Yes, when you are beeping, pan / volume DO work on the beep!

If you are watching the "oscilloscope" in the mixer, and you adjust the pan / volume, you can see your adjustment in real-time!

Also, if you run the DSP applet, and use the "Peak" plugin to look for the beep, you can see it immediately out of the FXbus. So, the bug happens someplace before that.

I guess Creative wasn't willing/able to help; what about Microsoft? I'm sure they know a lot about PCI issues and such....

Eugene Gavrilov

>> guess Creative wasn't willing/able to help; what about Microsoft?
>> I'm sure they know a lot about PCI issues and such

I doubt
this is a hardware-specific issue
who knows, maybe it is nVidia bug (Via 686b chipset was buggy, too -- but the problem reveals itself only when using sblive/audigy cards)

so, guys
once again: there's a list of tests to perform. any volunteers?

/E

Nappylady

Which tests do you need me to run? Just give me a list of them and I'll perform them.

Just to warn you--I haven't experienced the beep in about 2 weeks--I haven't reset my computer in that time. I find that if I find a good, stable session that doesn't beep, and I just use suspend-to-ram and hibernate, it will stay non-beeping.

Another clue, perhaps? Something in the BIOS initialization or something, puts the latencies wrong? I don't know anything about it, but anyway, there's some more information.

Tomorrow is my free day (starting about 24 hours from this posting) so please hurry to get me a list of things to do.

Thanks for all your help, Eugene.

Eugene Gavrilov

>> Which tests do you need me to run

the FIRST posting in this thread

/E/

Rox271

Hard to test this issue which is completely random.
I restored an XP previous setting and haven't experienced the beep for a few days.
I tend to agree with Eugene: this could have something to see with the video.
I have a Creative Blaster 5 FX5600. I installed the NVidia detonator drivers and experienced the beep. Now I went back on original Creative drivers and all seems to be much more stable.
Below are answers to your questions Eugene, though I'm not under the impression there is anything new.

Processor
Model : Intel(R) Pentium(R) 4 CPU 1300MHz
Speed : 1.30GHz
Performance Rating : PR1426 (estimated)
Type : Standard
L2 On-board Cache : 256kB ECC Synchronous ATC

Mainboard
Bus(es) : AGP PCI USB i2c/SMBus
MP Support : No
MP APIC : No
System BIOS : Dell Computer Corporation XP2
Mainboard : Dell Computer Corporation Dimension 8100
Total Memory : 383MB RDRAM

Chipset 1
Model : Dell Computer Corp 82850 Host-Hub Interface Bridge Device (A2-step)
Front Side Bus Speed : 4x 100MHz (400MHz data rate)
Total Memory : 384MB RDRAM
Memory Bus Speed : 2x 400MHz (800MHz data rate)

I don't use Win9x.
But sbdy reported the bug using Win98SE in the previous thread.

Not available in the BIOS but tweaked using PowerStrip.
Currently using 32 for all PCI cards.

I can go down to 128 but haven't tested. XP is quite clogged without RAM.

Most of the time this would fix the bug but in some rare occasion there is no other choice but reboot the PC.

Yes the bug affects everything.

Yes the beep responds to pan and volume.

Everything looks good in the analyzer. I can see red/green strips just as usual.

Nappylady

Addendum: I think I'm the only one who's tried reducing RAM to date, but... going from 512 (2 DIMMs, dual-channel DDR) to 256 (single DIMM) made no effect.

Someone mentioned video. I am using an AGP card in spite of the onboard video. I will try the onboard video and see if that's the problem.

nicklad

I have noticed that once you get the continuous beep, you will not get sound back until the same streams that caused the original beep are reused.

1. Bring up the visual representation of streams being used.
2. Keep pressing play and stop in an audio application like WMP until you get the dreaded bleep - note that the streams remain open even after you have ceased playback.
3. Keep pressing play and stop - notice that you keep getting the bleep - on the off chance that the news streams overlap the ones used previously, sound will be reporoduced normally.

This explains the pattern that some people claim to have observed.

Nappylady

Yep, Eugene mentioned that the beep continues until the same voices are re-initialized.

Hey, here's a thought: I don't think anyone's played with mono stuff. It probably just makes the cycles be twice as long, but AFAICT, no one has found for sure that the beeping even exists with mono material.

Okay, off I go to try it, right now!

Nappylady

I am running an NForce2 motherboard with the on-board video. Until this afternoon, I was running with the onboard disabled & a GeForce2MX in the AGP slot. I have removed the card, and have been unable to reproduce the bug!

Others with the bug, please check this out. It seems like NForce2 users were the main victims of the bug (if I remember correctly) and I wonder if it has to do with having a cardin the AGP slot.

Or, I wonder if it's related to the GF2MX.

Much testing still to be done! Please check this out ASAP!

Eugene Gavrilov

>> Rox271

thanks for your tests

>> But sbdy reported the bug using Win98SE in the previous thread

we need to verify this anyway

>> Most of the time this would fix the bug but in some rare occasion there is no other choice but reboot the PC

any more details?

>> Yes the bug affects everything

that is, any subsequent MIDI notes sound incorrectly, don't they?

>> to 256 (single DIMM) made no effect.

then it's not RAM-related

>> - note that the steams remain open even after you have ceased playback.

that's very important: what exactly do you mean?
what is the analyzer's window in this case?

>> NForce2 users were the main victims of the bug

I have nforce2 chipset -- and I experienced the bug only once -- after playing with Sandra/ DMI Bios utilities...
and I don't have on-board video

anyway, the presence/absence of some PCI cards (as well as PCI timers) seem to affect the bug

/E

Caithleann

I am not half as tech savvy as some here and I don't have the time to strip parts out of my computer but here is something that might be of interest.

The last few days I also had problems and almost went out to buy a new sound card when I came across this thread.
In my case I was playing a Pinball game made with a program called Visual Pinball. It allows the playing of sounds and 1 MP3 at anyone time which are triggered by VBscript. I don't hear a steady beep but a slew of different sounds rapidly following each other all sounding very digital, very harsch (as in square wave harsch) and loud.

It is very hard to describe but since I have a soundcreating background I will attempt to anyway. I have heard very similar sounds back in the days when we were creating single page ROM samples for Synthesizers during the late eighties and early nineties. If the sample was perfectly lined up and looped the result was a good sounding sample, but if the loop parameters exceeded the page boundaries that schratchy sound we have here resulted. One company in the US took advantage of this anomaly and allowed such samples to be played across their boundaries and wrote extensive ADSR algorhitms for further processing. This company was called Ensoniq (bought out and absorbed by Creative) and they called their newly created sound a Transwave.

The sounds I hear coming out of my speakers don't stop either when I pause or quit my game until quite a bit later.

My System is:

Processor Pentium IV (x86 Family 15 Model 2 Stepping 9 GenuineIntel_ ~2639 Mhz
Motherboard = ASUS P4C800 DeLuxe
ChipSet = Intel 875P
RAM 512 MB
BIOS Version/Date American Megatrends Inc. 1006.005, 5/6/2003
OS = WinXP 5.1.2600 SP1

Most recent installs: Reason 2.5
SLD (Video) Codecpack 1.5.3 to enable streaming MPG video.
Real Alt Codec to be able to view Real Audio video.


System information for Sound Device:

Name kX 10k1 Audio - Model CT4620
Manufacturer Creative Labs - kX Project
Status OK
PNP Device ID PCI\VEN_1102&DEV_0002&SUBSYS_00211102&REV_05\4&2E9 8101C&0&50F0
I/O Port 0x0000DF80-0x0000DF9F
IRQ Channel IRQ 22
Driver c:\windows\system32\drivers\kx.sys (5.10.00.3534 - debug, 498.63 KB (510,592 bytes), 8/18/2003 15:27)


Name SoundMAX Integrated Digital Audio (onboard audio)
Manufacturer Analog Devices, Inc.
Status OK
PNP Device ID PCI\VEN_8086&DEV_24D5&SUBSYS_80F31043&REV_02\3&267 A616A&0&FD
I/O Port 0x0000E800-0x0000E8FF
I/O Port 0x0000EE80-0x0000EEBF
Memory Address 0xFEBFF800-0xFEBFF9FF
Memory Address 0xFEBFF400-0xFEBFF4FF
IRQ Channel IRQ 17
Driver c:\windows\system32\drivers\smwdm.sys (5.12.01.3583, 542.63 KB (555,648 bytes), 9/16/2003 21:00)


Hope this helps a little., thanks


Caithleann

__________________
One cannot lie unless one knows the truth!

Rox271

• I just have the beep now and cannot cancel it. In the analyzer, I can see that voices are activated randomly, still from left to right but not in the sequencial order; some voices are skipped. Therefore I'm not sure that the original voice that was active when the beep occured is reused and this could explain why the beep is not cancelled.
• Also, when playing a pair of voices using the Winmedia Player, I can see 2 large red strips and 2 small red squares on the top (in the top white row). I never could figure out what they are but I suppose these two squares correspond to muted recording voices? Most of the time these to squares are just next to the large strips. But right now they are not???
• After some more experimentation, I just stopped Winmedia player and the large strips disappeared which is normal. But the two squares now remain on screen and would not move anymore when I play again. They were used to disappear and follow the large strips when playing again.
  This really looks like a weird bug. Have no more choice but reboot the PC.

Hmmm. You mean using a soundfont? Haven't tried that, not using MIDI. I don't even have a single soundfont on my PC .

256Mb is still quite a large amount of RAM isn't it?

[color=yellow]By the way, how can I acquire the v3535 some people are talking about?[/color]

Eugene Gavrilov

>> and 2 small red squares on the top (in the top white row). I never could figure out what they are

two top squares are the -actual- flags indicating the voice is active (allocated) or inactive (freed)
the 'large' bars who the 'volume' of the allocated voice

>> But right now they are not

it is more or less ok if there are two red squares and there aren't corresponding bars
[well, it means there are allocated voices that are either stopped or their volume is set to 0]

but if you see 'bars' but don't see ' squares' -- this is critical, since there are some invalid voices still playing back...

>> two squares now remain on screen and would not move anymore when I play again

this sometimes happen since DirectSound allocates 2 additional voices (once)
they are used for WinMM playback and are muted by default
that is, when you start DirectSound playback [stereo], it should allocate 4 voices -- two for playback and two for WinMM
if you start one more DirectSound stream, you should see only -two- additional strips (since WinMM stream is already allocated)
if your audio application uses WinMM -- you should see only -two- strips

the top squares should be 'white' if the voice is freed and stopped
if the top squares are darkblue, this means a 'released MIDI voice still playing'

>> Hmmm. You mean using a soundfont

yes, of course
I haven't heard any reports related to SoundFont playback in the same situation

>> By the way, how can I acquire the v3535

in the 'General section' -- the topic called '3535 rc2'

/E


/E

Rox271

Doh! I'm so used to go straight in the bug section that I didn't even have a look into other sections .
Thanks for all this information Eugene. I just downloaded v3535 and will pursue tests using this one.

I downloaded a crappy 2Mb GM SF and tried playing some MIDI during the beep.
This actually resets the beep very quickly!!!

Experimentation:
Play MP3 with Winmedia Player till the beep happens.
Now I have 4 voices allocated : MME (not actually used) and DX.
So I went in Soundforge (Winmedia remains open) and played a long WAV. This will use the MME voice that was allocated by Winmedia (strange? How can one application share something it allocated for itself??).
Still have only 4 voices allocated and everything beeps.
Then I started a MIDI file in Winmedia player; the DX voice is closed but not the MME still beeping.
The MIDI file started with some brief drums shots which means it didn't immediately required a large amount of voices. Results : MIDI beeps till more voices are allocated.
I have to confess that the beep didn't sound quite the same as usual on MIDI. It was more like some kind of amplitude modulation not a noisy beep.
Conclusion: the beep affects MIDI.

Other consequences:
After playing some MIDI file, most voices remain in a Dark Blue (Black?) state and Winmedia would almost always use the same 4 voices till I actually quit Winmedia. I guess this kinda ensure more stability cos I cannot get the beep anymore.

Other weird things that I noticed
I just rebooted the PC and started Winmedia Player with an MP3.
When I press start, 4 voices are allocated (2DX and 2 MME).
When I press stop, the voices are released and Winmedia allocates the 4 next voices (????) during a very brief delay then everything is blank. So everytime I start/stop 8 voices are actually used. Since there are 64 voices, I should loop every 8 start/stop. That is not the case. For some reasons, after a while, some voices are skipped and this happens randomly.
Also it looks like the beep will occur when this "random" behavior happens.

Features
By the way, where is the global voice resetting button you were announcing in a previous thread?

Nappylady

MIDI... Soundfonts... Hmm!

I noticed an annoying behavior earlier; sometimes, when using Vienna to preview a soundfont, I would get a "white noise" instead of a note, or the sound would get "dirtier" until it was unlistenable, and then would slowly go back to normal. (Anyone else experience this?) I did not try watching the analyzer whilst doing this.

I haven't tested for this behavior since pulling out my GF2MX (and thusly killing the wave beeping bug) but I will be sure to do that sometime soon.... I'm not even really sure if the two bugs are related, but I guess I'll find out!

nuppe

I can confirm on Midi resetting the noise, it seems like media player allocates the voices all in a row if you play midi files (e.g. C:\WINDOWS\Media\onestop.mid on XP). Play the file and look in the analyzer and you'll see.

By the way, I Checked the PCI latency setting in my BIOS, and it seemed like in some misguided attempt to tweak things i had set it to zero! Since i changed it back to the default 32 there have been no more beeps!

Verify that you don't have weird latency settings in the bios, or some program changing the settings after bootup.

/Andreas

Rox271

Before the beep occured, I never heard about PCI Latency; I found some explanation and decided to share it with people wondering what the heck is that damned PCI latency (see extract below). On the other hand I still don't know what happens if a device needs the PCI bus when it's busy. Could the kx driver ignore the busy state and leak some information?
I'm now using 32 for all devices and the system is quite table but still the beep occurs from time to time. The most efficient way to not only cancel but also prevent it that I found so far it is to play a MID file.

The PCI latency timer Source
The answer to this question has everything to do with a configurable setting that each PCI device has, the PCI bus latency timer. It's normally the role of the Linux driver to set the proper PCI bus latency timer value for each PCI device in your system, and most of the time the default settings are adequate (if not optimal), all the devices get along fine and the system works properly. The PCI bus latency timer can range from zero to 248. If a device has a setting of zero, then it will immediately give up the bus if another device needs to transmit. If a device has a setting of 248, it will continue to use the bus for a longer period of time before stopping, while the other device waits for its turn.

If all of your devices have relatively high PCI bus latency timer settings and a lot of data is being sent over the bus, then your PCI cards are generally going to have to wait longer before they gain control of the bus and can begin sending data. However, once they gain control of the bus they will be able to burst a lot of data across it before giving up the bus to another device. This is why high PCI bus latency timer settings increase latency (the delay in sending data across the bus), but also increase effective bandwidth. Because each device gets to burst large amounts of data across the bus without interruption, the PCI bus is used more efficiently and your PCI devices can transmit more data.

On the other hand, if all your PCI devices have low PCI bus latency settings, then they're going to gladly give up the bus if another card needs to transmit data. This results in a much lower data transmit latency, since no device is going to hold on to the bus for an extended period of time, causing other devices to wait. The dark side to all this is that low PCI bus latency timer settings reduce the effective PCI bus bandwidth when two or more PCI devices are operating simultaneously. This happens because large data bursts become much less frequent and control of the bus changes rapidly, increasing overhead.

Eugene Gavrilov

I'm sure people will find the PCI latency information useful

btw, the driver doesn't deal with the PCI latency at all
it is up to the hardware
so, probably, if the necessary hardware state is not changed within a given period of time (due to bus lock-up),
this causes the bug... I'm unsure

>> but also prevent it that I found so far it is to play a MID file

do you mean that playing a MIDI file right after reboot will make the bug unreproducible?

/E

Rox271

>>do you mean that playing a MIDI file right after reboot will make the bug unreproducible?
Yes and no. What happens is when a MIDI file was played, all the channels were allocated. For some reasons, the kx driver happens to spare MIDI voices and would preferably always reuse the same MME & DX channels in Win Media Player. This could well "auto fix" the bug.

More about the MIDI beeping : it really sounds like an amplitude modulation. The MIDI sound font is quite clear but with some kind of spectrum inversion. This really sounds like a ring modulation. Very strange. Nothing to see with a short sample loop.

By the way, I'm considering to get rid of my SB Live and purchase an Audigy 2. Shall I expect any dramatic change? Can this potentially fix the bug? In other words: Is it worth the money?

Eugene Gavrilov

>> Audigy 2. Shall I expect any dramatic change

well.. you'll get better DSP settings, 24/96 support, direct spdif recording, ac-3 passthru, ac-3 spdif-in decoding
and a little bit better codecs
that's it

concerning the beeping issue -- well, I'm unsure if it is related to the particular card or 10k1/10k2 difference
(I've experienced this bug =once= [I have audigy2] -- so, who knows)

/E

Rox271

And native (non beeping?) ASIO drivers according to the supplier...

kalimba

I'm pretty low tech, but wanted to add that I've been using these drivers for a while on 2 computers with 98SE, one seems fine, and the other (which gets a lot more use) regularly would have no sound. Rebooting did not help. I always reloaded the drivers (first 3528, then 3531) to get the sound to work again.

We're using Protools free along with sonic foundry's Acid on these computers, almost exclusively. After reading these threads, I tried a little experimentation.

Looking at the analyzer, when using Acid, every time I hit play, the 2 red lines move up 2 notches. After a certain number of hits, I will _always_ get silence, and then beeps, for 32 hits of the play button, when everything cycles through I get sound again.

In protools, I get 4 red lines on the analyzer, but they do not move when I hit the play button.

It now makes sense that I'm losing sound these days more often because one of my students is regularly using the Acid program.

Anyway, I'm glad to see that I no longer have to keep reloading the software. I can open Acid and click through the play buttons.

I sure hope a fix for this happens soon...

Eugene Gavrilov

pls try the 3536's 'kxctrl -rv' feature

/E