[alsa-devel] [PATCH] ASoC: pandora: switch clock back to internal on stop

[Peter Ujfalusi]

On 02/20/2012 12:50 PM, Grazvydas Ignotas wrote:
> Sounds good, I can wait for this I guess.

I just wonder why not just switch to twl4030 master scenario for
pandora? I know that there are products out there using this scenario (I
mean real consumer devices), and AFAIK they work pretty well.
What is the main reason to keep pandora in McBSP master mode? What is
the benefit for the platform? Can you send the per domain to suspend
during audio playback?

> Slightly off-topic: would you mind getting OSS emulation working on
> OMAP? We talked about it some years back.. I'm still carrying this
> hack in pandora tree:
> http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=commitdiff;h=7717278f6e

Hrm, yes I remember. Was it so that the OSS emulation calls hw_params
several times, each with different parameter to configure, or something?

If you do not have duplex operation this might be OK to do, but there
are cases when we return -EINVAL if a parameter is not correct...
To be honest I have not used OSS emulation for quite a long time, and
systems tend to use PulseAudio or AudioFlinger nowdays.
If it is really important for you we can take a look, it might bring
enhancements for other users as well at the end.

We also have the same mechanism in place in omap-mcbsp.c (to not allow
reconfiguration of the mcbsp port) so 'fixing' twl4030 might not be
enough for you.

> We have found in-kernel OSS emulation to have best compatibility and
> performance, and the later is important for a games machine with an
> aging SoC..

Is it still the case?

> The other issue with pandora on mainline is frequent buffer underflows
> just after the stream starts. Games tend to use tiny buffers with a
> goal to have low audio latency, and this often ends up with endless
> loop of stream start and underflow events. We used this hack on
> earlier kernels (the comment is probably not entirely correct, and
> fifo_samples should be multiplied by channels I guess):
> http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=commitdiff;h=d3ef3adfa

So we want to make sure that application written at least FIFO amount of
data into the buffer before we start the McBSP/DMA, right?
Not sure if it is a valid thing to just override the start_threshold.
But if we do something like this it might be better to have support in
the core (ASoC, or even in ALSA)..

> This can of course be fixed in a program itself, but the idea was to
> reduce effort needed to port things to pandora, and now I'll have to
> be carrying this for compatibility, but I wonder how that looks from
> mainline point of view.

We can try to figure out something, but I have a feeling that this would
be useful for other platforms as well.

-- 
Péter