Organisation
Gold Sponsors General Sponsors 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 |
Main /
AudioInfrastructureSUMMARYpulseAudio 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:
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. |