[alsa-devel] [PATCH V1 09/11] ASoC: DaVinci: i2s, add davinci_i2s_prepare and shutdown
Troy Kisky
troy.kisky at boundarydevices.com
Fri Sep 24 21:14:32 CEST 2010
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
More information about the Alsa-devel
mailing list