<br><br><div><span class="gmail_quote">On 1/12/07, <b class="gmail_sendername">Mikael Hallendal</b> <<a href="mailto:micke@imendio.com">micke@imendio.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Just to clearify, I'm only talking about what I think fits in DAPI.<br>Not that the features you describe wouldn't be useful in a multi-<br>platform library/daemon.</blockquote><div><br>Thanks, that is my POV :)<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I think they fit in their own component as I said in my last email.<br>DAPI can't be a full Sound-abstraction layer, that's not what it <br>does. It's a layer to abstract common and simple operations that are<br>used by a wide range of applications.</blockquote><div><br>Then, due to the similarity of the design, and the goal, what about putting these "more advanced interface for sound" in DAPI and call the library dapi-sound? Sincerly, if you think about the needs, these interfaces are not that advanced. Dealing with sound is probably a bit more complicated that what people expect at the beginning. But still we can provide very simple function like "Play". But such simple function will probably not be used for long, because they are not really that useful... <br></div></div>-- <br>Marc-André Lureau, GSmartMix