forums.ps2dev.org

[Lukasz]

Since the next The Third Creation deadline is on monday, March 1st,
I've decided to give everyone who is releasing a demo the opperrtunity test an alpa of freesd which I've been working on along with TyRaNiD.

Currently there are issues with freesd (which I believe reside somewhere in the init function), but I won't have time to fix them before
monday, but it should be working fine with block transfers which is what amigamod & SjPCM use.

Here is a little current state list:

- Note2Picth, Pitch2Note not implemented.
- BlockTrans does not support WRITE_FROM
- Issues with voices & effects, they seem to be working fine sometimes when I've loaded libsd first, which is why I believe
its somewhere in init the trouble is.

Download : http://www.lukasz.dk/files/freesd-0.8-alpha.zip

The final version will be released as a binary aswell as the source which will be commited to ps2drv in cvs.
Also there will an addon irx for freesd, which will make it possible to use freesd from EE, so basicly a RPC server. And ofcourse
a EE lib which will be the interface to this addon irx.

Any bugs and comments can be made in this thread.

Lukasz Bruun

[mrbrown]

If it's this far along, what's the holdup in putting it into CVS?

[ooPo]

Why not build the RPC services directly into freesd instead of as a separate irx?

[mrbrown]

Because it's unnecessary bloat for something designed to run soley on the IOP anyway. If you have to do sound processing on the EE, then you're in trouble :).

Besides most people would probably use sjpcm or amiagmod on top of freesd, and those two come with a RPC interface.

[ooPo]

Perhaps, but if he's offering to write yet another rpc interface to libsd/freesd, why not do something different? I mean, by your reasoning a rpc layer shouldn't even be bothered with.

[mrbrown]

RPC should always be optional, not bolted into a low level driver. By bloat I meant bloat freesd.irx with code that may never get used in practice. If the common practice is to interface with sjpcm via RPC, but sjpcm communicates with freesd on the IOP, what's the point of running a RPC server inside freesd if it's never activated?

The power of the IOP is that everything is modularized, you can have an IOP-only interface if you want to use the IOP in the background, and you can have an optional EE RPC interface in case you need to touch the device using the EE. The key is keeping drivers small so that you don't consume resources you might not use.

[ooPo]

I'll state it in simpler terms:

- This freesd is just a clone of libsd, but is free to use.
- The author has mentioned writing separate module as a RPC interface for it.
- There is one already available (sjpcm), so I suggest something different (putting rpc services directly into freesd).
- You say that its bloat.
- I reiterate how since there's already sjpcm, he could do something different, or not at all.
- You give a lecture on how it is bloat.

For the record, I know how the IOP is supposed to work with each module having a single function and living in modular harmony. Can we move past that?

Since sjpcm already exists, freesd works with it, if he's going to write rpc services:

1) Why not do something different and put them right into freesd?

2) Why write RPC it at all if sjpcm exists?

[mrbrown]

1) Because it's bloat.

2) I couldn't care less where RPC goes, where it lives now, or if it's written at all, not putting it in the direct access module is common practice and you are the only person that has ever suggested different.

With all this back in forth, in the end it's up to Lukasz to decide where it goes, and that doesn't make me any difference either :). I'm not debating what he should do, just why what you suggest isn't the thing to do.

[ooPo]

Might I suggest, Mr Brown, that you back down before I tell King Vu of your treachery!

His highness would be most displeased.

[Lukasz]