On Fri, Sep 24, 2010 at 14:14:32, Troy Kisky wrote: > On 9/24/2010 9:48 AM, Ambrose, Martin wrote: > > On Sat, Jul 04, 2009 at 21:29:59, Troy Kisky wrote: > > > >> If the codec is master then prepare should call > >> mcbsp_start, not trigger. > > > > For me this change induces audio artifacts when starting or stopping a gstreamer pipeline. > > Take, e.g., the pipeline > > gst-launch -v filesrc location=file.mp3 ! mad ! alsasink > > > > In the setup, before the file is opened, gstreamer places the pipeline into the PAUSE state. > > ... posting state-changed READY to PAUSED > > > > This results in a call to the davinci_i2s_prepare function which, when the codec is master, > > stops then starts the mcbsp driver. However at this point in the pipeline no valid data has > > been provided to the DMA layer (davinci-pcm). Consequently there is random noise of somewhat > > random length played out the DAC at the start of file playback. Moreover when the stream changes > > from the PAUSE to the PLAYING state another mcbsp_stop/mcbsp_start sequence is performed which > > seems inefficient. Similar behavior, and noise, occurs when the pipeline is shutdown. > > > > The aplay utility has a simpler startup/shutdown procedure which doesn't produce any noise. > > > > There doesn't seem to be any state context, e.g. pause vs start, provided to the prepare > > function so I can't see how to handle such cases in the current driver while preserving > > the use of this patch. If I revert this patch then I don't get any noise but I don't > > know what the consequences are. > > > > Comments/suggestions welcome. > > > > I don't see the problem because my codec waits until trigger to activate its interface. Thanks for the feedback. I'm using the tlv320aic3x codec driver. Which codec are you using? > So the question is, who should be responsible for the final turn on? > > My thought was that the device (master) which starts the external wires to wiggling should be last. Fair enough. I suppose that is the reasoning for the addition of the prepare function. The assumption being that a cpu_dai callback to the prepare function will always proceed a call to the codec_dai trigger function. In this way the serial port can be configured and enabled. Then the codec can turn on the bit/frame clocks which will start the flow of data. Although it would seem the codec is unmuted a bit prematurely in this scenario since it happens before the clocks are enabled in the core prepare function -- at least I think this is the case. However there would still seem to be spurious, or at least superfluous, calls to mcbsp_stop/start when just requesting the device to enter the pause state. I guess the call tree is then different in the case where the cpu, or machine, is the clock master. This has pros/cons obviously. > If the codec is master, and starts the clocks before the mcbsp is ready that could also cause a pop > or noise. I still a newbie when it comes to the ALSA architecture. Is the proper signal indicating everything is ready, including valid data, a trigger call with cmd=START? > It would be nice if such rules could be documented, are they??? Not that I know of. Regards, Martin _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
