[alsa-devel] size of snd_hda_intel
ismod
snd_hda_intel 435,772
435,772 bytes seems awfully large for an audio driver. The large size seems to be due to having support for multiple codecs in the driver. Could a generic hda driver load the correct codec dynamically instead of building them all in statically?
I have a Realtek codec.
Hi,
On Sun, 2008-10-05 at 18:19 -0400, Jon Smirl wrote:
ismod
snd_hda_intel 435,772
435,772 bytes seems awfully large for an audio driver. The large size seems to be due to having support for multiple codecs in the driver. Could a generic hda driver load the correct codec dynamically instead of building them all in statically?
I have a Realtek codec.
snd_hda_intel should probably be rearchitected to be similar to the way that snd-aoa works... e.g. multiple modules for codecs, etc.
But, that's a lot of effort, and I don't personally have the hardware to test (only one box of mine has HDA audio that I know of, and I use a better card there), or I would start working on making that happen.
William
At Sun, 5 Oct 2008 18:19:05 -0400, Jon Smirl wrote:
ismod
snd_hda_intel 435,772
435,772 bytes seems awfully large for an audio driver. The large size seems to be due to having support for multiple codecs in the driver. Could a generic hda driver load the correct codec dynamically instead of building them all in statically?
Splitting to modules is no essential solution. But, a lot of works are undergoing.
Takashi
I believe this isn't that easy. Here is why: iff you look at the ice1712/ice1724 driver, it doesn't detect dependencies when modprobed; that is, it loads, for example, ac97 codec and ak4xxx driver even if the card doesn't have any of that. Is it even possible to detect dependencies after modprobing?
2008/10/6 Jon Smirl jonsmirl@gmail.com:
ismod
snd_hda_intel 435,772
435,772 bytes seems awfully large for an audio driver. The large size seems to be due to having support for multiple codecs in the driver. Could a generic hda driver load the correct codec dynamically instead of building them all in statically?
I have a Realtek codec.
-- Jon Smirl jonsmirl@gmail.com _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Mon, Oct 6, 2008 at 4:28 AM, Vedran Miletić rivanvx@gmail.com wrote:
I believe this isn't that easy. Here is why: iff you look at the ice1712/ice1724 driver, it doesn't detect dependencies when modprobed; that is, it loads, for example, ac97 codec and ak4xxx driver even if the card doesn't have any of that. Is it even possible to detect dependencies after modprobing?
The base intel hda module would include code to figure out which codec is attached. It can then use loadmodule() to dynamically load it. ASOC use the separate codec driver model.
It would look like a "hda" bus in sysfs with the "codec" module sitting on it.
2008/10/6 Jon Smirl jonsmirl@gmail.com:
ismod
snd_hda_intel 435,772
435,772 bytes seems awfully large for an audio driver. The large size seems to be due to having support for multiple codecs in the driver. Could a generic hda driver load the correct codec dynamically instead of building them all in statically?
I have a Realtek codec.
-- Jon Smirl jonsmirl@gmail.com _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
-- Vedran Miletić
At Mon, 6 Oct 2008 21:29:32 -0400, Jon Smirl wrote:
On Mon, Oct 6, 2008 at 4:28 AM, Vedran Miletić rivanvx@gmail.com wrote:
I believe this isn't that easy. Here is why: iff you look at the ice1712/ice1724 driver, it doesn't detect dependencies when modprobed; that is, it loads, for example, ac97 codec and ak4xxx driver even if the card doesn't have any of that. Is it even possible to detect dependencies after modprobing?
The base intel hda module would include code to figure out which codec is attached. It can then use loadmodule() to dynamically load it. ASOC use the separate codec driver model.
You mean AOA? ASoC doesn't do any dynamic module handling by itself, AFAIK.
It would look like a "hda" bus in sysfs with the "codec" module sitting on it.
Well, originally there shouldn't have been so many codec variants. The current situation came up due to a couple of obvious reasons...
Ayway, the current plan is to develop an improved generic parser and add the capability to extra setup for each hardware, either dynamically or statically. In that way, the whole static function callbacks and mixer arrays can be removed or replaced with smaller hints.
The codec reconfigure patches are already in my tree in topic/hda-reconfig branch, and the improvement of generic parser is under development.
Takashi
2008/10/6 Jon Smirl jonsmirl@gmail.com:
ismod
snd_hda_intel 435,772
435,772 bytes seems awfully large for an audio driver. The large size seems to be due to having support for multiple codecs in the driver. Could a generic hda driver load the correct codec dynamically instead of building them all in statically?
I have a Realtek codec.
-- Jon Smirl jonsmirl@gmail.com _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
-- Vedran Miletić
-- Jon Smirl jonsmirl@gmail.com _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Tue, Oct 07, 2008 at 10:41:30AM +0200, Takashi Iwai wrote:
Jon Smirl wrote:
The base intel hda module would include code to figure out which codec is attached. It can then use loadmodule() to dynamically load it. ASOC use the separate codec driver model.
You mean AOA? ASoC doesn't do any dynamic module handling by itself, AFAIK.
It does this through reuse of the standard module loader - the machine drivers all have references to the codec and platform driver modules so providing something can figure out how to load the only relevant machine driver only the codec and platform drivers for that machine will be loaded.
v2 pretty much keeps on with the same model, though codec and platform drivers will be able to be instantiated via means other than the machine drivers.
2008/10/7 Takashi Iwai tiwai@suse.de:
At Mon, 6 Oct 2008 21:29:32 -0400, Jon Smirl wrote:
On Mon, Oct 6, 2008 at 4:28 AM, Vedran Miletić rivanvx@gmail.com wrote:
I believe this isn't that easy. Here is why: iff you look at the ice1712/ice1724 driver, it doesn't detect dependencies when modprobed; that is, it loads, for example, ac97 codec and ak4xxx driver even if the card doesn't have any of that. Is it even possible to detect dependencies after modprobing?
The base intel hda module would include code to figure out which codec is attached. It can then use loadmodule() to dynamically load it. ASOC use the separate codec driver model.
You mean AOA? ASoC doesn't do any dynamic module handling by itself, AFAIK.
This lets you load another module from intel_hda:
request_module("%s", module_name);
It would look like a "hda" bus in sysfs with the "codec" module sitting on it.
Well, originally there shouldn't have been so many codec variants. The current situation came up due to a couple of obvious reasons...
Ayway, the current plan is to develop an improved generic parser and add the capability to extra setup for each hardware, either dynamically or statically. In that way, the whole static function callbacks and mixer arrays can be removed or replaced with smaller hints.
The codec reconfigure patches are already in my tree in topic/hda-reconfig branch, and the improvement of generic parser is under development.
Takashi
2008/10/6 Jon Smirl jonsmirl@gmail.com:
ismod
snd_hda_intel 435,772
435,772 bytes seems awfully large for an audio driver. The large size seems to be due to having support for multiple codecs in the driver. Could a generic hda driver load the correct codec dynamically instead of building them all in statically?
I have a Realtek codec.
-- Jon Smirl jonsmirl@gmail.com _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
-- Vedran Miletić
-- Jon Smirl jonsmirl@gmail.com _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Tue, 7 Oct 2008 08:28:49 -0400, Jon Smirl wrote:
2008/10/7 Takashi Iwai tiwai@suse.de:
At Mon, 6 Oct 2008 21:29:32 -0400, Jon Smirl wrote:
On Mon, Oct 6, 2008 at 4:28 AM, Vedran Miletić rivanvx@gmail.com wrote:
I believe this isn't that easy. Here is why: iff you look at the ice1712/ice1724 driver, it doesn't detect dependencies when modprobed; that is, it loads, for example, ac97 codec and ak4xxx driver even if the card doesn't have any of that. Is it even possible to detect dependencies after modprobing?
The base intel hda module would include code to figure out which codec is attached. It can then use loadmodule() to dynamically load it. ASOC use the separate codec driver model.
You mean AOA? ASoC doesn't do any dynamic module handling by itself, AFAIK.
This lets you load another module from intel_hda:
request_module("%s", module_name);
As mentioned, it's no fundamental solution. The real problem is that the driver has too many stuff that can be trimmed down.
Takashi
participants (5)
-
Jon Smirl -
Mark Brown -
Takashi Iwai -
Vedran Miletić -
William Pitcock