Re: WINE and ASIO

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Message: 1
Date: Mon, 25 Sep 2006 15:50:23 -0400
From: Dave Phillips <dlphillips@xxxxxxxxxx>
Subject: Re:  WINE and ASIO
To: A list for linux audio users <linux-audio-user@xxxxxxxxxxxxxxxxxx>
Message-ID: <451832FF.80801@xxxxxxxxxx>
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

[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux