Re: Polypaudio for Gnome 2.10, the next steps

[Lennart Poettering <mztabzr 0pointer de>]

On Tue, 23.11.04 19:15, Mike Hearn (mike navi cx) wrote:

> The key point was grabbing the sound on a per-process basis from the
> lowest level possible rather than rewriting apps (or writing lots of
> drivers). It's kind of hard to hack the kernel to do this, so alsalib is
> the next level up where you can reroute audio. Currently you've written
> lots of drivers for different programs which is great but there are still
> ones you missed (eg Wine) or cannot change (because they only support OSS
> and have no driver framework) and therefore would need to use an
> LD_PRELOAD type wrapper. So why not have only one such wrapper program
> (aoss) and then redirect audio into Polypaudio at the alsalib level? There
> could be similar OSS level redirectors for other operating systems or they
> could deal with it at the kernel level.

There's "esddsp" which works fine with polypaudio, and I am planning
to add a new native tool "paoss". With that and the ALSA plugin I get
compatibility with virtually every Linux sound application, since OSS
and ALSA are the most common sound APIs on Linux and Unix.

> > BTW: I investigated to write an ALSA plugin for passing audio data to
> > polypaudio. Unfortunately the internal ALSA library API isn't flexible
> > enough for allowing such things without major changes (i.e. while the
> > external ALSA API exports multiple audio file descriptors for the
> > application to select() on, you don't have the ability to export more
> > than one fd from a single plugin. In addition to that there's no way to
> > change during runtime what to select() on: for readability, writability
> > or both).
> 
> I don't really understand this. Is it really impossible to have a plugin
> which either simply forwards data from the master to slave (ie is a 
> no-op) or writes it to a socket then just puts null data into the slave?
> That sounds like the simplest sort of plugin possible, it'd be pretty
> incredible if you could not do even that :(

Besides the pure audio samples you need to pass some meta data like
timing info and control data. This requires more work than simply
writing audio data to a socket. The plugin I have in mind utilizes the
normal polypaudio client libraries and behaves like a normal
polypaudio client. And that is far from being easy with the current
internal ALSA plugin API.

> That sort of thing would then sort of resemble what I was wanting, except
> would it be necessary to make it Polypaudio specific? Or could you do what
> I suggested and just write the audio maybe with timing data via a simple
> protocol to a domain socket in /tmp?  Then it would be usable by any
> program.

As far as I know there already is something similar: you can use an
SysV SHM based plugin to pass audio data between applications. See
http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html and
look for "plugin: shm".

Lennart

-- 
name { Lennart Poettering } loc { Hamburg - Germany }
mail { mzft (at) 0pointer (dot) de } gpg { 1A015CC4 }  
www { http://0pointer.de/lennart/ } icq# { 11060553 }