Audio: ALSA UCM, Pulseaudio and Android

ALSA UCM

  • Liam
    • ALSA Use Case Management
    • Intention of UCM to abstract mixer controls in a simple high-level API
    • Allows the underlying analog or routing to be abstracted from the application
    • Can also be used to query sound block for their hardware volume controls for each use case
    • Relieves the application from needing to know about the hardware
    • Kiko: can the application query what outputs the device supports
      • On the first level the UCM API provides what use cases the device supports
    • UCM uses configuration files
      • Defines use cases which describe what sort of use cases the user might trigger
        • Examples: Voice Call, HiFi, FM Digital, FM Analog

    • Example: While listening to music, you receive a phone call, UCM allows the application to adapt use cases
    • Zach: is there a way to introspect the current status?
      • Liam: commandline tool called alsa-ucm allows querying what is currently happening (in alsa-utils 1.2.4)
    • Zach: available for Android
      • Liam: intention to make part of the library available dual-licensed for adoption within Android
    • [Missed description of hifi use case]
    • Driver originally had to deal with all transitions in state, and required modifying the driver code to better handle them
    • Benjamin: how many use cases can you define?
      • Liam: no limit, you can do quite a bit
  • Relevant Linaro work candidates
    • UCM Integration and validation
    • PulseAudio

      • Would like a complete UCM implementation; slimlogic would be okay with providing a basic implementation, but doesn't have bandwidth or experience to implement this. Probably looking for help.
        • ACTION: study implementation of UCM support
    • Configuration file repository
      • Would like to provide a release for OSVs to pick up a complete set of configurations for different hardware, along with an installer to pull and update it.
        • ACTION: Look into implementation of this as well
    • AudioFlinger

      • Simon: looks like a bit more than Android need; looking to reduce the amount of complexity to fit it into their plans. At any rate, the idea of simplifying mixer control is compelling.
      • Liam: pointing out that are looking to relicense code to make it directly usable by Android
        • ACTION to determine what license would be ideal to use; send out email summarizing
      • Might fit into tinyalsa, definitely something that would go into salsa
      • AudioFlinger stack power analysis

        • Analyzing buffer states and wakes per second to evaluate power consumption
        • Simon: Eric would be the best person to talk about this, will look into it.
  • Stack overview
    • UCM configs are shareable between Android and Linux
    • Android stack changes involve changing AudioFlinger to make use of use cases

PulseAudio

  • Initial work on PulseAudio by Margarita (sp?) now handled by Graeme, but very basic and unfamiliar work for Graeme. Aim to get this upstreamed and flesh out implementation.

    • ACTION: need to raise with Graeme what work remains to be done
    • ACTION: collect feedback from Pulseaudio/Colin/Lennert on the implementation
      • Liam: Apparently are interested in getting more than the basic functionality provided
      • Question as to whether this is because they are unconvinced about the solution, or whether they just want someone else to write it?
        • Kurt: this is something that PA does want, just looking to get someone else to implement it
        • Liam: PA are requesting policy management as well; policy manager would specify how the use case transitions are triggered when events happen
          • How would the policies be implemented? Hardcoded today, implement as configuration?
            • UCM Modifiers are designed to implement handling transitions; control layer should however be implemented in the framework
      • Graeme to provide more detailed work breakdown
      • Steve: Phone connected to a computer which is playing music -- phone rings and fed analog into the computer. Would like the ring to be played via the computer, and for the feedback volume to be adjusted. How is that done?
        • Kurt: how does ALSA/alsa-lib cope with an event triggered by a hardware event?
        • Discussion around coping with hardware mixer, and other situations in which Pulseaudio and Audioflinger are bypassed (not aware of a stream being processed).
        • How do you support low-power audio and hardware mixing via AudioFlinger

          • Software mixing is what's done today; hardware mixing could be supported, but platform variability has made this difficult.
          • Possible model for solution would involve maintaining centralized control in userspace, notifying it when hardware events might happen, and allowing it to control hardware mixing when it has to.

AudioFlinger

  • Android looking
  • tinyalsa conceived initially as a stop-gap solution; API could be reused however
    • still looking at alternatives; tinyalsa itself is on github: https://github.com/tinyalsa

    • salsa-lib might be an alternative is relicensed, as discussed above
  • AudioFlinger today is a software mixer

    • being able to use underlying hardware when available would be great
    • changing audioflinger to communicate via the HAL to operate hardware
    • audio-hal would be a UCM client; might have UCM implemented in tinyalsa
      • Simon: question as to whether UCM is standalone or part of alsa-lib
        • Liam: alsa-lib implements UCM, and would like to add it to salsa-lib
      • Where ALSA isn't available on the platform, UCM wouldn't either
  • Would implement use cases in audio-hal, which would use UCM as a lower layer
    • Kiko: unsure about how well this fits UCM, which AIUI is designed as a higher-level API to policy managers

Events/2011-06-MMWG/Audio (last modified 2011-07-12 19:03:20)