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.
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.
If the codec is master, and starts the clocks before the mcbsp is ready that could also cause a pop or noise.
It would be nice if such rules could be documented, are they???
Thanks Troy