There is obviously a performance hit when running games in WINE on Linux or OS X, especially if you're using an additional layer of abstraction like a 3Dfx GLIDE wrapper or in this case, the EE's version of Shlink. But overall hardware has gotten so powerful, in addition to continuing improvements in the host OSs and APIs themselves, (and WINE has made a lot of significant strides in boosting performance, compatibility, and efficiency) that the performance hit is almost negligible for old games like System Shock. That's especially if they're not using intensive 3D graphics/hardware accelerated graphics.

Sure, running SS through the EE running in Wineskin or CrossOver is not as elegant or efficient as running the CE in DOSBox with whatever patches I need to get most of the functionality in the EE (or just running the whole thing in Windows). But in terms of ease of setup and features, the EE in WINE is much easier to setup and play (especially since it doesn't need any special dependencies, settings or registry hacks) for me, with almost no discernable loss in performance versus the CE in DOSBox.

A performance hit doesn't automatically mean that gameplay is affected. As a simplified example, if my CPU which runs at 3.4GHz takes a 10% performance hit, it'll be equivalent to running at 3GHz - probably still enough to run the game at full speed.

I'm running the game at 1440x1080 on Linux+Wine and have no problems with performance.
I don't use fluidsynth, but that message there suggests that it would like to have elevated privileges. Does the fluidsynth binary have a non-root group owner and an s in its group bits? (ls -l /usr/bin/fluidsynth)? Perhaps you will need to add yourself to some system group and re-login.

That link is rift with nonsense. It's amazing what people will tell themselves.

Conversion of OS GUI is not as trivial as you think it is. The one thing that link does state is the entire performance hit argument I've been making all along. Do some Win GDI programming & DirectX and find out first hand. I know I have. I don't know that you have. You don't see any hit because you (clearly) have enough horsepower on your system to shrug at the performance hit. Programming performance maxim : There's no such thing as a free lunch.

The reality is if you have over a dual-core 2.5 GHz system, either version would probably work fine. Multiple steps of translation vs complete emulation, you're talking a wash in performance at best. Like I said earlier, people are conjuring up info to suit their preference without any real knowledge of what's occurring in either the case of full emulation (DOSBox) or partial (Wine/Crossover) "because they want to play the definitive version". I'm saying the difference between the two versions is negligible, and worth comparing to make a judgement.

Again, if EE running fine for you in Wine or Crossover, great. But if you're running into problems with the game not running well on your system, it's worth it to try the CE via DOSBox. Even a decent system will run it well. Whatever system you personally have isn't what everyone has.

Anyways. this is moot.

TL;DR : Try both and see which runs better for you, especially if you have a lower-spec machine where you may be better off with the CE and Mouselook patch.

Hmm, I don't know how to check or do that.

How did you get the music to work without fluidsynth?

I'm afraid that when you are perfectly willing to take the absolutely ginormous performance penalty of DOSBox yet find that an extra translation step is even worth talking about, you are not getting the big picture and should perhaps not be advising people on what's occurring.

Unless.. wait. Are you just confusing DOSBox and DOSemu? Because a lot of what you're saying would be relevant and make sense then. DOSemu has been spoken favourably of in regard with this game, and I have no problem believing that it could beat both DOSBox and the Wine+EE in performance, being comparable to running the EE on Windows.

I have an old SoundBlaster Live! card in my computer that can do wavetable midi synthesis on hardware. It's not the greatest card ever and has its quirks - I'm even sacrificing two gigabytes of memory to get around a hardware bug - but it's like an old friend that I've had since my first PC.

I searched for those messages of yours and they seem to be just warnings, it should work regardless. How do you mean it's 'off'? It's not supposed to sound the same as on Windows, unless you use fluidsynth there too. Midi is like sheet music, how it sounds like depends on the orchestra that plays it.

Wow, this is true love.
I've composed via midi for a long time now and know that the soundfonts are different, but the whole rhythm is completely botched and this shouldn't happen.

Well, surely that shouldn't happen, I don't know what's wrong.

The first warning is saying that it can't make sure its memory won't get swapped to disk mid-operation, which would kill any chance of realtime playback. As long as you have enough memory this shouldn't become a problem. The other two look like they might be related to sound hardware limitations and if so there probably isn't a way around them.

Is your computer at least passably modern with multiple cores? If not, I guess the synthesis could just be too heavy. Are you having a really high CPU usage while doing this?

I've got a Athlon II with three cores at about 2.9Ghz, 4GB RAM and haven't got anything running in the background. My SWAP-partition has 8gb.
Linux audio drivers don't seem to like my onboard soundchip too much and I can't use the full 5.1 output with it, only Stereo, although I guess there's always a way to configure alsa in some way that it works, I never managed to do this with pulse.

Hmm, I don't think that should be a problem. pulse sits on alsa, so if it doesn't work on alsa it probably won't work on pulse either. In fact it's more complicated than that, since distros tend to have alsa configured to circulate its output through pulse for software mixing even if the applications are talking directly to it. This being the case it's probably better for the applications to speak directly to pulse if they can. Wine can't, wine-staging can.. nut I don't know if that has anything to do with your problem, the state of audio on Linux is just quite the tangled mess.

Can you play midi files through fluidsynth with pmidi and do they suffer from the same problem?

I can play midi files well with all programs anyway since I've got timidity installed, but for some reason it didn't work with Wine, that's why I've installed fluidsynth in the first place.

I don't know pmidi or the commands, I'm not too fluent on terminal stuff and it doesn't seem to have a gui.

I've been getting awful performance running SS via Wine, lots of lag and distorted sound. So I've used the classic edition in dosbox with the mouselook patch instead where the performance has been decent. But today I found out that setting SoftRenderer=On in sshock.ini in the game dir fixes the performance issues with the enhanced edition for me. It worked ok in dosbox, but it works even better via Wine now, together with the sound fixes already discussed in this thread. So if anyone has any performance issues using Wine, try turning on software rendering.

Thanks, your solution worked perfectly!