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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
