@Steff

Quote:

If you want I can put the SB live!(yeeuch) back into my machine and do an instant replay if you think it's needed?

Heh, your call- I'm satisfied we have a workaround, if not definitve root cause or workaround in code. You've shown many times you can reproduce it with the SB card, and not with the new card.

One question- is the new card in the same PCI slot, just to be completely thorough?

_________________
Are we not done with the same silly arguments and flames yet??!

Just kinda jumping in here, but I will say from experience that the SB Live! IS a resource hog. If you install it under windows, it gets it's very own category under Device Manager even! I used to have the standard Live! card, and I found the Audigy to be much more stable (at least in my PC.. which was a Via Apollo pro 133A chipset based Tyan Trinity, and now I use the Intel D865PERL motherboard). I will, however, be getting an A1 soon and I must have good stable audio, so I probably won't even touch the Creative Labs cards.

Just a thought... I wonder if the Live DSP/controller is conflicting with the non-functioning AC'97 controller on the Via southbridge of the A1XE?

Last edited by graffias79 on 13-Jul-2005 at 12:51 AM.

@graffias79

I believe Audigy was mentioned in this thread several times with similar results.

Best Wishes,
#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

It is probably some small error in the emu10k driver as the
Envy24HT driver performs flawlessly.
I have full confidence in DaveAE to solve this problem before
OS4 final is released

_________________
/Harry

[SOLD] µA1-C - 750GX 800MHz - 512MB - Antec Aria case

Avatar by HNL_DK!

@number6

Yes im using Audigy2 and had this lockup every day i listen
to mp3 streamings (even without streaming). Sometime really fast
other times after some hour.

However lately i have my tower opened and i off misstake changed
my 800mhz cpu (its 933 downclocked) to 866mhz and as its really
hot now in Sweden i got some crashes. Not audio but just crashed
like the cpu is too hot. I changed my FAN to blow fully instead
of halfspeed. More noisy but the heatsink feels good again.
I put back also the cpu to 800mhz.

And the crashes seems to be gone. Its strange as before a crash
happens i hear the DVD click like its resetting. The same sound
as when you reset your miggy and dvd starts clicking. Then i
know, in a second or two it will freeze :')

Its WB that freezes so i cant open any dir (just waits) etc.
However programs in background like mp3players, ibrowse etc
continues to work/play. If i quit Ibrowse it comes to the part
where it wants to close its window and then freeze. So i believe
no communication with workbench. I removed some programs i lately
installed like .ico datatype etc, changed in uboot to be as before
and my computer seems to work nice again. Oh not to forget Mplayer
did crash when i used search forward often.

However all this i believe is with all latest stuff when i changed
uboot, cpu speed and the hot weather.

About the lockup with sound its still there. This has always been
there for me from the first os4update and with all fans/heatsinks
i changed. Just to let you know im back again as i didnt have any
WB crash for some days now. So i couldn't do any testings etc.

Now i just have to download the .aiff test from Dave and check.
Feels nice that my miggy works good again.

@DaveAE

My arguement wasn't regarding data bandwidth usage on the PCI bus. The PCI bus data bandwith won't be used by the soundcard's tiny data packets, I know. Try to look at it this way. A NIC will receive data and the use DMA to copy the data to main memory. There's not much to it.
A "no CPU/DSP" soundcard will use the system in a different way. The CPU sends small realtime data packets to the soundcard, and the CPU realtime decodes the MP3 stream. When a netcard makes a DMA transfer, it has a very low impact on CPU clockcycle usage. But a SB128 card with processor assisted MP3 decoding, will use many elements of the system, to get the job done.

Playing mp3's is not very CPU instense? Well, my 060/Sb128 combo seems very stressed when playing mp3's at normal bitrate, and high bitrates are simply impossible to archieve. The 060 can't directly be compared to a G4 or P3 CPU. But a 060 stressed to the max? That indicates some CPU usage even on a "modern" CPU. Or let me say it in another way. Have you ever heard even a quite powerfull PeeCee making sound clicks, when accessing other parts of the system? I have, many times. Why? Sometimes the chipset/CPU busses are hogged by transfer traffic, and the system suddenly goes "click-click". It seems strange, because system should have enough bandwidth and CPU power left to do it perfect(Please add WinDoze factor at will ).

So sometimes when the traffic is high on the various busses(Wegster), timings between the various becomes very critical. If a single chipset timing signal arrives a nanosecond too late, then the system could crash.

I could imagine a situation, where the netcard makes highspeed DMA transfers to main RAM, and the IDE controller also makes highspeed DMA's. Suddenly this annoying little CPU hungry sound card comes along, making all kinds of transfers, all the time. Not using much bandwith, but using interupts and DMA, while the highspeed cards has to wait. Even a low bandwidth device like a SB128, can with a single "bad" timing event, crash the chipset/bus. So any PCI card with critical timing settings, has the potential the bring any system down, no matter how much bandwith it uses.
Have you ever tried to fiddle too much with various BIOS latency timing settings, and found that the system starts behaving strange and crashes? I have, many times.

When a CPU gets hot, many nasty things happens. The signal quality drops, on the output pins of the CPU. The electroc flow speed drops, meaning higher chipset latency settings are needed. And even worse the signal-to-noise ratio(noise margin) might drop to an "out of range" condtion. The chipsets connected to the CPU, receives these low quality signals from CPU output pins. Until one of the timing signal is just outside the "legal" timing window, and the system crashes.

Timings on a motherboard are a critical part of the design. You have to take the lenght of the PCB tracks into consideration, to avoid signal strenght problems, timing problems, and even EMC related problems. A few mm of misplaced PCB track , can cause critical chipset timing errors, on any motherboard. An example could be the A1XE memory controller and a SD-RAM stick. The RAM expects a certain signal output and timing quality from the memory controller, and the other way around. This result in some RAM sticks working perfect, some seems to work, some won't work at all. Eventhough a SD133 RAM should be a fairly standard component, it's not. They differ a lot in terms of signal quality and timing tolerances.
Chipset and bus timing on the motherboard, has to be razorsharp and flawless. Or an unstable motherboard will be the direct result. If some component on the motherboard starts to work outside SafeAreaofOperation, the motherboard will crash sooner or later.

When I received my 800MHz G4, I had no problems running all sorts of more or less CPU intense tasks. But when I ran 3d stuff, with OpenGL software rendering, my A1XE crashed soner or later. Every time a program used the FPU for a certain amount of time, my system suddenly stopped working. It seemed like the FPU might had a defect in some way. But when I refitted the CPU cooler properly, the problems were gone!
My guess is the FPU part of CPU core got too hot, while the rest of the CPU core worked fine. This FPU heat problem apparently made the CPU behave badly in some way, resulting in a general motherboard crash. So playing mp3's on a task saturated A1XE, could be the last drop, that makes the system crash? I would say yes. If there's a heating problem on the Articia or CPU, and you're running a tasklist similar to Wegster's. Then random crashes might start occuring. So Wegster may have a heat problem with a motherboard component.

Sorry, I so busy trying to help out Wegster in my very first AW post, that I forgot to say hello. So here's a BIG hello to all my fellow amigans!!! Glad to join

Some time later this week, I'll try and post more info about my A1XE experiences. I have been working for some years with electronics. So I might be able to help when someody has problems with electronic related issues.

!8O)
/Cipher

@CiPheR

Quote:

I could imagine a situation, where the netcard makes highspeed DMA transfers to main RAM, and the IDE controller also makes highspeed DMA's. Suddenly this annoying little CPU hungry sound card comes along, making all kinds of transfers, all the time. Not using much bandwith, but using interupts and DMA, while the highspeed cards has to wait. Even a low bandwidth device like a SB128, can with a single "bad" timing event, crash the chipset/bus. So any PCI card with critical timing settings, has the potential the bring any system down, no matter how much bandwith it uses. Have you ever tried to fiddle too much with various BIOS latency timing settings, and found that the system starts behaving strange and crashes? I have, many times.

This actually sounds quite similar to the documented 686B/SB interaction bug, especially as some of the 'fixes' involve changing the PCI bus latency timing..

_________________
Are we not done with the same silly arguments and flames yet??!

@Kicko

Hi again,

Thank you for your reply and confirmation about the Audigy2. That saves us from
having to look up and re-supply a link to a particular card.
Glad to have you back and testing again.
DaveAE and Wegster will be pleased to get more responses from those doing Dave's
previously mentioned .aiff test.

Edit (Added):Repeating the link to Dave's test - Current thread - Page #3 - Post #57


Best Wishes,
#6

Last edited by number6 on 13-Jul-2005 at 03:13 AM.

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@thread

I did get a response back from George Breese (thank you George!), which was very nice to see, especially considering the length of time ago on the issue he was involved in. As a refresher, George was one of two people pretty publicly working on fixes for the Via 686B/SB Live issues as encountered years ago on some PC mainboards a few years back. If you follow the linkes I posted at the start of this thread, his name re-occurs fairly often.

I am posting his email response below, as it may be of use to DaveAE or others OS4 devs. DaveAE, I don't think there's any harm in posting this, but if for some reason you think it should not be, let me know.

Quote:

Good grief, there's a VIA VT82C686B sitting on the AmigaOne XE motherboard! What silly person put THAT there? :) Disclaimer time... I never had tools to debug these issues properly. VIA claimed to fix the problem in late-2001 editions of the VT82C686B. It's been four years since I was hip-deep in the problem. So, take everything here with a grain of salt, as they say. There is a major issue with the VT82C686B where, if both of its IDE channels are busy, it will continue touching the PCI bus after the PCI controller has removed GRANT. The theory was that the SoundBlaster Live brought out the problem because it frequently demanded access to the bus, forcing the PCI controller to constantly take GRANT away from the IDE controller while the IDE controller was requesting more time on the bus. The popular workaround was to increase the duration of the PCI controller's arbitration timer. The timer's default was 32 cycles, but the corruption stopped if the timer was increased to 96 clocks. This lengthened the time between the SoundBlaster Live's REQuest starting, and the IDE controller's GRANT stopping. But this workaround was specific to the behavior of VIA's PCI controller chip. Other PCI controllers didn't cause the problem, and the design of their PCI arbitration circuitry was undoubtedly the reason. Oh, and a timer over 64 cycles in length can cause problems if an ISA bus is also present on the motherboard. FYI, using PCI's Master Read Caching feature was also toxic, but this could have been a bad implementation of the feature on VIA chipsets. I remember being able to freeze the PCI bus by combining this feature with IDE activity and other sound cards, such as those using Aureal Vortex chips. There were plenty of other issues with VIA. The SoundBlaster Live card would crackle if it couldn't receive its sounds through the PCI bus in a timely fashion; having an idle Athlon processor "go to sleep" would trigger this handily. This was also reproducible on motherboards that didn't use any VIA chips. If you have access to the PCI controller of the AmigaOne motherboard, you can try tweaking the bus features and timings. I won't be able to help you gain access to the PCI controller, but someone should have a way to do it. Unfortunately, I can't contribute any time to the project. -- George

_________________
Are we not done with the same silly arguments and flames yet??!

@wegster

Well...that explains it.

Best Wishes,
#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@ikir

Quote:

The air blow on cpu and near, so also on the articia.

Thanks for the tip! Took apart old psu and fitted its fan to blow on the cpu area - instabilities with linux kernel 2.6.9 went away!

Now the life is brighter(no lookups with audio in aos4, 2.6.9 kernel seems to be stable)

Big thanks!
Jack.

_________________

"the expression, 'atonal music,' is most unfortunate--it is on a par with calling flying 'the art of not falling,' or swimming 'the art of not drowning.'. A. Schoenberg

@Samwel

Quote:

It is probably some small error in the emu10k driver

No, I'm confident there is no bug in the driver. You can see this from the problems there are with PC's using 686b's. The only solution could be in tweaking the latencies.

@others
One confirmation of a freeze with my aiff test was enough actually. Thanks for testing!

_________________
Audio Evolution
http://www.audio-evolution.com

@wegster

Quote:

Moving the card does not change the problem - tried it, no change.

Ok, it was desparate idea from start :)

@jack

So the problem are 3.

1-vcore and cpu over heating
2-articia overheating
3-via bug

????

_________________
ikir

@all

Does anyone knows about "Articia S"'s operating temperature specs? It is pretty hot sitting there under the cpu module (I do suffer crashes under linux 2.6.9, but much less frequently, now fitted the extra fan at different angle to allow the articia more air flow).

TIA,
Jack

Last edited by jack on 13-Jul-2005 at 02:40 PM.

_________________

"the expression, 'atonal music,' is most unfortunate--it is on a par with calling flying 'the art of not falling,' or swimming 'the art of not drowning.'. A. Schoenberg

@jack
Quote:

Does anyone knows about "Articia S"'s operating temperature specs? It is pretty hot sitting there under the cpu module (I do suffer crashes under linux 2.6.9, but much less frequently, now fitted the extra fan at different angle to allow the articia more air flow).

If only the AmigaOne's CPU module was mounted further up. There's just no room between the module and the motherboard to mount a heatsink or a fan.

Last edited by amipal on 13-Jul-2005 at 03:10 PM.

_________________
After a decade away from the scene, I am back!

Ok, I can reproduce the lock-up myself pretty easy now: just using the soundtest, running ftpd and copying 2 or 3 large files across the 100Mbit LAN, and freeze assured within 1 minute (edit: ok, sometimes it takes longer). And the Aureon (using Envy24HT) has no problems at all..

You can now all stop doing tests...

Last edited by DaveAE on 13-Jul-2005 at 10:15 PM.
Last edited by DaveAE on 13-Jul-2005 at 10:08 PM.
Last edited by DaveAE on 13-Jul-2005 at 10:03 PM.

_________________
Audio Evolution
http://www.audio-evolution.com

@DaveAE

I have the programm running now for 4 hours now on my µA1/750FX while downloading several ISO images to a VIA driven harddisk and have no lockups so far. The sound is slightly distorted, but I think this is because mplayer (more precisely mplayer audio task) crashed twice.

_________________
Why stop it now, just when I am hating it?

Thore Böckelmann

@tboeckel

Yes, it seems a SB Live / emu10kx problem only.

_________________
Audio Evolution
http://www.audio-evolution.com

Ok, important finding. The SB Live does not receive interrupts anymore on a freeze. This was not the case with the network+UDMA on VIA bug. I'll try changing some VIA regs.

_________________
Audio Evolution
http://www.audio-evolution.com