[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cdi-devel] Proposed Sound Infrastructure


> * We need to support at least two different kinds of OSes. This make a
>  difference foremost for the interface between mixer and hardware
>  driver. The monolithic case is easy, as usual. In other OSes, each
>  hardware driver might sit in its own process and the mixer in another
>  one. We need to support a model where the communication uses some RPC
>  model (and for tyndur I'd prefer to use shared memory for the data)
>  So both of the arrows above would end up as OS specific code.

I agree.

> * We need to support hardware mixers. Drivers tell the mixer how many
>  streams they can do in hardware and the CDI mixer sends the number as
>  an additional parameter. Don't know how it looks in detail, but
>  something like this.

That's true. I think if we have a "software mixer" CDI device which
automatically determines if the sound device it's mixing for support
hardware mixing (and therefore sends it down to the hardware mixer),
it'd work well. That would require a couple of extra functions in the
sound device interface, mainly to determine if hardware mixing support
is available (and whatever other support functions would be needed for
hardware mixing).

>> I do believe that this needs further discussion, and as such I am
>> merely proposing the infrastructure at this stage. Things to still
>> consider include linking the mixer to sound hardware (in a generic,
>> OS-independent manner),
> The mixer will need a method to enumerate all sound devices. I think
> this would be part of the OS specific driver/mixer interface. The mixer
> would probably expose this list to the applications so they could
> select the output device they want to use.

Right, and I think a method to access other devices from CDI drivers
would be rather handy at times as well. This should be another CDI
"system call", in my opinion. How that call looks is probably
something to be discussed - it needs to be generic for driver code but
at the same time able to cater to many different ways for an OS to
handle devices. Any ideas?

> Do you agree with our thoughts so far?

At this stage I do.