seg fault is in wine-pthread, not wine-preloader, which is even tougher
- two exec boundaries to cross.
i am building ardour (http://ardour.org) as a win32 executable to allow
us to continue using win32 DLL's as plugins.
when i run the result with wine, i get a segfault long before control
has been transferred to my code. it appears to be in wine-preloader
(based on what "file core." says).
i c
>I don't understand you. We are discussing a problem in the wineoss sound
>backend. This backend interfaces with the OSS API. Are you saying Wine's
>OSS backend should use Alsa???
OK, that wasn't clear from the initial context of the
discussion. Sorry, I missed it. Ignore me then.
>Hmm, the specs don't actually say that opening RDWR only works
Warning - basing this on the OSS API is probably a mistake. Although
ALSA supports the OSS API, its also preferable to use the ALSA API for
a variety of reasons, most of them related to interoperability with
different audio interfaces
>I really feel that yes we should support Wine as a library, and that means
>making the APIs we export stable ASAP. I especially think we should stop
I don't think this is necessary. The functionality that Wine offers is
significant enough that developers like myself and Torben (I don't
know about
>>Once again how can you fuss about unstable interfaces on a project that
>>does not have a stable release? You could work with Winehq to create
>>those stable interfaces.
PDB might not be able to fuss, but I will. I recently asked about a
way to figure out which version of Wine is in use at run-t
>Mike Hearn <[EMAIL PROTECTED]> writes:
>
>> Paul Davis of Ardour has raised a good point: currently despite the fact
>> that the symbols in libwine are versioned, we change them at will and
>> don't change the symbol version, for instance in the patch tha
>Finally, apparently Paul has had to duplicate a fair amount of Wine code
>inside his libfst (library for loading Cubase VST plugins) because the
>relevant functions are declared static in Wine. Paul, could you post a
>list of exactly what you use?
actually, a "fair amount" is an overstatement. it
>My original question generated this new thread, which in turn became
>very technical. But, I think that Paul's original posting was more of
>a philosophical or maybe even moral nature.
[ ... ]
>If questions relating to a commercial non open source product that uses
>wine heavily are not we
>> for this reason, i personally wouldn't feel comfortable asking in a
>> public forum how to go about doing this. your mileage may and probably
>> does vary, of course.
>
>Well, if I could clearly predict ELF linker behaviour with several
>different modules each having global variables/functions w
i'd just like to mention a small concern i have.
hiding symbols might well be a perfectly honest thing to want to do. i
personally can't see why, since a list of symbol names doesn't provide
much extra help to somebody who wants to disassemble and reverse
engineer your code. but i can understand t
>> I think winmm should work over directsound ok. I just need to look into
>> what ASIO does now.
>
>I think ASIO loads kernel drivers and bypasses the whole thing.
ASIO is a vastly superior API for audio programming. Its too bad that
Windows doesn't support it as the standard. It would be really
>> However, later on we need our kernel to run as a real time task by means
>> of RTAI, and we don't know if that is even possible with Wine/Winelib.
>> Anybody knows if such a thing is possible?
>
>What is RTAI? Realtiming a task in Linux is certainly possible but you
>need to be root to do it. I'
>On Wed, 21 Apr 2004 21:06:22 -0400, Paul Davis wrote:
>> if the freedesktop people have any intent of avoiding a split between
>> the music world and the "desktop beep" world, JACK is the only viable
>> sound server. if they don't care about such a split,
>The issues with arts and esd are that by their very design they are unsuitable
>for professional audio use. Its easier to add things to the lower latency
>design of jack than it is to improve the latency of blocking io apps like
>arts and esd.
to reinforce Chris' point: *no* significant linux
I offer this for Alexandre and other's consideration and
comments. This is already in use in libfst, which is in turn used by
Ardour, a native linux digital audio workstation, and gAlan, a native
linux modular synthesis system.
There is still no proper cleanup on failure, and nothing is done if
th
>What I think was being asked if you could use Winelib to build a native
>linux application
>that just uses wine for libraries (similar to gtk and other libs). In the
>case of wine your
>executable becomes a library which needs to be run by wine. Further you need
>other wine
>stuff (registry set
>On Tue, 06 Apr 2004 11:25:13 -0400, Dimitrie O. Paun wrote:
>> But this, I'm afraid, besides the point. This entire discussion assumes
>> that the Win32 windows are mapped to X windows. If IIRC, Alexandre was
>> saying that we need to switch back to the old ways, where we handle most
>> of the win
(this is for review by people who know better than me :)
[ some functions are replaced here by lower case versions
because this code is not part of dlls/ntdll/thread.c.
consequently, we have to dlopen() that library,
and dlsym() the functions we need. if this ever makes
it into Wine, this
>The intermediate buffering is the issue. It's not a real big issue
>now with only a single buffer but it will be when wine supports
>hardware accelerated secondary buffers. You don't want 32 or
>64 streams of data each going through multiple intermediate
>buffers for SRC, format, and volume chan
>I believe it makes sense for wine to keep the oss and alsa
>drivers as low level as possible for users that require performance
>over useability. The straight to hardware philosophy of direct sound
>should be honored when possible. This would be appropriate for
>games, voip or low latency music ap
>Where do you have your code public so we can download it?
nowhere yet. there will be a tarball available within the next 36hrs,
probably at ardour.org. i'll let you know.
--p
>mike already fixed a bunch of my misunderstandings on IRC. but now
>i'm faced with the more challenging task of getting this "mono hack"
>to support threading properly. so feedback is still welcome :)
its turns out that the "mono hack" in which threading is know not to
work is broken in at least
mike already fixed a bunch of my misunderstandings on IRC. but now
i'm faced with the more challenging task of getting this "mono hack"
to support threading properly. so feedback is still welcome :)
--p
hello. i'm the main author of Ardour and JACK, projects those of you
with audio/music leanings may be aware of. i'm in the middle of trying
to add "native" windows/x86 VST plugin support to these systems, and
i ran into some problems. #winehackers suggested to write this list.
we are using a modif
25 matches
Mail list logo
