Re: [Jack-Devel] Jack-Devel Digest, Vol 71, Issue 22

PrevNext  Index
DateThu, 24 May 2012 21:20:35 +0100
From Peter L Jones <[hidden] at drealm dot info>
To[hidden] at jackaudio dot org
In-Reply-ToSteve Schow Re: [Jack-Devel] Jack-Devel Digest, Vol 71, Issue 22
Hi Steve,

Great to hear you're willing to give it a shot at getting it going.  It would
be good to have wineasio be cross-platform.  A 64-bit build would be good too...

If you have a poke around on the SourceForge project, you'll find several
different versions of the code and in the SVN tree they're pretty neatly laid
out.  This does, IIRC, include different approaches to locking.  I think that's
also one of the things jhernberg was looking at in his refactoring.

I'm hoping Real Life (tm) will at some point give me time to spend catching up
with where we are on wineasio/JackWASIO/JackRouter (which is the native Windows
ASIO to JACK driver).  I'm so out of the loop, I can't do much more than watch
the project at the moment!

Thanks,

-- Peter

On 20/05/2012 18:37, Steve Schow wrote:
> 
> Thanks a lot for responding Peter.  
> 
> Yes I have tried JackWASIO.  Actually I have the original binary that is 4 years old, its not posted anywhere on the web anymore.  His src is on the JackOSX code repository and I recently also managed to build it successfully on Snow Leopard, after some tweaks to the Makefile.
> 
> However JackWASIO does not support more than 2 ASIO outputs.  I tried messing around with the code a bit for an evening to see if I could enable more outputs, not really knowing what I was doing in terms of ASIO or Jack programming, and I was able to get more outputs to show up under one app, but not under Reaper, I don't know, something was missing obviously.  The code in JackWASIO was obviously hacked together in a way to get it working fast, its not very well organized code, I found a few things that didn't make sense to me, when comparing it with the wineasio code.  But I really have to learn more about the ASIO and jackd SDK's before I an tackle this.
> 
> Since that time I read up about the Jackd SDK and I've decided that there is probably no reason why I can't take the real current wineasio codeline and bulid it for OSX.  I read somewhere from the author of JackWASIO that the main problem with it before was the use of semaphores or shared memory or some such thing, which was a conflict between linux and BSD.  Something like that.  Its been a few years since I read it, I can't remember now what it was.  Wineasio has been refactored since then, so perhaps it can now be made to work on OSX too.
> 
> Wineasio is more up to date and over time that codeline will be getting general improvements related to midi perhaps and synchronization.  It would really be a lot better for the OSX community if we can somehow benefit from that ongoing progress instead of just using this 4 year old JackWASIO code that nobody is interested in improving(except perhaps me).  
> 
> Either that or I will totally refactor the JackWASIO code myself, based more on the way wineasio works, but my time is limited to work on such things.  Just poking around in wineasio and JackWASIO, I can see that wineasio has been refactored a lot to use Jack's SDK differently.  I have to learn more to understand why or how its different.  
> 
> 
> 
> In any case, I was taking a stab at compiling existing wineasio on osx to see where I get and this macro stuff in the start of asio.c is blocking progress.  its a bit over my head, but basically its some assembler injections to deal with COM and function pointers somehow.  I get the feeling this is a common wine development issue, but I can't be sure.  Its something I don't really understand (yet), but whatever they did in wineasio is not compatible with the OSX compiler/assember (which is not ELF).   When I get some time my next step will be to compare the COM assembler injections in JackWASIO and I'll try to bring that back to wineasio to see if I can get it to work, but maybe one of you guys knows helpful info.
> 
> 
> On May 20, 2012, at 6:28 AM, [hidden] wrote:
>>
>>
>> Date: Sun, 20 May 2012 13:12:48 +0100
>> From: Peter L Jones <[hidden]>
>> To: [hidden]
>> Subject: Re: [Jack-Devel] Wineasio on OSX
>> Message-ID: <jpan40$dd0$[hidden]>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Hi Steve,
>>
>> Have you tried JackWASIO?
>>
>> -- Peter
>>
>> On 15/05/2012 20:57, Steve Schow wrote:
>>> I'm trying to build wineasio 0.90 on osx.  So far can't get past some ELF assember code injection which I believe is a work around for COM.  Somehow whatever is in wineasio's asio.c file is not compatible with Mac.  Anyone have an idea how I might fix this?
>>>
>>> Here is the compiler error and below that the code I think causing the problem:
>>>
>>> Error:
>>>
>>> gcc -c -I. -I/usr/include -I/Users/sjs/wine/wine-1.5.4/include -I/Users/sjs/wine/wine-1.5.4/include/wine -I/Users/sjs/wine/wine-1.5.4/include/wine/windows    -m32 -g -O2 -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -o asio.o asio.c
>>> {standard input}:36:Unknown pseudo-op: .type
>>> {standard input}:36:Rest of line ignored. 1st junk character valued 95 (_).
>>> {standard input}:38:Unknown pseudo-op: .cfi_startproc
>>> {standard input}:43:Unknown pseudo-op: .cfi_endproc
>>> {standard input}:44:Unknown pseudo-op: .previous
>>> {standard input}:48:Unknown pseudo-op: .type
>>>
>>>
>>> Code:
>>>
>>> /* ASIO drivers (breaking the COM specification) use the Microsoft variety of
>>> * thiscall calling convention which gcc is unable to produce.  These macros
>>> * add an extra layer to fixup the registers. Borrowed from config.h and the
>>> * wine source code.
>>> */
>>>
>>> /* From config.h */
>>> #define __ASM_DEFINE_FUNC(name,suffix,code) asm(".text\n\t.align 4\n\t.globl " #name suffix "\n\t.type " #name suffix ",@function\n" #name suffix ":\n\t.cfi_startproc\n\t" code "\n\t.cfi_endproc\n\t.previous");
>>> #define __ASM_GLOBAL_FUNC(name,code) __ASM_DEFINE_FUNC(name,"",code)
>>> #define __ASM_NAME(name) name
>>> #define __ASM_STDCALL(args) ""
>>>
>>> /* From wine source */
>>> #ifdef __i386__  /* thiscall functions are i386-specific */
>>>
>>> #define THISCALL(func) __thiscall_ ## func
>>> #define THISCALL_NAME(func) __ASM_NAME("__thiscall_" #func)
>>> #define __thiscall __stdcall
>>> #define DEFINE_THISCALL_WRAPPER(func,args) \
>>>    extern void THISCALL(func)(void); \
>>>    __ASM_GLOBAL_FUNC(__thiscall_ ## func, \
>>>                      "popl %eax\n\t" \
>>>                      "pushl %ecx\n\t" \
>>>                      "pushl %eax\n\t" \
>>>                      "jmp " __ASM_NAME(#func) __ASM_STDCALL(args) )
>>> #else /* __i386__ */
>>>
>>> #define THISCALL(func) func
>>> #define THISCALL_NAME(func) __ASM_NAME(#func)
>>> #define __thiscall __cdecl
>>> #define DEFINE_THISCALL_WRAPPER(func,args) /* nothing */
>>>
>>> #endif /* __i386__ */
>>>
>>> /* Hide ELF symbols for the COM members - No need to to export them */
>>> #define HIDDEN __attribute__ ((visibility("hidden")))
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> 
>> Jack-Devel mailing list
>> [hidden]
>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>>
>>
>> End of Jack-Devel Digest, Vol 71, Issue 22
>> ******************************************
PrevNext  Index

1337890875.16459_0.ltw:2, <jpm56r$iq$1 at dough dot gmane dot org>