Re: [alsa-devel] Installing a "different" version of Alsa
Message: 1 Date: Sun, 20 Dec 2009 12:47:28 +0000 From: Mark Brown broonie@opensource.wolfsonmicro.com Subject: Re: [alsa-devel] Installing a "different" version of Alsa To: Brian Welch Brian-Welch@cox.net Cc: alsa-devel@alsa-project.org Message-ID: 20091220124727.GA2881@sirena.org.uk Content-Type: text/plain; charset=us-ascii
On Sat, Dec 19, 2009 at 09:48:16PM -0700, Brian Welch wrote:
When I use kbuild to build my custom sound hardware driver against the SDK in the kernel, it always trys to pick up the older ALSA header files that are in the SDK, but I want to use the newer versions that are in the directory with the newer version of ALSA. What the best way to make sure I get the correct headers? Is what I'm trying "dangerous" and should I be going about this a different way?
The best way of integrating with the toolchain you're using will usually depend on the toolchain - you'll generally be able to get better advice about how to work with the toolchain by asking people who work with the toolchain.
I guess I don't understand exactly what you mean by "toolchain." I've already contacted the people that package up the SDK and they said I should solve it myself. I originally hoped that I could just re-build the kernel without Alsa built-in, then add my new version of Alsa, but they claim that causes other issues (i.e. no sound at all).
On Sun, Dec 20, 2009 at 11:34:03PM -0700, Brian Welch wrote:
I guess I don't understand exactly what you mean by "toolchain." I've already contacted the people that package up the SDK and they said I should solve it
I mean the people who produce whatever embedded Linux distribution you are using (you didn't mention?), or the user community surrounding it. If you're having trouble getting support from them there's other distributions out there such as the OpenEmbedded based ones which do have more of an active user community around them:
myself. I originally hoped that I could just re-build the kernel without Alsa built-in, then add my new version of Alsa, but they claim that causes other issues (i.e. no sound at all).
If it's just the drivers you need to update it's probably easier to merge the newer ALSA version into the kernel rather than trying to keep an out of tree version as well, it will hopefully reduce the level of confusion within the toolchain.
----- Original Message ----- From: "Mark Brown" broonie@opensource.wolfsonmicro.com To: "Brian Welch" Brian-Welch@cox.net Cc: alsa-devel@alsa-project.org Sent: Tuesday, December 22, 2009 5:58 AM Subject: Re: [alsa-devel] Installing a "different" version of Alsa
On Sun, Dec 20, 2009 at 11:34:03PM -0700, Brian Welch wrote:
I guess I don't understand exactly what you mean by "toolchain." I've already contacted the people that package up the SDK and they said I should solve it
I mean the people who produce whatever embedded Linux distribution you are using (you didn't mention?), or the user community surrounding it. If you're having trouble getting support from them there's other distributions out there such as the OpenEmbedded based ones which do have more of an active user community around them:
myself. I originally hoped that I could just re-build the kernel without Alsa built-in, then add my new version of Alsa, but they claim that causes other issues (i.e. no sound at all).
If it's just the drivers you need to update it's probably easier to merge the newer ALSA version into the kernel rather than trying to keep an out of tree version as well, it will hopefully reduce the level of confusion within the toolchain.
Hmmm, yeah, problems all the way around. Maybe I should explain in more detail. This SDK is for a platform (silicon/software/dev-board) still very much under development and I can't say too much without violating NDA, etc. The SDK is currently supported by the silicon manufacturer. It includes a vanilla Linux distribution directly from kernel.org and a small kernel patch. In addition to the Linux distrubution there are drivers in the SDK for dozens of custom devices including custom sound hardware. Basically, they're rolling their own toolchain and supporting it (for now).
I've written an Alsa-compatible sound driver layer to go between Alsa and their custom driver and it's been working for a few months, but they recently decided to start supporting two versions of the SDK, each having a different version of Linux. The version of Alsa built-in to Linux in each version of the SDK is different, and they would like to supply a version of Alsa "out-of-tree" so that both SDKs are the same and so that customers can theoretically swap out to any version of Alsa they want.
This change has caused my driver to not build correctly/reliably on both SDK versions. The reason is that the symbols in linux/include/sound are different than the out-of-tree include files that I need to build against. I can make it work by hacking the SDK directory structure but they want to eventually integrate everything into the SDK so minimizing hacks is desirable.
Merging the correct version of Alsa into the kernel will fix my immediate problem but they don't want to do it because it won't satisfy the desire to be able to swap in any version of Alsa (assuming that's actually possible).
Another thing I thought of was to fix up the kernel/include/sound directory structure with soft links when "installing" the out-of-tree version of Alsa into the SDK, but I didn't get a positive reaction when I suggested it.
Brian
On Tue, Dec 22, 2009 at 02:50:42PM -0700, Brian Welch wrote:
From: "Mark Brown" broonie@opensource.wolfsonmicro.com To: "Brian Welch" Brian-Welch@cox.net
If it's just the drivers you need to update it's probably easier to merge the newer ALSA version into the kernel rather than trying to keep an out of tree version as well, it will hopefully reduce the level of confusion within the toolchain.
Hmmm, yeah, problems all the way around. Maybe I should explain in more detail. This SDK is for a platform (silicon/software/dev-board) still very much under development and I can't say too much without violating NDA, etc. The SDK is currently supported by the silicon manufacturer. It
Feel free to contact me off-list if you feel you're able to discuss things a bit more that way, I might be able to advise in more detail with more information. Please also feel free to put the vendor in touch with me directly, I can discuss these issues from the point of view of a silicon vendor.
includes a vanilla Linux distribution directly from kernel.org and a small kernel patch. In addition to the Linux distrubution there are drivers in the SDK for dozens of custom devices including custom sound hardware. Basically, they're rolling their own toolchain and supporting it (for now).
On this front it may well be worth pointing out to them that a number of large companies have tried this approach and run into trouble with it in the longer term due to things like the effort involved in maintaining things once you've got a number of legacy products or customer pressure to have mainline work. There's an awful lot of work in maintaining a full Linux kernel, never mind distribution, and many customers are not going to use large parts of this work anyway (especially at the distribution level) and use their preferred software stack.
I've written an Alsa-compatible sound driver layer to go between Alsa and their custom driver and it's been working for a few months, but they recently decided to start supporting two versions of the SDK, each having a different version of Linux. The version of Alsa built-in to Linux in each version of the SDK is different, and they would like to supply a version of Alsa "out-of-tree" so that both SDKs are the same and so that customers can theoretically swap out to any version of Alsa they want.
Hrm, are these standard ALSA drivers, not ASoC drivers? If this is a standard embedded processor setup with an I2S or similar controller in the processor talking to an external device providing the audio CODEC then the code really ought to be written in terms of ASoC in which case trying to go for compatibility with multiple kernel versions is going to be more trouble than its worth since the ASoC APIs are fairly fluid and are likely to continue to be so for the forseeable future.
The big win from ASoC from the point of view of the CPU vendor is that they will get compatibility with all the audio CODEC devices supported by Linux without having to reinvent the wheel each time, and won't have to support customisations for individual customer boards within their code. This really does save a lot of time, especially once you start to address a wide customer base.
This change has caused my driver to not build correctly/reliably on both SDK versions. The reason is that the symbols in linux/include/sound are different than the out-of-tree include files that I need to build against. I can make it work by hacking the SDK directory structure but they want to eventually integrate everything into the SDK so minimizing hacks is desirable.
Without knowing what their SDK is doing it's going to be hard to comment in much more detail than to say that contributing the code to the kernel is the simplest way to get something that's up to date with kernel API changes. If they don't want to contribute their code upstream then the easiest approach is usually to track the current ASoC version and backport ASoC (and possibly all ALSA) en masse to whatever kernel version they are targetting. This will make life easier if/when they do decide to work upstream and avoids having to deal with any bugs or missing features in older kernels.
Trying to mix and match an in kernel ALSA with an out of tree ALSA isn't going to work well, if you are using an out of tree ALSA then you should completely disable the in tree version
Merging the correct version of Alsa into the kernel will fix my immediate problem but they don't want to do it because it won't satisfy the desire to be able to swap in any version of Alsa (assuming that's actually possible).
ALSA and ASoC are generally relatively independant of the kernel version, though it's likely that ASoC is going to grow support for runtime PM very soon which will be a bit of a backporting issue.
Like I say it's hard to comment in too much detail without more information but it does sound like the vendor is expecting a stable in-kernel API which isn't something you can rely on with Linux in any area. Greg K-H's Stable API Nonsense article
http://www.kroah.com/log/linux/stable_api_nonsense.html
covers this in a bit of detail, and there's discussion in the kernel mailing list archives. Embedded audio is one of the areas that's fairly actively developed at the minute, right now there are a number of reasonable system designs which can't really be addressed without some refactoring and newer audio hardware presents new opportunities for the kernel to improve performance.
participants (2)
-
Brian Welch -
Mark Brown