Esound and FS9.1

[Andras]

Hi Pete,

I have just started experimenting with esound for some specific sounds that I need in my cockpit, and it seems it doesn't work under FS9.1 (I get a panel.dll error).

Is there any chance you may look into it some day or should I just forget about it, as it is clearly unsupported?

regards

Andras

[Pete Dowson]

I have just started experimenting with esound for some specific sounds that I need in my cockpit, and it seems it doesn't work under FS9.1 (I get a panel.dll error).

Is there any chance you may look into it some day or should I just forget about it, as it is clearly unsupported?

I can look at it, but I can assure you that there's nothing changed between 9.0 and 9.1 which would affect Esound. For token-named variables it does use panels.dll, just as a gauge would do (Esound started life as a gauge). PANELS.DLL will crash quite readily if token value requests are made of it when there's no aircraft loaded and ready -- e.g. during initial loading and during relading of flights and/or aircraft.

However, in those times Esound doesn't really get a look in, and I've never seen a crash brought about in this way.

It shouldn't be a problem at all for FSUIPC offsets -- Esound calls FSUIPC for those and the latter provides the protection for unloaded aircraft.

Mind you, I haven't used Esound for many years. I simply do a re-test and make minor adjustments if necessary for each FS release. My standard test may not be extensive enough though.

I just tried again with 9.1 and cannot get it to fail. At what point do you get a failure? Have you actually programmed it to do anything yet? Maybe if you sent me your Esound.CFG file to try here?

BTW isn't pmSounds able to cope with virtually everything now?

Regards,

Pete

[Andras]

Hi Pete,

For token-named variables it does use panels.dll, just as a gauge would do (Esound started life as a gauge). PANELS.DLL will crash quite readily if token value requests are made of it when there's no aircraft loaded and ready

As I was just in a very initial stage to try it out, I only tried two simple token variables.

[Devices]

1=Primary Sound Driver

2=SB Audigy Audio [DF80]

[sounds]

1 = esound\letototte.wav

2 = esound\done.wav

[Polling]

Var = 5

[Triggers]

1 = AUTOPILOT_ACTIVE = 1.0, 1, 1, LOOP

2 = AIRSPEED <= 10, 1, 0

I willl also try FSUIPC offset, as you say those are better.

I just tried again with 9.1 and cannot get it to fail. At what point do you get a failure?

Whenever I tried to change a trigger as token. Sometimes nothing happened, but when the first panels.dll error occured, it was giving it unless I disabled the trigger line.

BTW isn't pmSounds able to cope with virtually everything now?

Not quite (unfortunately). Two main things. It can not really loop sounds and the worse that it doesn't accept offset ranges. It accepts an offset but without values... What Enrico programs into it works well, with variable values, etc. but the user configurable part is too simple.

Regards,

Andras

[Pete Dowson]

1 = AUTOPILOT_ACTIVE = 1.0, 1, 1, LOOP

2 = AIRSPEED <= 10, 1, 0

I've just tried your exact CFG file, except with my devices and different (FS) sounds, and it works fine here in FS9.1. How can I make it fail?

Incidentally, I note that you start the Autopilot Active sound in a loop when the autopilot is switched on, but you have nothing to terminate the loop, so it will continue forever after then.

I willl also try FSUIPC offset, as you say those are better.

Well, more flexible and a little less dangerous, but all of the early uses of Esound were using the gauge tokens. It shouldn't matter.

Whenever I tried to change a trigger as token. Sometimes nothing happened, but when the first panels.dll error occured, it was giving it unless I disabled the trigger line.

Sorry, I don't fully understand that part. You mean the Panels DLL error did NOT occur whilst loading an aircraft? It occurred whilst everything was relatively stable? If so, then I certainly don't understand that -- there's nothing in the Esound access which won't work with a stable setting. Furthermore, if you mean it doesn't crash until you change something (e.g. switch on the A/P) then it really isn't going to be related to token access -- Esound will have been looping like mad reading that token in any case.

Things to check:

1. Are you using the current version of Esound? (2.572).

2. Does this occur with the default FS panels?

3. Does it occur with default FS sounds or only your own creations?

Item 3 is looking the most likely. If, as you say, either "nothing happened", or a panels.dll crash occurred, but only when you expected a sound to trigger, then it seems most likely that the WAV files you are trying to use are clobbering something in FS.

Esound doesn't play sounds independently from FS, it is using DirectSound and, if these are on the same sound device as FS, blending them into FS's sounds. I'm wondering if it is possible that your WAV files are not compatible with FS's WAV files.

Regards,

Pete

[Andras]

Hi Pete,

I've just tried your exact CFG file, except with my devices and different (FS) sounds, and it works fine here in FS9.1. How can I make it fail?

If I fire up FS with NO trigger in the cfg file, it loads ok. Then I change the cfg (Fs still running) and remove the comments before the trigger, and it works just fine. I fly around, no problems. But when I close FS and start it again, the panels.dll error appears and repeats it at each startup, until I remove the trigger again...

Incidentally, I note that you start the Autopilot Active sound in a loop when the autopilot is switched on, but you have nothing to terminate the loop, so it will continue forever after then.

Oh yes, but that was just a test. If it loops, I can hear what happens.

Sorry, I don't fully understand that part. You mean the Panels DLL error did NOT occur whilst loading an aircraft? It occurred whilst everything was relatively stable?

Yes, everything stable, using the default 737 at Meigs.

1. Are you using the current version of Esound? (2.572).

2. Does this occur with the default FS panels?

3. Does it occur with default FS sounds or only your own creations?

1. Yes.

2. Yes.

3. Yes, I changed my file to one of the default 16 bit mono 22500 FS sound. Mine was the same, just 8 bit instead of 16.

Regards,

Andras

[Pete Dowson]

If I fire up FS with NO trigger in the cfg file, it loads ok. Then I change the cfg (Fs still running) and remove the comments before the trigger, and it works just fine. I fly around, no problems. But when I close FS and start it again, the panels.dll error appears and repeats it at each startup, until I remove the trigger again...

Ah, so I did misunderstand you when you said "Whenever I tried to change a trigger ..." -- you did NOT mean actually operating the A/P switch, for example? That's how I read it.

In fact you now seem to be saying that the error occurs during the load of the aircraft -- Esound is somehow getting to run before FS has loaded the aircraft, hence the panels crash. Right?

OR do you really mean this apparently conflicting statement (in answer to me asking "It occurred whilst everything was relatively stable?":

Yes, everything stable, using the default 737 at Meigs.

Once we can understand each other, so I can picture what is actually happening, which is difficult at present, then I can make the best suggestions.

If it is because of access whilst FS is still loading, then some small changes to Esound (to check certain new FS flags, for instance) could probably fix it okay. Alternatively I could trap errors and discard them, which may or may not answer everything.

But my main problem is that Esound isn't suitable, as it stands, for re-compiling using my current development system. If it was then either of these solutions could be achieved quite quickly. As it is, it is about a day's work to move it over. I can probably fit that in soon, but not this week or weekend, I'm afraid.

Please clarify exactly what is happening, resolving some of the conflicting statements, and I'll make some decisions on this. Meanwhile, if this hypothesis is correct, it would have probably failed in the same way on your system in any version of FS -- it's just extremely odd that I cannot make it do so here. You may be able to do what you want better using FSUIPC offsets instead.

Regards,

Pete

[/i]

[Andras]

Hi Pete,

Ah, so I did misunderstand you when you said "Whenever I tried to change a trigger ..." -- you did NOT mean actually operating the A/P switch, for example? That's how I read it.

Yes, it also happened. After I got the FIRST error message, I tried to change the trigger, thinking that it might be a syntax error. But the error appeared every time after that, regardless what I actually entered. The only cure was to disable all triggers and restart FS. So you are probably right, and it happens when loading the plane.

In fact you now seem to be saying that the error occurs during the load of the aircraft -- Esound is somehow getting to run before FS has loaded the aircraft, hence the panels crash. Right?

Yes, that seems to be the case.

OR do you really mean this apparently conflicting statement (in answer to me asking "It occurred whilst everything was relatively stable?":

Sorry, I meant that answer to state that it happened when no "strange" or 3rd part plane was loaded or rather I was trying to load it.

But my main problem is that Esound isn't suitable, as it stands, for re-compiling using my current development system. If it was then either of these solutions could be achieved quite quickly. As it is, it is about a day's work to move it over. I can probably fit that in soon, but not this week or weekend, I'm afraid.

Any help from you Pete at any time is truly a wonderful thing, so of course I am not at all forcing you impatiently to do anything, specially that your wonderful module is 'officially' unsupported. By just the few sentences by me you took care of shows, that your support is the the best on global scale...

I will also try it on other machines, as so far I have only experimented on my main one. BTW, all are XP-pro I don't have other OS left here.

Thanks for everything

Regards,

Andras

[Pete Dowson]

Ah, so I did misunderstand you when you said "Whenever I tried to change a trigger ..." -- you did NOT mean actually operating the A/P switch, for example? That's how I read it.

Yes, it also happened. After I got the FIRST error message, I tried to change the trigger, thinking that it might be a syntax error. But the error appeared every time after that, regardless what I actually entered. The only cure was to disable all triggers and restart FS. So you are probably right, and it happens when loading the plane.

We still seem to be talking at cross-purposes here. There are still serious inexplicable conflicts in what you say which prevents me understanding what you are seeing.

You say "Yes, it also happened" in answer to the question "you did NOT mean actually operating the A/P switch, for example?", but you end by saying "So you are probably right, and it happens when loading the plane."

All I can derive from this is that

(a) it happens when loading the plane, AND

(b) it happens when you operate the A/P switch in FS

The former is probably because PANELS.DLL is calling upon SIM1.DLL to suply data before an aircraft is fully loaded, but the latter can only be down to a problem with the Sound itself, as far as I can see.

There's no point in me solving one part if the other is still a problem.

So, please, can you be more specific? Just a simple statement of what you do and what you see, including WHEN you actually operate the A/P switch itself.

Have you tried using the FSUIPC offsets instead yet? Does this fix the aircraft loading problem but not the sound-crashing problem when you operate the switch?

I am out most of tomorrow, so there will be a delay in further replies. Apologies.

Regards,

Pete

[Andras]

Hi Pete,

We still seem to be talking at cross-purposes here.

Truly sorry for not being clear enough.

All I can derive from this is that

(a) it happens when loading the plane, AND

(b) it happens when you operate the A/P switch in FS

It ONLY happens when I load the plane.

It does NOT happen when I operate the AP switch it works fine once FS is up. But works at all, if I enter the trigger line WHILE FS is running. If I do it before FS is started it crashes with the panels.dll. After it worked fine in FS it also crashes the next time I load it.

So, please, can you be more specific? Just a simple statement of what you do and what you see, including WHEN you actually operate the A/P switch itself.

Same here, once FS is up and running without the trigger line and I add it while FS is up, all is well, the A/P switch works, the sound works.

Have you tried using the FSUIPC offsets instead yet? Does this fix the aircraft loading problem but not the sound-crashing problem when you operate the switch?

I tried the entire thing on two other (XP) machines. The results were the same.

Also tried FSUIPC offsets, but couldn't get any of them working, but it might be my fault, as the syntax was new to me. But no errors, FS LOADS up with an FSUIPC trigger, just nothing happens.

Thanks and have a nice weekend

regards

Andras

[Pete Dowson]

Just caught your message before I leave for the day.

I tried the entire thing on two other (XP) machines. The results were the same.

Strange it won't happen here on any of my three PCs on which I have FS9.1 installed -- two on XP Pro, one XP Home. It'll be some sort of timing thing. How do you start up FS -- does it go into the selection dialogue where you eventually press "fly Now", or have you got it going straight into the default flight? And when EXACTLY does the crash occur?

Also tried FSUIPC offsets, but couldn't get any of them working, but it might be my fault, as the syntax was new to me. But no errors, FS LOADS up with an FSUIPC trigger, just nothing happens.

Please let me see your entries.

Regards,

Pete

[Andras]

Hi Pete,

How do you start up FS -- does it go into the selection dialogue where you eventually press "fly Now", or have you got it going straight into the default flight? And when EXACTLY does the crash occur?

I never use the selection dialogue, rather load FS directly into the 'flight'.

The crash occures before FS starts loading the scenery, meaning before the slider for 'loading scenery' appears.

The great news is that now everything works fine with FSUIPC offsets. Sorry for misleading you yesterday by saying that they didn't. I made a silly syntax error, that was all. No loading crashes when these are used, everything is perfect. This what I did for testing:

1 = VB028C = 1, 1, 0 //Landing lights on

2 = VW07BC = 1, 1, 0 //Autopilot master on

3 = VW0BCC = 1, 1, 0 //spoiler armed

4 = VW0BD0 >= 4800 & VW0BD0 <= 16383, 1, 0 //spoilers deployed

So it seems the timing error has to do with Tokens only.

Regards,

Andras

[Pete Dowson]

So it seems the timing error has to do with Tokens only.

Okay, I can deal with that, but not just yet. Stick to FSUIPC offsets for now!

Regards,

Pete

[Andras]

Okay, I can deal with that, but not just yet. Stick to FSUIPC offsets for now!

Sure. Many thanks for your help!

Regards,

Andras

[Andras]

Hi Pete,

Sorry, I'm back again with some updates on this issue.

After almost a day of experiments, it turned out that the problem is not only with the tokens, but I also get ntdll crashes when using the FSUIPC offsets.

There are two variations of crashes.

The first when it just crashes affter some time, I couldn't find any particular way to trigger it.

The second is more interesting, it happens with all wav files that are shorter than 1 second. They always crash with ntdll.

regards

Andras

[Pete Dowson]

After almost a day of experiments, it turned out that the problem is not only with the tokens, but I also get ntdll crashes when using the FSUIPC offsets.

There are two variations of crashes.

The first when it just crashes affter some time, I couldn't find any particular way to trigger it.

The second is more interesting, it happens with all wav files that are shorter than 1 second. They always crash with ntdll.

Hmmm. I can't really see how any of that is really likely to be anything to do with Esoundit looks like you have other problems on your system to do with sounds. That is, unless Microsoft have made the DirectSound routines incompatible between DirectX 6 or 7 and whatever is current, which seems rather unlikely.

The DirectSound routines in Esound haven't change in many years and always worked fine, and the access to FSUIPC variables is done in no different a way than any other FSUIPC user would use.

NTDLL is simply a main support library in Windows. If I were you I'd check your sound drivers and DirectX installation.

There's certainly nothing in any of that coding I'd want to go near in Esound, it was bad enough doing the research to make it work in the first place. DirectX is about the most unfriendly, complex and difficult API to work with that could be devised and I want nothing more to do with it ever again if I can possibly help it.

Let me know if you decide not to bother with Esound any more and I won't do those other changes either. It will save wasting a day or two. On the other hand, maybe a simple re-compilation will actually help, though I really can't see why.

The only other alternative I can think of is for me to produce a non-DirectSound version of Esound -- one with all the other facilities intact, but the sound playing reduced to a simply "PlayWave" call -- no speaker selection, no DirectX. Maybe no looping (I'm not sure whether the simple interface provides looping).

However, this is quite a bit of work as it would involve wholesale changes. I'm not really inclined to do this. It would be a *lot* easier and quicker, I think, for pmSounds to be enhanced a little. Why don'y you put your needs together and ask Enrico?

Regards,

Pete

[Andras]

Hi Pete,

... it looks like you have other problems on your system to do with sounds.

I would have thought of that, but I tested the entire thing on 3 different machines, getting the very same result, so unfortunately it is unlikely my settings would be the culprit.

The DirectSound routines in Esound haven't change in many years and always worked fine

Of course. But FS9.1 did something to it, I guess hence the error with the tokens too. Perhaps panels.dll changed that much.

Let me know if you decide not to bother with Esound any more and I won't do those other changes either. It will save wasting a day or two. On the other hand, maybe a simple re-compilation will actually help, though I really can't see why.

I would most certainly do that Pete, specially, that I know that an officially unsupported prg, written for an earlier version of the sim, is really something that I could not truly beg for support, specially that I know how valuable your time is.

However, as it is a wonderful small prg, that just does exactly what I wish for, please forgive me if I give up upon it a bit reluctantly...

A non-DirectSound version would definitely be lacking the looping facility, that is the MOST important for me in this case, as when it works, it gives the most precise, fast and clearest result.

Another route for me would be to write gauges, as they could do just the same, but as I have never done that in my 15 yrs of FS ventures, I thought it would be simpler, and possibly more beneficial for others too, if I just requested you to look into something, which may not be perfect for the latest FS patch, but is ready and does it easyly and nicely.

If you could just try what you have said, a simple re-compilation, perhaps it would solve all problems, and I am certain that a quick look into what troubles the interaction with panels.dll, would solve it all. I'd be (and hopefully others as well) truly grateful for that, as giving up on it would be a mistake in my view...

I have been thinking of going back to FS9.0 just for this simple reason, but in the long run, I'd be silly to do that I guess.

It would be a *lot* easier and quicker, I think, for pmSounds to be enhanced a little. Why don'y you put your needs together and ask Enrico?

He is very busy nowadays, and the very fact that PMSounds is having the OGL interface makes it much slower. It is good for the basic stuff if run on another PC, still having timing problems, and the lack of looping makes it just incapable. enrico said once that he might add loops to it, but that was almost a year ago...

Of course I can not force you into it, but if I can just friendly request you not to give up on it once and forever...

Regards,

Andras

[Pete Dowson]

Of course. But FS9.1 did something to it, I guess hence the error with the tokens too. Perhaps panels.dll changed that much.

No, the changes in PANELS.DLL are quite small and don't affect any of this. In any case the length of a triggered sound is actually nothing to do with either PANELS.DLL, or Esound for that matter. Once Esound has issued the command to DirectSound to play a sound it has nothing else to do with it. It can get a notification when it has finished, but it doesn't normally bother as there's no need.

Why do you believe there's so much difference between FS9.0 and 9.1 as far as Esound is concerned? Have you tried all these things in FS9.0 and found that they work okay? That would be quite interesting to me, and not a little surprising!

If you could just try what you have said, a simple re-compilation, perhaps it would solve all problems, and I am certain that a quick look into what troubles the interaction with panels.dll, would solve it all.

I really very much doubt that. The interaction with PANELS.DLL is exactly the same as any Gauge would use -- it's the same interface exactly. The only reason it crashes when aircraft are being loaded is that PANELS.DLL calls routines in SIM1.DLL which try to access data not yet initialised. I know all about that as FSUIPC has to take a lot of precautions. The only reason PANELS.DLL doesn't care about precautions is that it is normally only being used when Gauges are loaded and running -- and by then the aircraft is loaded and the data initialised.

Your reports indicated you were getting crashes in NTDLL during normal operation. that is most certainly nothing to do with anything related to PANELS.DLL. Not only that, you said you got them using FSUIPC offsets only, which excludes PANELS.DLL altogether as FSUIPC doesn't use it.

In fact the only thing in Esound which isn't also in FSUIPC or any other IPC interfacing program or module from me is the DirectSound interface.

I have been thinking of going back to FS9.0 just for this simple reason, but in the long run, I'd be silly to do that I guess.

If you have proven that none of these problems occur at all in FS9.0 I will be amazed. Is that what you are truly saying?

Regards,

Pete

[Andras]

Hi Pete,

Have you tried all these things in FS9.0 and found that they work okay?

That's what I'm just trying to figure out. I'll revert to 9.0 on one PC and will report back, I don't want to guess... seems my guesses were quite faulty so far... I learn more and more by every thing you say.

Regards,

Andras

[Andras]

Hi Pete,

Sorry, it's me again...

I reverted my main cockpit FS machine to 9.0

I had no crashes whatsoever. :P

When I tried to use tokens, the result was the same as in 9.1. Error with panels.dll.

As it is a 3.2 machine actually overclocked by 5%, is it possible that it's too fast while loading? (Don't get angry with this silly guesswork please, it happened once. Do you remember when I was asking you about the AutoTuneADF= setting re FSUIPC and the problem was that the software by TheRealCockpit folks was unable to autotune the fractional value? The problem was solved more than a month later when it turned out that their search rotation was too fast for faster computers. Just a weak guess...)

Regards,

Andras

[Pete Dowson]

I reverted my main cockpit FS machine to 9.0

I had no crashes whatsoever. :P

Really? That's astounding!

Look, I've found no changes in FS9.1 that affect anything other than a few things in FSUIPC -- mainly to do with weather. However, if you can reliable produce crashes with Esound in 9.1 which don't occur in 9.0, then I want to see how.

Do you think you can ZIP up your Esound CFG, plus the sounds you are using (if they are all in the sounds\esound folder, then just ZIP that up please), and send it to me at petedowson@btconnect.com? Once I can reproduce a problem fixing it becomes relatively easy.

Better include both the Esound.CFG with Tokens as well as the one with only FSUIPC offsets, though it will be the latter I'll concentrate on for this.

When I tried to use tokens, the result was the same as in 9.1. Error with panels.dll.

Don't worry about that for now. I should be able to deal with that. It's messy but doable. I might have to get you to do the testing though!

Regards,

Pete

[Andras]

Hi Pete,

...I might have to get you to do the testing though!

Gladly!!!

My config is on the way to you.

Thanks for everything.

regards

Andras

[Pete Dowson]

My config is on the way to you.

Okay. Thanks. I just tried it and I can't make anything fail, no matter what I do!

Can you give me precise instructions, please, on how to make it fail. I am using the latest FSUIPC (3.411), and FS9.1, and the default 737-400. Now what?

Unless I can get it to fail here I can't see how I can do much.

Incidentally, I noticed you listed three entries as "not working":

//These are not working...

5 = VB31F4 = 4, 6, 0 //Pushback

6 = VB0BCC = 1, 2, 0 //spoiler armed

7 = VW0810 = 1, 2, 0 //Autothrottle disarmed

I enabled those too. The offset 31F4 is for pushback CONTROL -- i.e. it is an input from an application to control pushback. the pushback state, which I presume you want, is 31F0. Whilst neither have been thoroghly tested in FS2004 (they were found in FS2002), I've just checked and certainly 31F0 seems to change correctly.

The spoiler armed line works fine. i tested by asrming the spoiler (which you can only do in the air) with Shift+/. Why did you list it as not working?

I'm not sure why checking for 0810 going to '1' is labelled "autothrottle disarmed" -- when it is 1 it is armed. However, that doesn't see to work here in any case. Not sure why.

Anyway, unless I can find a way to re-create the crashes you are getting, I really don't know how to proceed. I've not got time this week to do much on it in any case, but with no crashes all I might be able to do is re-compile, and try adding some diagnostics, error traps and so on, and try to diagnose things remotely.

Regards,

Pete

[Andras]

Hi Pete,

Can you give me precise instructions, please, on how to make it fail. I am using the latest FSUIPC (3.411), and FS9.1, and the default 737-400. Now what?

Same config here.

Alas I can't say how to fail it, as it was usually failing here after 15-20 minutes, but always when one of the sounds were triggered.

Pete, I will further test the crashes, it might be my overloaded PC (both of them) and that I will just test with a spare soundcard.

the pushback state, which I presume you want

Ah, many thanks. I overlooked the difference.

Anyway, unless I can find a way to re-create the crashes you are getting, I really don't know how to proceed. I've not got time this week to do much on it in any case, but with no crashes all I might be able to do is re-compile, and try adding some diagnostics, error traps and so on, and try to diagnose things remotely.

I'll be trying to reproduce and track the crashes.

Many thanks for your time and effort.

Regards,

Andras

[Pete Dowson]

Alas I can't say how to fail it, as it was usually failing here after 15-20 minutes, but always when one of the sounds were triggered.

Two things there:

1) I may not have tried for long enough then. 15-20 minutes is a long time for a developer writing and testing programs. It sounds like I would have to do a real flight too -- I was just checking things statically. Do I really have to have everything going?

2) The accesses Esound is making into FS are occurring all the time, so it can spot the changes. All that is happening differently when a sound is triggered is just that -- the call to DirectSound to make the sound occur. So it certainly sounds (excuse unintentional pun) like it's somehow related to the sound subsystem.

Also, so I could definitely hear if your sounds were being triggered or not, I turned the FS sounds off (Q). Do you still get crashes with FS's sounds off?

What version of DirectX are you using? I'm on DX 9.0c. But the PC I'm testing on (the only one with all my debugging aids installed) only has an on-board sound system, an Avance AC97 chipset I think. The drivers for that date back to March 2002.

Regards,

Pete

[Andras]

Hi Pete,

1) I may not have tried for long enough then. 15-20 minutes is a long time for a developer writing and testing programs

The last thing I'd expect from you is sitting there for hours. Please don't. I will sit here and report whatever comes.

2) The accesses Esound is making into FS are occurring all the time, so it can spot the changes.

Is it possible that a lower polling rate may help?

What version of DirectX are you using? I'm on DX 9.0c. But the PC I'm testing on (the only one with all my debugging aids installed) only has an on-board sound system

Same DX here. On one PC I have an Audigy and the other uses its inbuilt soundcard. Actually the latter was the one that shown those crashes after those valuable long minutes.

Tomorrow I'm going to buy another soundcard into it to test.

Regards,

Andras