At Mon, 18 May 2009 13:33:10 +0300,Ozan Çağlayan wrote:> > Hi,> > I'm maintaining the ALSA stack as a separate alsa-driver using the> supplied tarballs from www.alsa-project.org unlike some popular distros> which uses the in-kernel sound/ stack. This has the advantage of quickly> acting against latest quirk or driver support changes and pushing a> driver update instead of whole the kernel update.> > But there is a big disadvantage that I'm not able to figure out how to> solve:> > When we enable the SND Kconfig option in kernel, some other sound> support for some DVB devices(e.g. SAA7134 sound support, etc.) are> enabled as well. So if you're using the in-kernel ALSA, you can enable> and use them happily but in my case, those additional sound supports> can't be enabled in kernel.> > Is there a way to hack around this when a separate alsa-driver is used> in a distro? It's fairly difficult because the internal API was changed.Especially the core struct was modified recently, thus there is noABI compatibility at all between the older kernel and the latest alsadriver. > Is it technically possible to patch those tiny drivers onto> alsa-driver and compile them if the .config file from the kernel source> has enabled those DVB devices?>> Or maybe I should enable ALSA in-kernel, compile those DVB sound stuff> and remove the sound/ directory from the kernel package? (Even the idea> sounds really *dirty*, dunno if it's technically possible too) You'd need to copy the original ALSA in-kernel stuff, copy the headersfrom alsa-driver, then rebuild the related modules in kernel to followthe new API. Also, some wrappers would be needed, e.g. for theobsoleted snd_card_new(). Takashi_______________________________________________Alsa-devel mailing listAlsa-devel@xxxxxxxxxxxxxxxxxxxx://mailman.alsa-project.org/mailman/listinfo/alsa-devel
