Implementing ALSA compatibility in OSS

Implementing ALSA compatibility in OSS

[Hannu Savolainen]

Hi folks!

We are considering making our OSS software compatible with ALSA. However
there are some serious problems. Maybe somebody on this list could give us
some initial help.

Our initial plan was to implement a version of libasound.so that
implements the required functionality in OSS way. However the problem is
that there are more than 1500 snd_* functions exported by libasound.so
(of alsa-lib-1.0.7rc2). How many of them are actually needed and how many
of them are just helpers used internally by the library.

After checking about 10 or 20 different applications we have found about
220 different routines that have been used by them. In addition there
are 90 routines used by amixer/alsamixer we have decided to leave
unimplemented. Each new program we try adds about 10 to 20 new routines to
the set.

There are about 1200 calls we have not "seen" yet. At this rate we will
need to try at least 60 to 120 programs before we know how many ALSA
routines need to be implemented for good ALSA compatibility. However
it looks like we are running out of programs. Many apps on the applications
list (http://www.alsa-project.org/applications.php) seem to have been
updated last tame in 2002 and they don't work with ALSA 1.0.x any more. Is
this list up to date or do we have just looked at a wrong place.

Is there any other official documentation for the pcm and mixer
interfaces in addition to the DOXYGEN stuff? It's mostly just a function
prototype list and not very helpfull.

Btw, the "Howto use the ALSA API" document
(http://equalarea.com/paul/alsa-audio.html) contains three sample programs
for audio but they are bit out of date. The
snd_pcm_hw_params_set_rate_near() call seems to use some older parameter
passing convention and they don't work with ALSA 1.0.x. Maybe somebody
should fix them.

Is the ALSA library API frozen now or should we wait until the 2.0
version to avoid doing redundant work?

Another alternative is making OSS compatible with the ALSA's device driver
interface /dec/snd/*. This would be the most natural alternative. Is there
any documentation written for it (nothing seems to be available in the net)?


Third alternative might be improving the OSS plugin for Jack. After
browsing the ALSA web site it looks like many pages recommend using Jack
instead of the ALSA library API. However are there any reasons to
implement a new version of libasound.so instead of improving the Jack
plugin?


Anyway we will include a mimimal "Simple ALSA" (SALSA) library in the next
OSS version (in few days) that permits running selected ALSA applications
(mainly esd, xmms and alsaplayer). This is needed because many Linux
distributions have compiled them with OSS support disabled. The first
version of this library implements about 20 or 30 ALSA library routines.
In addtion there are about 200 "stub" routines required to make the loader
happy. The remaining 1300 calls don't have even stubs yet so we do not
claim having full ALSA support yet.

Best regards,

Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Implementing ALSA compatibility in OSS

[Peter Zubaj]

Hi,

I am not alsa-developer, but:

Would be simpler and faster to implement only alsa-lib plugin as whole
alsa-lib (I never tryed this) ????

And if you create new alsalib (SALSA) you will overwrite old one -
this will prevent ussage of both sound systems at same time.
For example soundcard 1 uses ALSA and sound card 2 uses OSS.

Look at pcm_jack.c (from alsa-lib) - this plugin implements output to
jack from every alsa app (I think).

I think API is stable, but I think kernel api can be changed, because
these changes will be hiden in alsa-lib.

Peter Zubaj

____________________________________
http://www.pobox.sk/ - spolahliva a bezpecna prevadzka





-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Implementing ALSA compatibility in OSS

[Hannu Savolainen]

On Mon, 15 Nov 2004, Peter Zubaj wrote:

> Hi,
>
> I am not alsa-developer, but:
>
> Would be simpler and faster to implement only alsa-lib plugin as whole
> alsa-lib (I never tryed this) ????
That might be one option.

> And if you create new alsalib (SALSA) you will overwrite old one -
> this will prevent ussage of both sound systems at same time.
> For example soundcard 1 uses ALSA and sound card 2 uses OSS.
There is no such problem. This library is not for OSS/Free. Our retail
version of OSS cannot be used at the same time with the ALSA drivers
anyway so there are no problems.

Best regards,

Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Implementing ALSA compatibility in OSS

[Hannu Savolainen]

On Mon, 15 Nov 2004, Peter Zubaj wrote:

> Would be simpler and faster to implement only alsa-lib plugin as whole
> alsa-lib (I never tryed this) ????

> Look at pcm_jack.c (from alsa-lib) - this plugin implements output to
> jack from every alsa app (I think).
This approach sounds interesting. Unfortunately my impression after
looking at the code is that the plugin interface only works with PCM. Also
the library seems to be build tightly around ALSA kernel drivers and
taking ALSA's place as the "hardware" driver (for the default and hw:*
devices). However it would be be interesting to hear what ALSA's
developers say about this.

Best regards,

Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Implementing ALSA compatibility in OSS

[Peter Zubaj]

>This approach sounds interesting. Unfortunately my impression after
>looking at the code is that the plugin interface only works with PCM.
>Also
>the library seems to be build tightly around ALSA kernel drivers and
>taking ALSA's place as the "hardware" driver (for the default and hw:*
>devices).

AFAIK every interface (control, pcm, midi, ...) in alsa can have it's
own plugins. These plugins can be compiled in lib and load at runtime
through .asoundrc file. I think, it is possible to even create virtual
user space soundcard. Only compilation depends on internal alsa-lib
heades (*_local.h) and on kernel asound.h file.
And these local headers can change at any time without warning.

But you should check LICENSE if you can use internal alsa-lib headers
and asound.h header.

If you implement your own alsa-lib you will be always one (or more)
step behind ALSA, and it will cost you too much. And missing functions
implementations can by problems too.

Peter Zubaj
____________________________________
http://www.pobox.sk/ - spolahliva a bezpecna prevadzka





-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Implementing ALSA compatibility in OSS

[Clemens Ladisch]

Hannu Savolainen wrote:
> We are considering making our OSS software compatible with ALSA.
> Our initial plan was to implement a version of libasound.so that
> implements the required functionality in OSS way.

The plugin interface is there to avoid having to (re)implement most of
libasound.

All device types (pcm/rawmidi/ctl/seq/hwdep/timer) are implemented
using plugins, although most of them have only a plugin named "hw" for
the kernel driver.

> However the problem is that there are more than 1500 snd_*
> functions exported by libasound.so (of alsa-lib-1.0.7rc2). How
> many of them are actually needed and how many of them are just
> helpers used internally by the library.

Many of the xxx_set/get_yyy functions are just accessors for the yyy
field of the (internal) xxx structure, to make the libray binary
compatible if the structure changes.

A plugin has to implement much less functions (see pcm_null.c for a
simple example).

> Is there any other official documentation for the pcm and mixer
> interfaces in addition to the DOXYGEN stuff?

Unfortunately, no.  The plugin interface isn't documented at all.

> Is the ALSA library API frozen now or should we wait until the 2.0
> version to avoid doing redundant work?

I don't know of any plans to make (big) changes.

> Another alternative is making OSS compatible with the ALSA's device driver
> interface /dec/snd/*.

This is an internal interface (that will change in future versions).

> Is there any documentation written for it (nothing seems to be
> available in the net)?

Of course not, otherwise people would try to use it. ;-)
(Unfortunately, sox does.)

> Third alternative might be improving the OSS plugin for Jack. After
> browsing the ALSA web site it looks like many pages recommend using Jack
> instead of the ALSA library API. However are there any reasons to
> implement a new version of libasound.so instead of improving the Jack
> plugin?

This depends on whether you want to be compatible with ALSA programs
not using Jack.  Usually, non-'professional' application don't use
Jack.


Clemens



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Implementing ALSA compatibility in OSS

[Hannu Savolainen]

On Mon, 15 Nov 2004, Clemens Ladisch wrote:

> The plugin interface is there to avoid having to (re)implement most of
> libasound.
>
> All device types (pcm/rawmidi/ctl/seq/hwdep/timer) are implemented
> using plugins, although most of them have only a plugin named "hw" for
> the kernel driver.
Ok. This sounds promising.

> > Is there any other official documentation for the pcm and mixer
> > interfaces in addition to the DOXYGEN stuff?
>
> Unfortunately, no.  The plugin interface isn't documented at all.
Any chance that it gets documented in the near future? I guess no.

> > Another alternative is making OSS compatible with the ALSA's device driver
> > interface /dec/snd/*.
>
> This is an internal interface (that will change in future versions).
>
> > Is there any documentation written for it (nothing seems to be
> > available in the net)?
>
> Of course not, otherwise people would try to use it. ;-)
> (Unfortunately, sox does.)
Hmm. Isn't this some kind of waste of natural resources?

OSS is a driver API and it's definitely designed to be used directly.
Maybe alsa-lib could be implemented on top of the OSS driver API instead
of having two redundant APIs in the kernel. The draft for current OSS API
specification is available at http://www.fi.opensound.com/developer . We
could also consider donating core parts of OSS to the kernel (under GPL)
if there is any interest to it (no promises however).


> This depends on whether you want to be compatible with ALSA programs
> not using Jack.  Usually, non-'professional' application don't use
> Jack.
Right. They usually use the OSS API directly.

Best regards,

Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Implementing ALSA compatibility in OSS

[Jaroslav Kysela]

On Mon, 15 Nov 2004, Hannu Savolainen wrote:

> OSS is a driver API and it's definitely designed to be used directly.

It's (and was) a broken idea. We have never ending trouble to reroute your
API to ours, because you have not designed a proper library in the user
space to handle application requests. While you can use alsa-lib to 
reroute ALSA apps to the OSS driver, we have no such simple way for ALSA 
-> OSS path. We must do an emulation in the kernel side or use some hacks 
to do proper rerouting.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Implementing ALSA compatibility in OSS

[Clemens Ladisch]

Hannu Savolainen wrote:

> On Mon, 15 Nov 2004, Clemens Ladisch wrote:
>
> > The plugin interface isn't documented at all.
> Any chance that it gets documented in the near future? I guess no.

Properly documenting the application interface has priority.  (Which
doesn't say much as long as neither one is being done.)

> > > Another alternative is making OSS compatible with the ALSA's device driver
> > > interface /dec/snd/*.
> > > Is there any documentation written for it (nothing seems to be
> > > available in the net)?
> >
> > Of course not, otherwise people would try to use it. ;-)
>
> Hmm. Isn't this some kind of waste of natural resources?

The purpose of having alsa-lib is that things like sample format/rate
conversion, virtualization, software synths, replacement drivers like
Jack etc. can be done in user space.  We either do not want or cannot
do this in kernel space.

> Maybe alsa-lib could be implemented on top of the OSS driver API instead
> of having two redundant APIs in the kernel.

AFAICS the ALSA API is a superset of the OSS API.


Best regards,
Clemens



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Implementing ALSA compatibility in OSS

[Hannu Savolainen]

On Mon, 15 Nov 2004, Jaroslav Kysela wrote:

> On Mon, 15 Nov 2004, Hannu Savolainen wrote:
>
> > OSS is a driver API and it's definitely designed to be used directly.
>
> It's (and was) a broken idea. We have never ending trouble to reroute your
> API to ours, because you have not designed a proper library in the user
> space to handle application requests.
Interesting point. Do you mean that all Linux drivers for whatever devices
should have defined their own library interface instead of the using the
traditional Unix device/file interface?

To me this uniform and robust device/file abstraction was the main reason
to get married with Unix. That happened exactly 20 years ago, btw. It was
also the reason why I originally designed OSS in this way.

OSS doesn't have it's own library API. Our goal has been to develop  as
good device drivers as possible and nothing else. As a small company have
intentionally left all user space development (including libraries) to
others.

> While you can use alsa-lib to
> reroute ALSA apps to the OSS driver, we have no such simple way for ALSA
> -> OSS path. We must do an emulation in the kernel side or use some hacks
> to do proper rerouting.
Such is life.

Best regards,

Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Implementing ALSA compatibility in OSS

[Hannu Savolainen]

On Mon, 15 Nov 2004, Clemens Ladisch wrote:

> The purpose of having alsa-lib is that things like sample format/rate
> conversion, virtualization, software synths, replacement drivers like
> Jack etc. can be done in user space.  We either do not want or cannot
> do this in kernel space.
But why does this need to be done in alsa-lib? Jack is also a library.

> > Maybe alsa-lib could be implemented on top of the OSS driver API instead
> > of having two redundant APIs in the kernel.
>
> AFAICS the ALSA API is a superset of the OSS API.
Right. 1500+ library calls is really a superset of OSS API that has just
5 system calls and a handfull of ioctl calls. OSS is designed to make
the right decisions itself without babysitting by the applications. With
ALSA you check what the device can do. With OSS you simply tell the device
what it should do. In that way we need just a fraction of primitives for
the same functionality.

Best regards,

Hannu
-----
Hannu Savolainen (hannu@opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Implementing ALSA compatibility in OSS

[Takashi Iwai]

At Mon, 15 Nov 2004 19:31:23 +0200 (EET),
Hannu Savolainen wrote:
> 
> On Mon, 15 Nov 2004, Jaroslav Kysela wrote:
> 
> > On Mon, 15 Nov 2004, Hannu Savolainen wrote:
> >
> > > OSS is a driver API and it's definitely designed to be used directly.
> >
> > It's (and was) a broken idea. We have never ending trouble to reroute your
> > API to ours, because you have not designed a proper library in the user
> > space to handle application requests.
> Interesting point. Do you mean that all Linux drivers for whatever devices
> should have defined their own library interface instead of the using the
> traditional Unix device/file interface?

It depends.  Accessing to the device file would make sense for many
simple devices, but not for the devices with wide variety.

The problem of the direct device access is that it restricts the
extension of the API.  It can never exceed the limitation of the
kernel.  That is, you can't use floating point in the lowlevel
(i.e. system level) layer.


> To me this uniform and robust device/file abstraction was the main reason
> to get married with Unix. That happened exactly 20 years ago, btw. It was
> also the reason why I originally designed OSS in this way.
> 
> OSS doesn't have it's own library API. Our goal has been to develop  as
> good device drivers as possible and nothing else. As a small company have
> intentionally left all user space development (including libraries) to
> others.

I see your point.  I would say it's a different design decision.

For example, the current design of ALSA lib isn't well suitable for
the embedded system.  It's because we wanted to have a powerful and
extensible middle layer which can be used uniquely by apps.  For the
tiny systems, OTOH, it's too bold.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Implementing ALSA compatibility in OSS

[Takashi Iwai]

At Mon, 15 Nov 2004 19:58:34 +0200 (EET),
Hannu Savolainen wrote:
> 
> On Mon, 15 Nov 2004, Clemens Ladisch wrote:
> 
> > The purpose of having alsa-lib is that things like sample format/rate
> > conversion, virtualization, software synths, replacement drivers like
> > Jack etc. can be done in user space.  We either do not want or cannot
> > do this in kernel space.
> But why does this need to be done in alsa-lib?

Because we can provide a uniform API with that.
Each app doesn't have to take care of the whole such stuff.


> > > Maybe alsa-lib could be implemented on top of the OSS driver API instead
> > > of having two redundant APIs in the kernel.
> >
> > AFAICS the ALSA API is a superset of the OSS API.
> Right. 1500+ library calls is really a superset of OSS API that has just
> 5 system calls and a handfull of ioctl calls.

The ALSA "kernel" API is also not too bigger than that.

As Clemens explained, most of lib calls are accesors to the opaque
struct fields (imagine C++).  (Don't discuss further about the sense
of this implementation here at this point.  You're too late on the
stage for the definition of 1.0 API :)


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Implementing ALSA compatibility in OSS

[Paul Davis]

>> It's (and was) a broken idea. We have never ending trouble to reroute your
>> API to ours, because you have not designed a proper library in the user
>> space to handle application requests.
>Interesting point. Do you mean that all Linux drivers for whatever devices
>should have defined their own library interface instead of the using the
>traditional Unix device/file interface?

No, Jaroslav doesn't mean that and you know it. But take a look at
video devices for a comparison. There is almost no application for any
Unix system that accesses the video device directly. X, libsvga (or
whatever its called), OpenGL ... video programs use abstractions that
are supported by libraries that sit on top of device drivers.

And there very good reasons for this - many manufacturers of
frequently incompatible hardware, often designed around quite
different h/w models. As soon as we moved away from VGA-style video
(the audio equivalent, of course, being the soundblaster), everybody
on every OS i can think of moved to video access via a library. 

--p


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Implementing ALSA compatibility in OSS

[Jaroslav Kysela]

On Mon, 15 Nov 2004, Takashi Iwai wrote:

> For example, the current design of ALSA lib isn't well suitable for
> the embedded system.  It's because we wanted to have a powerful and
> extensible middle layer which can be used uniquely by apps.  For the
> tiny systems, OTOH, it's too bold.

It's not true. We can allow to remove not used code. I plan to shrink
library for these devices. It's not a big problem.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Implementing ALSA compatibility in OSS

[Takashi Iwai]

At Mon, 15 Nov 2004 20:58:47 +0100 (CET),
Jaroslav wrote:
> 
> On Mon, 15 Nov 2004, Takashi Iwai wrote:
> 
> > For example, the current design of ALSA lib isn't well suitable for
> > the embedded system.  It's because we wanted to have a powerful and
> > extensible middle layer which can be used uniquely by apps.  For the
> > tiny systems, OTOH, it's too bold.
> 
> It's not true. We can allow to remove not used code. I plan to shrink
> library for these devices. It's not a big problem.

Read the word "current".

Your plan is exactly what I have, too :)


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Implementing ALSA compatibility in OSS

[Jaroslav Kysela]

On Tue, 16 Nov 2004, Takashi Iwai wrote:

> At Mon, 15 Nov 2004 20:58:47 +0100 (CET),
> Jaroslav wrote:
> > 
> > On Mon, 15 Nov 2004, Takashi Iwai wrote:
> > 
> > > For example, the current design of ALSA lib isn't well suitable for
> > > the embedded system.  It's because we wanted to have a powerful and
> > > extensible middle layer which can be used uniquely by apps.  For the
> > > tiny systems, OTOH, it's too bold.
> > 
> > It's not true. We can allow to remove not used code. I plan to shrink
> > library for these devices. It's not a big problem.
> 
> Read the word "current".
> 
> Your plan is exactly what I have, too :)

Fine. Sorry ;-)

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8