Am 19.04.2013 00:02, schrieb Michael Mol: > On 04/18/2013 05:46 PM, Volker Armin Hemmann wrote: >> Am 18.04.2013 23:10, schrieb Michael Mol: > [snip] > >>> Do you say that because you've tested the various orders and know >>> that one application will not conflict with another if started >>> before that, or do you say that because you've never noticed a >>> problem, despite not knowing the order you've started things? >> because I am using linux since Suse 6.2. And in that time I have >> listened to a lot of music, watched a lot of movies and did a lot of >> things in parallel. Just yesterday I watched a music video on >> youtube, while hunting for something sounding almost identical on my >> harddisk - using vlc. So firefox&flash and vlc were working fine. > I know you're smarter than this. You actively ignored my explicit > description of a testable sequence of steps. Which Hartmut specifically > tried, and in doing so that the problem I encountered is not currently > present. > > By ignoring the sequence of steps, you're left with, well, nothing > testable or verifiable.
I have answered your none-question. I am using a wide range of applications (firefox&flash, chromium, vlc, mplayer, alsaplayer etc pp) a lot of them at the same time, starting in different orders AND I NEVER HAD A PROBLEM. It does not matter if flash starts first, then vlc then alsaplayer then mplayer or chromium first, then xine then firefox. IT JUST WORKS. The only thing missing is wine. Hmm... maybe it IS wine? But why using a broken-by-design sounddaemon to paper over wine bugs, if there are a couple of easy ways to solve the problem once and for all? Without introducing lag and additional bugs. ie - fix wine. Or don't use it in the first place. >>>> I don't use wine. For a lot of good reasons. >>>> >>> Name one. >>> >> fat, slow and buggy. Do you need more? > Not from you, I suspect. At this point, I'm confident you have > absolutely no idea what you're talking about. > > By "fat", I suppose you're referring to the number of additional > binaries that land on your system. If you're going to implement the > entire API of an operating system, even as a wrapper around native > libraries, you're going to have a lot of code. That's just the way it is. No, by fat I mean its absolute humongous size. The crap its vomits into my $HOME adds just insult to injury. > > As for "slow"...it's been documented from time to time that some > applications run *faster* via WINE than on Windows. On one occasion, > this was the result of the Linux drivers being faster than the Windows ones. well, from time to time I try wine with this and that app. Speed? Abysmal - if the app works at all. Btw, who is doing that 'documentation'? Phoronix? > > As for "buggy"...Sure, not all of the APIs are implemented. Not all of > them need to be. Bugfixes and such are prioritized by interest in the > applications which need the buggy APIs, which is why many applications > work fine. Heck, I have an application installed which *depends* on > WINE, and this is part of that application's "Linux" version. I use it > every day as part of my job, and so I can do my job from this laptop > running Gentoo instead of a machine running Windows. great for you. AT WORK I just use the XP box to do windows jobs. At the end it is so much easier. > >> If I really had an application that I must use and is windows only - >> I would install windows. That is a lot quicker and less painful than >> that wine crapfest shitting all over the place. > ...The worst I've had has been WINE apps getting registered to handle > some files. Unless you're referring to the idea that WINE was what was > breaking my sound (itself clearly erroneous if you had read through the > description of either my or Hartmut's steps), I really don't know what > you're talking about, and I fear I'm just feeding a troll. And I am afraid that you are just talking because you like the sound of your voice. What was your point again?
