No support for real OPL?

[tomas]

Looking at the adplay-unix source reveals that nowhere is the CRealopl class used, which means (as far as I know) that adplay-unix doesn't actually support using a real OPL chip.

Is this on purpose? Would you be interested in a pull request to include this?

[Malvineous]

I had to remove support for CRealopl from the latest Winamp plugin as the Windows API no longer supports I/O port reads/writes (even with the appropriate drivers), and I figure computers running the latest versions of Windows are fast losing the ability for a real OPL to be connected to them anyway.

If you think support for this would be useful (and you have a computer running adplay-unix that has a real OPL you can test with) then by all means send a pull request through and I'll be happy to merge it. I'm not sure how much use it would get but maybe there are still people out there using AdPlug with hardware OPL devices?

[tomas]

I do have an OPL equipped laptop and would love to get adplay running on it using the CRealopl class. I also think there's a growing interest in FM synthesis, in general, so I don't think I'll be the only guy using this if implemented, haha.

Now, why is the Winamp plugin relevant for the purposes of this client? Is any part of the code shared between the two projects?

[Malvineous]

In that case, go right ahead.

The Winamp plugin is the main user of the AdPlug library and the way most AdPlug users make use of the library. I only mention it because now it has lost real OPL support, and it does suggest there are fewer machines as time goes on that are capable of communicating with a real FM synth.

Because of this there are currently no users of CRealopl and I was contemplating removing it entirely, as opposed to just disabling it under Windows as is the case now. However if you add support for it to adplay-unix, then I guess that's one reason to keep CRealopl a little longer!

[tomas]

Keep it forever! Eventually the world will realize we need to start putting OPL chips back into laptops, haha.

On a sidenote, I've been trying to use the CRealopl class on Deadbeef's adplug plugin but I had to do a couple of changes in realopl.cpp for it to initialize correctly in Linux -- though I haven't managed to get sound out of it yet.

I'm assuming I'd need to send a PR with those changes to adplug in order to get CRealopl working in this repo, right? Or is there something I'm missing?

[Malvineous]

Happy to keep it there as long as someone is actually using it!

Yes I'm no expert on port I/O under Linux but it looks like that will have to become part of the core adplug library for it to work under Linux. I'm not sure whether you still have to run adplay-unix as root though, I'm guessing yes.

Probably best if you make those changes locally and once you get it working, send one pull request for adplay-unix and then a second one for adplug (as opposed to sending a PR for those Deadbeef changes then having to send another once you get it working.)

[KynikossDragonn]

Would anybody here need a Linux user to help test real OPL support?

Another project known as "vgmplay" can use real OPL chips if you tell it where to find the chip. I have a soundcard using a legit CMI8738 (so not a real Yamaha OPL3 but it sounds closer than Creative's CQM) behind a bridge chip. As a result of the bridge chip the OPL3 has to be accessed at 0xD050 rather than the typical 0x388. (My card uses the range D000-DFFF)

Short audio example here:
realopl3usage.ogg

To make adplay-unix work without root in this case (like vgmplay is) you must pass the proper capability onto it:
sudo setcap cap_sys_rawio+ep adplay

[tomas]

@KynikossDragonn Kudos to you my friend. I knew I wasn't the only Linux user wanting to make use of an OPL chip!

[KynikossDragonn]

@tomas Thanks. I was surprised this even worked myself.

There seems to also be support for hardware OPL in Chocolate Doom, you most likely also have to do the same "setcap" invocation to make that work without root as well.

[tomas]

TIL about the setcap command, by the way. Do you know what the command does internally?

[KynikossDragonn]

I don't know fully how the capability system works. I'm going to presume that information is stored somewhere sane... Not sure if it stores that directly in the ELF header or some information database system wide.

Would be worth reading CAPABILITIES(7) in man.

[Malvineous]

Normally a program doesn't have access to directly write to I/O ports unless run as root. When a program tries, the CPU jumps into the kernel and it's up to the kernel to decide whether to allow it or to terminate the program with an exception. setcap just tells the kernel to allow any requests to write to I/O ports for that one active process (or in the case of a shell like bash, for any program that it launches from that point on), so it's only stored in memory and you have to reapply it each time. Either way it's bad for security because any bugs in the app that are exploited (e.g. from a malicious song that "can only be played on a real OPL chip!!") can result in complete control of the hardware, so really there's little benefit to using setcap over just running the program as root.

While supporting playback on real OPL chips is great, I'm not such a huge fan of doing it by directly writing to I/O ports for this reason. In my opinion it would be better served by having a kernel module talk to the OPL chip, and then make something like /dev/opl available for userspace applications to use. This way you don't need root or dangerous setcap commands, and you can write your kernel module to turn all the notes off when the /dev/opl device is closed, to prevent any hanging notes. Of course having to load custom kernel modules is a lot more involved than just running as root, so there are certainly tradeoffs.

The Linux kernel already has drivers for the OPL3 chip (looks like you can use it as an ALSA MIDI device and there seem to be functions for loading custom instruments) so it may already have a method of sending the chip raw OPL data. It would be worth investigating this further, because if there's already a way to use existing kernel modules for OPL chip access then that would be a much cleaner, more secure method to use and wouldn't need root access or setcap.

[KynikossDragonn]

Yeah, not only is there a OPL3 driver for ALSA MIDI playback, the driver appears to be aware of bridge chip remappings despite the driver "snd_cmipci" being loaded with a default "0x388" fm_port variable... I'm not sure how they figure that part out so automatically like that, I don't really understand enough C\C++ to figure alot of these out by glance.

I can understand why direct IO is a big "no no" but I don't know of anybody willing to write a kernel driver to handle this stuff, and I'm not much of a decent programmer to wrap my head around that issue myself unfortunately. The rawio method just seems much simpler to do by comparison.

[Malvineous]

The kernel module would be nice but I agree, it's a complex solution to create one from scratch. Are you able to have a look at the existing OPL kernel modules and ascertain whether any of them already provide direct access to the OPL registers? Maybe the module already exists and has done so for a while, which would be perfect.