Home About Community Download Documentation Planet

PulseAudio miniconference 2014 Düsseldorf

The miniconference will be co-located with LinuxCon Europe and a bunch of other conferences (CloudOpen Europe, Embedded Linux Conference Europe, KVM Forum, Linux Plumbers Conference, GStreamer Conference). A badge for any of the main conferences should get you access to the PulseAudio miniconference.

  • Time: Wednesday 15th October, starts at 14:00, ends when we're done (we have the reservation for the rest of the day)
  • Place: Congress Center Düsseldorf, Room 111

You might also be interested in the Audio Mini Summit that is held on Tuesday.


If you want your name in the list below (or remove it from the list), and you don't have write access to the wiki, please send a mail to tanu.kaskinen@linux.intel.com or to the PulseAudio mailing list.

Registering for the miniconference isn't mandatory, but we will have seats only for 10-20 people (the exact number will be clarified if necessary, the probable seating plan has seats for 18 people). If it turns out that this event is hugely popular, and we don't have enough seats, the ones who registered (i.e. are listed here) will get preference.

  • Tanu Kaskinen
  • David Henningsson
  • Peter Meerwald
  • Arun Raghavan
  • Colin Guthrie
  • Alexander E. Patrakov

Topic suggestions

If you want to suggest topics, please send the suggestions to the PulseAudio mailing list.

  • Resampler quality evaluation

    • Proposed by: Alexander
    • Which resampler implementations should be kept and which removed as clearly inferior in all aspects? Should the default be changed? If one default resampler doesn't suit everyone - what are the relevant use cases and their acceptance criteria in terms of quality, battery life or whatever else?
  • Extraction of low frequencies into the LFE channel

    • Proposed by: Alexander
    • How should we implement this? Tanu has suggested that we'd add support for multiple remapper implementations that could be chosen by a policy module on a case-by-case basis. This would require some new infrastructure in the core. Is that the way to go?
    • Some discussion: http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/21508
  • Routing patch status update

    • Proposed by: Alexander
    • What does the huge set of routing patches achieve? Some kind of a demo would be nice. What needs to happen in order to get those patches merged?
  • Audio groups

    • Proposed by: Tanu
    • Audio groups allow applications to control the volume of a group of streams (and in some cases devices too). Audio groups are implemented in Tizen's volume API, can we get the feature in upstream too? Core or module?
  • Stream and device objects

    • Proposed by: Tanu
    • As part of the volume API, Tizen provides also an API to handle streams and devices at more abstract level than the normal introspection API. There are stream objects that cover both sink inputs and source outputs, and device objects that cover sinks, sources and ports. Is there interest in having this abstraction also in upstream? If yes, core or module?
  • Getting rid of filter sinks

    • Proposed by: Alexander
    • Filter sinks are currently the best way to add signal processing to an audio path inside PulseAudio, but it has its problems. Many people want a better solution, but can we find any volunteers to do the work? What should the better solution look like?
  • Dynamic PCM for HDMI

    • Proposed by: David
    • When we talked about this two years ago, David's idea was to make pa_card instances that would appear and disappear as HDMI was plugged/unplugged, but since, profiles have gained availability. Maybe we could keep the pa_card as it is and instead change the availability of the profiles as the HDMI devices are plugged in and unplugged.
  • Reasons and mitigation ideas for bad rewind handling code

    • Proposed by: Alexander
    • Suggested priority: low
    • We have zero virtual sinks with a correct rewind implementation, and also had a submission of module-xrdp-sink with a rewind implementation even though having no rewind support would have been better in that case. Why does this happen? What technical and social measures (e.g. wiki content or comments in the code or whatever else) would help people avoid writing incorrect code here?
  • Automated testing status

    • Proposed by: Arun
    • We currently have some automated testing, but this is hardly comprehensive. What would it take for us to have a test suite that we could rely on to make us confident enough to just ship tarballs?
  • Flat volume usability

    • Proposed by: Arun
    • There are certain use cases where flat volumes don't serve their purpose of improving usability. Mainly, this is to do with not reducing sink volume when sink input volumes are decreased, which makes tweaking master volume less effective. Should we be reducing sink volume on sink input volume decrease?
  • Browser volume handling

    • Proposed by: Arun
    • Reawaken the discussion on per-stream flat volumes vs. volume groups vs. relative volumes, and try to find a way forwards.