[Alsa-user] OPL chip direct usage

[Ryan U. <nem...@ic...>]

It is possible to use a OPL chip through direct FM interface, but
unfortunately, I am writing a library which needs direct access to the
OPL registers.  It is always possible to just use port I/O or /dev/port,
but this gives me many problems:

1) User must be root
2) User must tell the application where his OPL chip resides
3) Nothing prevents multiple applications from both trashing the OPL
registers at the same time if they compete for its access.  A driver can
return -EBUSY instead to the latecomer.

Also, the user has to tell the application what kind of OPL chip he has.
This can be detected in a library, but ALSA already has detection, so
why bother doing it twice?

Is there a hwdep device like the ALSA Direct-FM device, but which
accomplishes raw access to the OPL device instead?  Or is there some
functionality in the Direct-FM API that I have overlooked?

Should I design another hwdep device to simply do raw FM programming, or
extend the ALSA DirectFM one?

Example of a new FM hwdep device:

/dev/asound/oplX

OPL_REG_WRITE -> write to a register of this cell
OPL_REG_READ -> read from a register of this cell
OPL_QUERY_TYPE -> what sort of OPL cell is this?
OPL_QUERY_PANNING -> if I write to these regs, what side does the
			sound produce on?
OPL_RESET -> Reset this cell

QUERY_TYPE is needed because the app must be programemd differently
depending on whether it wants a OPL2, OPL3, etc.  If it e.g. wants a
OPL3 but cannot find a OPL device with the type that it needs, it can
omit the sound or fall back to emulation instead.  A OPL2 device is not
sufficient for a OPL3 sequence, although the converse is ok.

QUERY_PANNING is needed because there is no way to the app to detect
what side the sound produced by this cell will arrive on, and only a
OPL3 has per-operator panning control.  Is it the left side, right side,
or is this a mono cell?  This will be setup by each card's driver,
because the driver is knowing the topology of the OPLx cells on the
card.  This can be useful for a SB Pro and similar cards with dual OPL2
cells, for dual Adlib cards (this is possible, just change one address
pin to put the second card at 0x390), etc.

Example: App wants a mono OPL2.  I search all oplX devices for a OPL2
device who has QUERY_PANNING return mono.  If I cannot find such a
device, I can search for OPL3 devices, and simply write to both sides of
the OPL3 to simulate a mono device.  If there is no OPL3, then I can
search for both a OPL2 device on the left side and a OPL2 device on the
right side.  If I find both of these, then I can just write to both of
them to produce a mono sound.  Otherwise, I can fall back to a emulation
in userspace because there is no hardware to satisfy my program's need.

Example: App wants two OPL2

Does this seem useful?  This may be like overkill, but I don't see any
other way to have working hardware OPL support when direct chip
programming is necessary.  It also seems like the Direct FM API does not
allow direct programming, only at a FM instrument level.

Thanks for your comments.

--=20
Ryan Underwood, <ne...@ic...>