[PaulHoule]

Device drivers can be very simple code, but you have to know something about systems programming to write them.

(E.g. you might be able to just allocate a buffer, copy data into the buffer, write to an I/O register to start the DMA and it is that many lines of code.)

You have to know how the device works. The vendor may or may not have gone out of the way to make it hard to initialize the device to control who can write drivers for it. Also the device could have many modes but you only need to use one which is less work.)

So it is high risk. In an easy case with good luck and the right skills an audio driver could be working in a day. In a hard case a professional reversing firm could do it with a $1M budget (think of the people who unlocked a terrorist’s iPhone for the fbi)

Other than writing new drivers there are ways to ‘virtualize’ a device driver to get it to run in a different environment, particularly for USB devices. That is, the driver works through an OS interface to send USB packets and you can tap it at this level, see how it works, tunnel the USB data to another OS, etc.

[mortirolo]

Hey, thanks for sharing this info, and your suggestion of virtualizing.

Given the risk you mentioned, it sounds tricky to commission without finding one of the team who had worked on the device previously and knew they could have it wrapped quickly. Or someone with a shared interest in getting it done.

At the risk of being told to Google it ... may I ask you a little more about your suggestion of 'virtualizing' the driver?

Would this involve running another full OS within the OS? Like, running a Mojave install from within a Big Sur install? VMWare type thing?

Latency is always a thing with audio routing, might this be a bit resource-intensive / slow?

Would there be implications with the M1?

Any hints welcome. Thanks

[PaulHoule]

When you can’t take no for an answer in software development you often have to get some hardware.

In your case a Windows machine or maybe you boot your old laptop into Windows. People report that older Windows drivers work perfectly in Win 10 but don’t say that in the .ini file. A 1 line change fixes that.

Maybe you can do the same with macOS, but the platform is less open.

What I call virtualization could be many things like tunneling the usb packets into VMware, but could also include binary patching the driver, or running the driver inside a simple emulator (only has to support the exact features the driver needs and the driver probably doesn’t do very much so throughput is a non-problem)

For instance you could use Libusb and pyusb and run the driver inside an interpretive emulator inside Python, observe what it does and replace one bit of functionality at a time until you know how it works.

Latency is tougher than throughput.

M1 runs ARM, I know it uses a binary translation emulator to run x86, how much backwards compatibility it provides I don’t know. If Apple were motivated to keep old drivers working they could do better than they do.

What I see is contradictory but some reports indicate it can use the standard audio drivers to run at 16 bit resolution and 44.1/48 sample rates. 24 gives headroom and high sample rates are great for effects processing, but you might be happy with the results you get with the standard driver if that’s the case.

All of these, for an individual, would cost more than a new USB audio device from a vendor with a different attitude. Roland’s attitude is a bad one for a vendor for tools for pros and other serious users; you can justify a high purchase price for a product with a long lifetime.

Searching I find there is a huge amount of frustration and you might do a Kickstarter.

[mortirolo]

Hi again. Thanks for your reply and explaining a little more about ideas for virtualisation. I am quickly getting out of my depth but at least now have an idea of possible directions to research and learn.

I also read the 1 line change fix for the Windows driver in a forum. Infuriating. It seems a stone cold profit / loss decision to brick the device when it would have been so easy to ship an updated driver.

But I also think that it shows a lack of imagination: if it's just about profit, Roland should let their customers pay for new drivers. Drivers can be an income stream, too, and after so many years of use, paying for an upgraded driver is not an unreasonable request.

Unfortunately at the time I bought this device, I was not wise enough to save and buy a device by a more conscientious company like RME.

I have contacted one of the more experienced developers at Roland to see if they might be willing to unofficially guide an effort to update the driver. That would definitely streamline the process.

Thanks also for the point about class-compliant mode at 16/44k. It is a good point and would give use of the analogue limiter. Although I am really trying to work with higher resolutions and not having use of the midi port is also a bit of a pain.

I agree the idea of a kickstarter for this device is worth testing.

Taking a step back, I also wonder whether a group of developers specialising in coding drivers for a whole range of unsupported audio interfaces could make decent money from grateful producers via patreon / kickstarter. That is if they weren't flooded with cease and desist orders.