On Tue, Aug 17, 2010 at 6:46 PM, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Aug 17, 2010 at 08:14:43AM +0900, Jassi Brar wrote: > >> I guess most quality conscious products can afford to attach a dedicated >> OSC to a good CODEC. A CODEC already specifies the clocks it support >> and usually comes with 'preferred' input clocks. So, just having a specified >> rating accurate enough OSC can take care of quality. On the other hand >> the clock sources on CPU side are not particularly accurate for audio-clock >> generation. Or so have I seen so far. > > Right, this shouldn't be an issue with the change I proposed - the > clocks are still rooted from the CODEC and its clock generation > facilities would still be used, it's just that they get routed > differently. > > The issue with using most CPU clocks isn't really the dedicated > oscillator so much as the ability to generate non-integer divisions of > whatever input clock is available. If this can't be done then it can be > hard to generate the full range of common audio frequencies. Ok, now that I am faced with supporting latest SMDKs that use codecs other than WM8580 (like wm8994), I think we'd better break the MACHINE driver into SMDK specific (setup CPU master, CODEC slave and root-clock sourced acc to option provided vai platform_data) and CODEC specific part. That will also help code reuse. Any opinions, before I start working on it? Thanks, Jassi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
