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

>
> Message: 1
> Date: Mon, 25 Sep 2006 15:50:23 -0400
> From: Dave Phillips <dlphillips@email-addr-hidden>
> Subject: Re: [linux-audio-user] WINE and ASIO
> To: A list for linux audio users <linux-audio-user@email-addr-hidden>
> Message-ID: <451832FF.80801@email-addr-hidden>
> 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
Received on Tue Sep 26 12:15:03 2006