On Wed, Jan 05, 2011 at 04:20:04PM -0800, Stephen Warren wrote:
One of the nice things about ALSA on desktop is that everything just works without having to fiddle around setting up routing etc. from user-space e.g. using alsamixer or custom code.
If you look at the desktop case on a modern system a fair chunk of the configuration is actually being handled by PulseAudio rather than the driver - the driver exposes a standard view of the cards but Pulse figures out how it should be configured. Probably at some point after the media controller API (or something like it) makes it into mainline we'll start to see some efforts at similar managment for embedded systems, but the diversity of the hardware makes this a much more difficult problem.
Isn't ASoC attempting to set up a reasonably good routing/configuration on a per-board basis, driven by knowledge in the machine (board?) driver? Then, let people tweak it /if/ they want? It kinda sounds like you're pushing for a
No, it's delegating everything to userspace.
model where simply loading the driver may or may not have things set up right, then one has to configure everything from user-space before audio will work. Am I grossly misunderstanding?
No, that's exactly it. The bulk of the reason is that the hardware is very diverse, plus the fact that the edit/compile/run cycle for dropping the configuration into the kernel is pretty slow and painful and it's very hard to maintain stuff in mainline when you can't test the settings.
You can't do stuff in the CODEC driver because everything depends on the system and what physical configuration it has, plus user taste. Doing stuff in the machine driver means you're very fragile in the face of any changes in the CODEC driver (and CPU drivers as CPUs get more functionality) and means that stuff is still in the kernel.
Things get even more entertaining when you consider that things like smartphones can have vastly different configurations depending on the use case they're using - it's often not just a case of tweaks, it can be a substantially different setup.
Worse, if you hard code stuff into the kernel you end up causing pain for userspace people when they want to change use cases - they own part of the configuration but not all of it, which increases the coupling between the software components in the system. Adding a new use case becomes much more likey to require kernel changes (and consider what happens on a board that's used by multiple userspace groups, all of who may have diverging ideas of what's the optimal setup for any given use case).
Related to this, there's a lot of code in the-original-Tegra-driver-that-I- based-my-submission-on which pokes all kinds of registers in the codec from the machine driver to set up recording; e.g. mic mux selection, mic volume or gain, bias on/off, mono/stereo etc. based off detailed knowledge of the Harmony board. Seaboard, Ventana, ... would have similar but subtly different configuration logic. I stripped this out to simplify things initially. Is such configuration not meant to be part of the machine driver, but provided by manually setting everything up with alsamixer for example (and perhaps shipping a saved alsamixer state file)?
The intention is that userspace would ship a bunch of different configuration files here; you should never be configuring any of this stuff in kernel space. When used in conjunction with mainline drivers such register writes are often actively disruptive - they overwite settings applications might try to change, confuse the internal state of the CODEC driver or otherwise upset things. Stage one when people run into issues is often to strip such code from drivers.
Bias management in particular should never be being done from the machine driver - the ASoC core may well get confused if you do that by hand.
Both basic alsa-lib and UCM have support for loading different configurations based on board name, and userspace can in general do whatever it likes to handle per-board setup - what makes sense is going to vary depending on how the application layer is set up.
Oh, hrm. That wasn't clear from your code. Would mapping controller n to port n work for Harmony?
Yes, Harmony just happens to use controller ID 1 and port ID 1.
OK, then the straight through mapping sounds like a good bet for initial submission. If we don't get better support in before 2.6.39 goes out then we can always expose the API to machine drivers as a stopgap.