On Thu, Apr 26, 2018 at 05:30:05PM +0100, Charles Keepax wrote: > It is proposed that the model adopted for compressed component > support currently should be that multiple components are supported > on a compressed DAI but that they must provide a unified set of > capabilities. So for example having multiple components involved in > the decode is fine but the core will not presently attempt to make > smart decisions like offloading MP3 to this component and AAC another. Well this is supposed to be entirely a userspace call, we just present devices with capabilities and the usespace decides... Btw capabilities are supposed to be dynamic. Looking at the code again now, I realized that we are treating compress like PCM. It makes little sense to me to have multiple components for a compressed device, does that model on your systems..? > To implement this it is suggested that callbacks configuring the state > of the components (trigger, set_params, ack and set_metadata) should be > called on all components and required to succeed on all components > before being considered to have succeeded. However for callbacks that > return information from the driver (copy, get_metadata, pointer, > get_codec_caps, get_caps and get_params) it is expected that either > there is only a single provider on the link or that all components > will return identical results. > > Essentially this matches the current implementation of the code and > only small clean ups are undertaken here. > For callbacks configuring the state of the components simplify the > code a little and make intention clearer by aborting as soon as an > error is encountered. The operation has already failed and there is > nothing to be gained from processing the additional callbacks. > > For callbacks returning information from the driver only look for the > first callback provided, currently the code will call every callback > only returning the information provided by the last. Again this makes > the currently supported feature set a little more clear. Btw code changes look fine but I think we need broader cleanup here... -- ~Vinod _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
