provision of "driver" type facilities from user-space

provision of "driver" type facilities from user-space

[Iain Sandoe]

hi list,

I want to put a layer in between user-space and a driver (dmasound).

The reason is - that I want to provide facilities (transparently) to
applications and these facilities cannot be (sensibly) placed in the driver
[e.g. rate conversion and so on].

In this case to make dmasound look like it can do "anything" and help
support (easily) apps that don't really bother to check for h/w capabilities
properly.

It isn't really the best solution to bloat each and every app with code to
do the job - some form of sharing seems to be the right way.

so solution 1:

provide a pseudo-oss interface via a library:

psuedo_oss_open(), pseudo_oss_read() .... etc. etc.

so app source is amended and then linked with a lib providing the
appropriate stuff in user-space...

not, probably, going to be popular...

solution 2:

??? is there a way of doing this without the apps being amended but _still_
making sure that code that belongs in user-space resides and is executed
there?

preferably allowing apps to think they are just talking to /dev/dsp

ciao,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: provision of "driver" type facilities from user-space

[Hollis R Blanchard]

On Fri, 9 Mar 2001, Iain Sandoe wrote:
>
> I want to put a layer in between user-space and a driver (dmasound).
>
> The reason is - that I want to provide facilities (transparently) to
> applications and these facilities cannot be (sensibly) placed in the driver
> [e.g. rate conversion and so on].

Isn't this what esd and arts do?

-Hollis


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: provision of "driver" type facilities from user-space

[Brad Boyer]

Have you looked at the ALSA project? They have both a new kernel driver
and a user-space library that does extra capabilities. It is backward
compatible with OSS through an optional kernel module, and was just
recently ported to PowerMacs (beta only).

http://www.alsa-project.org/

I'm not sure it's exactly what you're trying to do, but it might be worth
investigating so you don't waste effort doing something that's already
being worked on. I haven't taken the time to read all their documentation,
but it might be a good place to start.

        Brad Boyer
        flar@pants.nu

Iain Sandoe wrote:
>
>
> hi list,
>
> I want to put a layer in between user-space and a driver (dmasound).
>
> The reason is - that I want to provide facilities (transparently) to
> applications and these facilities cannot be (sensibly) placed in the driver
> [e.g. rate conversion and so on].
>
> In this case to make dmasound look like it can do "anything" and help
> support (easily) apps that don't really bother to check for h/w capabilities
> properly.
>
> It isn't really the best solution to bloat each and every app with code to
> do the job - some form of sharing seems to be the right way.
>
> so solution 1:
>
> provide a pseudo-oss interface via a library:
>
> psuedo_oss_open(), pseudo_oss_read() .... etc. etc.
>
> so app source is amended and then linked with a lib providing the
> appropriate stuff in user-space...
>
> not, probably, going to be popular...
>
> solution 2:
>
> ??? is there a way of doing this without the apps being amended but _still_
> making sure that code that belongs in user-space resides and is executed
> there?
>
> preferably allowing apps to think they are just talking to /dev/dsp
>
> ciao,
> Iain.
>
>
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: provision of "driver" type facilities from user-space

[Iain Sandoe]

> Have you looked at the ALSA project?

yes, I'm subscribed to the list and have discussed the PMac drivers with
Takashi Iwai.

What I'm trying to do is meant to be very much lighter weight than ALSA.

thanks,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: provision of "driver" type facilities from user-space

[Iain Sandoe]

>> I want to put a layer in between user-space and a driver (dmasound).
>>
>> The reason is - that I want to provide facilities (transparently) to
>> applications and these facilities cannot be (sensibly) placed in the driver
>> [e.g. rate conversion and so on].
>
> Isn't this what esd and arts do?

yes... in a way.

I was hoping to avoid running a separate daemon...

but, well, maybe that's the only way to achieve it.

I thought the question worth asking.

a sort of attempt to Keep It Simple...

...and then there's the "favourite" way of doing things issue...

ah well.

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/