under linux direct hardware access is not a normal thing

Well ALSA has to be "directly accessing the hardware" to even beable to use the OPL3 because you have to write to it's registers to make it produce sound. I get that it's not a "normal thing" but that's not answering if what I want to do is feasible enough. I already seen working passthrough on Windows NT based systems using either special drivers or Ring 0 "rootkits", but never under Linux...

alsa has drivers, and those do the accessing of the hardware, i hope this answers your question

Hey guess what, it is possible. Though it can be only done under root (and I'm not sure what the specific capability\permission is to make non root users able to access this)

Though the port is not 0x388 but instead 0xD050 according to NukeYT.

Now I just need to find more software to test this with. I hear Chocolate Doom has support for direct OPL access. Is there a build of adplay for Linux that has it as well?

DracoNihil wrote:

Though the port is not 0x388 but instead 0xD050 according to NukeYT.

Since it's a PCI-e card, and not a legacy ISA card, I'm not too surprised that it uses a different port range.

Root can do IO on ports, but that is not very neat. You might have a raw device under /dev/snd, such as /dev/snd/fmCxxx, where the xxx stands for the Alsa card. But that depends on the driver, and I have not used it. That device should be an abstraction of the OPL3 ports into the device file system, so that you do NOT need root privileges. I don't have any Linux machine with such a configuration on hand though, so take it with a grain of salt...

Scali wrote:

and not a legacy ISA card

CMI8738's were never ISA to begin with as far as I know. They were among the first PCI only soundcards with dubious SBPro2 backwards compatibility.

root42 wrote:

Root can do IO on ports, but that is not very neat. You might have a raw device under /dev/snd, such as /dev/snd/fmCxxx, where the xxx stands for the Alsa card. But that depends on the driver, and I have not used it. That device should be an abstraction of the OPL3 ports into the device file system, so that you do NOT need root privileges. I don't have any Linux machine with such a configuration on hand though, so take it with a grain of salt...

I only get the following in that directory (I don't even know that much about ALSA to begin with either):

1by-id    controlC0  hwC0D0    pcmC0D0c  pcmC0D1p  pcmC0D2p  seq
2by-path  controlC1  midiC0D0  pcmC0D0p  pcmC0D2c  pcmC1D0c  timer

And I know there is a way to specify permissions a process name can access (I had to do this to permit Wine's processes to bind ports 0-1024) but I don't know what the name of the permission is to grant.

DracoNihil wrote:

I only get the following in that directory (I don't even know that much about ALSA to begin with either): […]
Show full quote

root42 wrote:

Root can do IO on ports, but that is not very neat. You might have a raw device under /dev/snd, such as /dev/snd/fmCxxx, where the xxx stands for the Alsa card. But that depends on the driver, and I have not used it. That device should be an abstraction of the OPL3 ports into the device file system, so that you do NOT need root privileges. I don't have any Linux machine with such a configuration on hand though, so take it with a grain of salt...

I only get the following in that directory (I don't even know that much about ALSA to begin with either):

Copy code to clipboard

1by-id    controlC0  hwC0D0    pcmC0D0c  pcmC0D1p  pcmC0D2p  seq
2by-path  controlC1  midiC0D0  pcmC0D0p  pcmC0D2c  pcmC1D0c  timer

And I know there is a way to specify permissions a process name can access (I had to do this to permit Wine's processes to bind ports 0-1024) but I don't know what the name of the permission is to grant.

Do a 'ls -l /dev/snd' and you will see that all those devices have group id "audio". So you just need to make sure that the processes you are running are run by a user that is in the audio group.

It is also very hard to find information about low level FM / OPL2 / OPL3 access in Linux. But I guess someone might be able to write a simple device driver... That would actually be a neat project, come to think of it...

I mean, you can look at vgmplay's source code for how they're directly writing to the registers.

As far as drivers go, ALSA just has a driver for using the OPL3 as a "General MIDI" device. Somehow this driver also works around bridge chip usage, despite the driver having the "fm_port" set to 388...

Concerning vgmplay: you should be able to run it without root privileges after setting the capabilities:

sudo setcap vgmplay CAP_SYS_RAWIO

Also not tested, but it should give the process to call ioperm() -- which it does, according to the source in ChipMapper.c -- and hence be able to write directly to the OPL2/3.

In my case the invocation is:

1sudo setcap cap_sys_rawio+ep ./vgmplay

Thanks for pointing me out what the capability was named, no need to constantly sudo vgmplay. I'm going to assume it'll be the same case for Chocolate Doom's direct OPL access too, and anything else using the raw IO syscalls or whatever.

Yes, should be the same. Sorry for the wrong syntax. I did that from memory... 😒