Recent Changes - Search:

Organisation


Gold Sponsors

 CSIRO
 Vquence
 NICTA
 LA

General Sponsors

 Annodex Association
 CeNTIE

The CeNTIE project is supported by the Australian Government through the Advanced Networks Program of the Department of Communications, Information Technology and the Arts, and the CSIRO ICT Centre.

Endorsed by

 ACS

PmWiki help

Organisers Only

edit SideBar

AudioInfrastructure

SUMMARY

pulseAudio appears to be central to most of the discussion. It's not going to restrict user choice, but it'll provide a default that just works in 99.9% of cases. PulseAudio? provides lots of frame and samplerate conversions automatically.

Issues:

  • simple flexible API that doesn't require writing sample rate conversion
  • jack on top of pulseAudio or pulseAudio on top of jack
  • hardware autoconfiguration
  • echo cancellation - should it be in pulseAudio?

Goal: lots of feedback on pulseAudio development to make sure it works for the majority of applications

Goal: a common recommended way to do audio for the future - best practices

Breakout A (Audio Infrastructure)

 Andre, Jan, James C-D, Julien, Ralph, Conrad, Leonart, Jean-Marc, Mikko, Mike, Bill, Shane, Erik, Silvia

 (1) Real-time audio effects and filters

 (2) Audio and video I/O configuration
 Mikko: HAL has some stuff going on here.
 Leonart: pulseAudio implement plug 'n play using HAL.  Load drivers into
 sound server whenever HAL event is detected.  Can (e.g.) automatically switch 
 playback between external and usb speakers when plugged in.
 Julien: would be nice to switch in real time like dmix
 Leonart: pulseAudio does this.  Lots of properties in HAL that let you know
 information about the device, so it's very clean.
 J-M: where should we be going in terms of applications?  Stick with ALSA?
 Ralph: currently, yes.
 Leonart: device listing capability being added to libasound?  Doesn't seem to 
 make sense as it's already in HAL.
 James: problem, get device name but alsa abstracts that.
 Leonart: we talk to card and device using numbers reported in HAL
 James: doesn't work with all cards, eg creative cards.  The abstraction in ALSA
 allows you to direct to particular speakers.  Shouldn't use "hw:" names, should 
 use abstraction names like "front", "rear", "surround5.1", etc.
 Conrad: are these hardware devices?
 James: no, libasound.  There's a default one for a sensible default
 Leonart: but it's not always sensible, e.g. uses dmix when not wanted 
 (pulseAudio)
 Mikko: what about bluetooth?
 James: currently it works incorrectly, but we're not implementing
 Leonart: problem: pulseAudio opens device once, then routes internally to 
 enable multiplexing.  Should I open the highest resolution I can and do
 copying / upmixing?
 James: yes.
 Leonart: I don't want to do samplerate conversion in alsa - I need to do it
 in pulseAudio.
 James: you should use "front", it's a raw hardware device + the correct routing
 to get to the appropriate speakers.
 -> conversation moves offline between James and Leonart.

 Jan: so PulseAudio? replaces dmix and esd.
 Leonart: yes
 James: why replace dmix?
 Leonart: latency, bumpiness in timing, limitations
 James: this sounds like bugs that need fixing, not a need for a whole new 
 layer
 Conrad: pulseAudio supplies much more to the applications as well, e.g. volume
 control etc.  It just happens to reimplement dmix as well.
 Mike: also pulseAdio could provide a portable API while Alsa doesn't.
 Jan: does things that are hard at alsa level like autoswitching to new device
 and auto volume adjusting when doing so.
 Mike: we want a sound server somewhere, and there should only be one.  Alsa is
 more at the level of an audio device.
 Leonart: yes, alsa is essentially the hardware drivers.
 J-M: in the longer term, assuming everything switches to pulseAudio.  Should it
 go through libasound, or the kernel layer directly?
 James: well, libasound is designed around as little as possible going on in
 the kernel, but with everything above libasound looking as similar as possible.
 Leonart: we don't want to replace libalsa, just some of the plugins like 
 "plug:hw"  

 Jack
 Conrad: needs to be able to access hardware directly for timing.  Talking to
 dmix or plug:hw is bad.  Applications have to meet demands of Jack.  PulseAudio?
 should be able to not meet Jack's demands and not get kicked out (desktop app)

 alsa <- jack <- pulse is one possibility.
 Leonart: can do, but wouldn't recommend.  Too many process transitions.  Trying
 to embed jack into pulseAudio.
 (e.g. alsa <- pulse <- jack)
 Conrad: Jack developers would prefer it the other way around.
 Leonart: it works by jack being in same process as pulse, jack still pretty
 much plays directly to alsa, but sometimes pulseAudio injects sound too.
 James: but jack audio users don't want anything pulseAudio has to offer
 Andre: you don't want to have to manually switch over
 Conrad: it's important that the same guarantees get offered by jack.
 Mike: and it should have the same API, but it doesn't have to be jack.
 Leonart: can currently run pulse on jack, or jack on pulse.  embedding is a 
 long term goal, as it's a cleaner solution; but not going to happen soon.
 Julien: big problem with configuration of jack.  Needs better defaults, and
 better manipulation of permissions.
 Leonart: Ubuntu will be shipping code to automatically shut down pulseAudio
 when jack is started up.
 Julien: does pulseAudio support multiple channels, etc.?
 Leonart: yes.  We don't support codec channels yet, but it's on the Todo list.
 Julien: what about arbitrary channels, like 17 to this, 3 to that?
 Leonart: yes, that works. 

 Simple Audio API
 J-M: it would be nice if people could write audio applications without spending
 ages learning difficult APIs?.
 James: what will those people be doing? There's 4-5 different methods for 
 different people in libalsa.
 J-M: the problem is that everyone pretty much gets it wrong.
 Ralph: what are they getting wrong?
 J-M: setting period size, buffering issues
 James: period size: it's very difficult, but alsa provides exactly what the
 hardware does.
 J-M: a sound application should like like:
   open device
   take data at this frame size and this sample rate
 shouldn't have to happen in every application.
 James: best way to get sounds to soundcard is using callback method.  Soundcard
 requests sound rather than application pushes sound.
 J-M: the thing that happens with that is every application needs to convert
 between frame sizes and samplerate sizes.
 Mike: shouldn't be writing to libasound API then.
 J-M: well what API should I use then?  
 Leonart: Not pulseAudio.
 Andre: can you do what J-M wants with pulseAudio?
 Leonart: yes.  Should use alsa compatability on top of pulseAudio.
 James: does it use callbacks?
 Leonart: both methods due to number of compatibility layers.  The number of
 compatibility layers is why I'm worried that pulseAudio is not the best
 API - it's massive.
 J-M: should only be a few lines of initialisation.  Should be simple like
 OSS is (libalsa currently takes many more lines to do the same thing). 

 Leonart: one issue with pulseAudio at the moment is that (e.g.) AC3? streams 
 can't be routed directly to SPDIF
 James: libalsa gets around it by providing an spdif target device
 Leonart: this means that AC3? data can't be mixed or supported when there's no
 hardware layer, but that's OK.

 OSS emulation
 Julien: main problem is evil mmapping (especially if binary only)
 Leonart: there's a character device that Monty's building that allows user
 space emulation
 Ralph: does it actually exist?
 K: have you seen the code?
 James: will it do mem mapping though? 

 Julien: professional multichannel support in libalsa - will chase up with James later. 
Edit - History - Print - Recent Changes - Search
Page last modified on January 13, 2007, at 10:00 AM