Library communication port

Is there a way to create a kind of message port for a library which you can use to provide the library with additional data? So not throught the library interface.

I have a library which can be opened by one program only because it gains exclusive access over hardware. But I want to feed it with additional information from another program.

@geennaam

Access to hardware is normally something a device does, devices use io messages, the structure of device wherry similar to amiga library.

@geennaam

That's essentially what a filesystem or other handler does isn't it?

@geennaam
Quote:

You would normally not implement this via OpenLibrary/CloseLibrary.

You would rather allow the library to be opened by everybody. The library would have a gain_access and a release_access function. The gain_access function grants exclusive access for the first caller and fails for any successive caller until the first caller calls release_access.

For those callers where gain_access fails it could have a third function to supply data to the first caller.

How you implement this internally is up to you. For example the gain_access function could spawn a background process which listens to a message port. The supply_data function would then send the data to the port.

@all

Ok, my bad. I need to be more precise. The library is in fact a soundcard driver for AHI. AHI drivers are just libraries.

I need to control the volume though a mixer like program. The clean way to do this is to insert volume commands in the communication stream between the driver and the soundcard. The dirty way is to do it is via a debug interface in the soundcard hardware. The debug interface and normal communication stream are mutual exclusive. During normal playback, the communication interface shouldn't be actively sendind commands. But ahi programs could request a certain change through the library/driver interface. That might lead to undefined behaviour when the mixer program is used to control with the volume with the debug interface at the same time.
With all my tests I haven't seen any calls to this control function but it is there for a reason.

In end it is just a question. If it is not possible than I do it in the same way as mixer controls the volume of other soundcards. In this case that would be the debug interface.

double post

You could add private volume fields to your library base. The mixer would write the new volume values into these fields and the next time an AHI program issues a sound command the driver can check the volume fields and insert new volume commands into the command stream if needed.

@thomas

That will work but not realtime. Because the only library function called during playback by AHI is ahisub_start.
And this is called once to initiate the playback. From there on it is an interrupt driven process which hooks to the ahi mixer function to aqcuire the samples for playback.

@NinjaCyborg

Quote:

No..

A FileSystem or handler is on top of everything, they have lot in common.

FileSystem is handling what is stored on the media, but does not interact directly with hardware, it will access the hardware normally, by talking to a device.
Handers can be used different of things, like console handler, keyboard handler, a filesystem handler, and also serial handler (I believe the serial handler talk directly to the hardware.).

Libraries is the API developers use when they code, its set of routines, that contains a index register / lookup table, you reference the routine, from a offset, different standards are used for 680x0 programs and PowerPC programs.

The OLD standard uses D0-D7,A0-A7 CPU registers, it uses 680x0 instructions, etc, wherry CPU dependent. The AmigaOS4 interface on the other hand is based on higher languages like C, so everything is written in C language. (backwards compatibility is optional.)

Devices is what normal controls the hardware, and present the blocks stored I the media.
it has lot in common with Libraries, it has some standard routines to access the device, it also has to preform reading or writing to the hardware. (the hardware can be virtual or real, that does not matter.), the device can also perform async operations, the filesystem does not need to wait for the device to write blocks, devices can be smart or stupid, they can cache blocks internally, but not all device does this.

@LiveForIt

I meant, if you need to maintain some global statefulness over the top of a device driver, that's what a handler could be used for.