Re: [Linux-wildo-devel] Some talk about the sound API

[Gabriele D. C. <dar...@io...>]

On Wed, 4 Jul 2007 10:24:19 +0200 (CEST)
Benjamin Peter <ben...@ar...> wrote:

> Hi,
>=20
> Gabriele Dini Ciacci wrote:
> > This is a copy from IRC about gros idea on how the new API shoudl
> > look like:
>=20
> To make it clear, you mean an API that coveres codecs, filters and
> output, right?
>=20
> [Client]-> NEW API >-[Filters/Codec/Output]+
>
This API idea was basically for Input/Output from the card, but if well
written and if we cannot design an easier one for the Codec/Filters it
will be common to all.

> And about the multiplexing for the case of multiple speakers, this
> would be outside of the new API I suppose.

Multiplexing as in playing a sound only to left speaker if the sound
did come from left?
If yes that stuff that is related to the buffer containing the data
itself, each sound buffer will have it's propriety that will be passed
over until some layer use it or change it.
If you mean Multiplexing as in mixing different streams coming
simultaneously from the client it's _very_ complex to do, not regarding
the audio part but because of the network code and protocol needed.
If you mean Multiplexing as client and other applications it's not up
to us to manage that part, it's library stuff.

> >
> > The API for the sound part shouldn't be hard to define. Basically,
> > you need open(), close(), get/setParameters(), encode() and
> > decode().
> >
> > open() and close() would take no parameters. Parameters would be
> > twofold: implementation-specific ones (for example, the device name
> > for OSS, or the port to use for a Jack-based one) and LW-specific
> > ones (quality).
>=20
> So the parameters can be changed during usage? Well since this is
> codec/output specific I guess it depends and every API module should
> decide for itself and document it.

Yes, indeed each thing will support his parameters.

> What kind of parameter do you want to use, something like
> setParamater(string type, string value) to be generic?

Probably this look as much generic as it can be.
=20
> > encode and decode would take/return a sized buffer chunk of data.
>=20
> > both encode and decode should take the amount of desired bytes to
> > read/write as a parameter.
>=20
> Maybe a struct (class?) with two fields, size and buffer pointer
> would be nice? I think those values should stay together, maybe event
> to provide additional information about the buffer in the future. A
> filter might need information about the sample lenght (not by some
> static define) and if the buffer was already encoded ... so there
> might even be some kind of communication possible between the API
> modules.

Yes a struct can offer us many advantages indeed, and the slow down
will probably be a few. The struct can also contain additional
information that can be where the sound come from and such for use with
positional audio.

> (Could be MAXBUFF and be reused, struct holds the real and current
> size with a third field)
>=20
> >
> > open, close, encode and decode would all throw an IOException when
> > something goes wrong, to manage error cases.
> >
> > the LW client would probably pass the initialization parameters to
> > the sound class constructor (which would then have a
> > "contructor(string params)" prototype.
>=20
> How is this different to the setParameters(), they are dynamic the
> init params are static?

Yes, init are for init, like device for audio, you need to reinit the
interface asking the factory for a new one if you change any of the
init parameters, naturally we want to reduce them as much as we can,
without making it ridiculous unuseful, like device change for audio
card is not going to happen often and so it's fine to ask for a reinit.

> >
> > Ideally, you'd want to wrap sound classes management into a factory
> > class, so to "hide" the implementation details from the rest of the
> > LW code, which would only give an init string to the factory, and
> > get a generic "LW_Sound" class in return.
>=20
> This is the way to do it.

yes, it's lot of work, but I hope we can gradually add it without
breaking everything.

>=20
> Sounds good, the implementation will show what is missing. :-)
>=20
>=20
> regards,
>=20
> Benjamin Peter
> aka dedeibel

Salutes,
Gabriele
>=20
>=20
>=20
> Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen +
> telefonieren ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT
> bei Arcor: g=FCnstig und schnell mit DSL - das All-Inclusive-Paket f=FCr
> clevere Doppel-Sparer, nur  39,85 =80  inkl. DSL- und ISDN-Grundgeb=FChr!
> http://www.arcor.de/rd/emf-dsl-2
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Linux-wildo-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-wildo-devel


-----------=20
http://linux-wildo.sf.net
http://www.diniciacci.org