[linux-audio-user] Re: WINE and ASIO

[Stéphane Letz]

>
> Message: 1
> Date: Mon, 25 Sep 2006 15:50:23 -0400
> From: Dave Phillips <dlphillips at woh.rr.com>
> Subject: Re: [linux-audio-user] WINE and ASIO
> To: A list for linux audio users <linux-audio-user at music.columbia.edu>
> Message-ID: <451832FF.80801 at woh.rr.com>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> Dave Phillips wrote:
>
>> FM7 still looks like it's working, but I still get no audio from  
>> it. :(
>
> Scratch that. For some reason the master volume gets set to 0 for each
> patch.
>
> Demudi 1.3 Debian Etch, kernel 2.6.15 (homebrew)
> WINE 0.9.21 patched for ASIO support.
> WineCfg audio/MIDI set for ALSA.
> JACK period size set to 1024 to accommodate apps' recommended ASIO  
> setting.
> Audio and MIDI work nicely. I loaded a MIDI file demo, and I played  
> the
> synth from an external MIDI keyboard.
>
> Potential interest should be modulated by the capabilities of Robert's
> driver. Currently it supports only two channels and doesn't
> self-configure via JACK (buffersize is hard-coded at 1024). Also, I
> don't know how much more work Robert will put into the project. But  
> the
> code is there, it's a good start, and it works.
>
> Best,
>
> dp
>


I think ideas (maybe code...)  could be shared with similar projects  
that also does Jack <==> some other audio API connections, that is  
JackOSX/JackRouter that does the Jack <==> CoreAudio bridge on OSX  
and the ASIO JackRouter driver, part of jack on Windows implementation.

- on both projects there is a notion of "virtual channel", basically  
the number of audio channels (that actually correspond internally to  
real jack ports) can be different from the number of jack ports the  
real hardware supports. This way jackified applications can use these  
additional audio channels to route whatever they need. This number of  
virtual channels typically needs to be managed in a global setup with  
a shared state visible by all jackified applications.

- saving/restoring jack ports connections state: any Jack <==> some  
other audio API bridge has to map the jack client life cycle on the  
other audio API  life cycle, so that each jack API call would  
correspond to one of the other audio API call. Although this mapping  
usually works well with most applications, one may have some that  
behave a bit stangely: for example jackified Max/MSP typically  
register a jack client the first time the DSP is set to on, but only  
*deactivate/reactivate* the jack client with its DSP is later set up  
off/on. When desactivated the jack client still appears in a  
connection tool, but cannot be connected anymore: when setting the  
DSP to on, the previous state of jack connection is just lost.
In this case having an automatic saving/restoring jack ports  
connections state inside the bridge is very convenient....

Regards,

SL