[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: F12: KDE and PulseAudio latest update

On Friday 01 January 2010 21:35:05 Terry Barnaby wrote:
> On the second question, does the design of PulseAudio allow an
> application, on an application by application basis, to choose to use
> a specific input/output device ? If not I would consider this a major
> failing ....

Of course, it wouldn't be of much use otherwise, right? :-) This is why it was 
written in the first place (among other reasons, like networked audio and 

> I would have thought that PulseAudio would, in effect, publish all
> of the available Alsa audio devices along with default. An application
> would then connect to default by default which would use the standard
> PulseAudio configuration but could use any of the other devices including
> other pulseaudio servers over the network.
> Each of these devices would be handled by PulseAudio (ie sound would
> pass through PulseAudio to/from the device in question).

Not completely sure, but the way I understand pulseaudio works is that it does 
*not* publish available Alsa devices to the application. If all the sound 
passes through the server, there is not much point for the app to know which 
device is going to be used for playing and recording. The app only sees 
pulseaudio input and output, and uses that. So which app uses which alsa 
devices is configured within pulseaudio (using pavucontrol), rather than in the 
app itself.

This is not the question of available functionality, but rather where the 
controls reside. It is similar to the functionality of an X server --- once a 
new app is started and it tries to draw its own window on the screen, it is 
not up to this app to decide where exactly will the window be drawn, but 
rather it is up to the window manager. It's window may be moved around, 
minimized, maximized, covered by another one, on this or that desktop, etc., 
and all this is done transparently, without the app knowing much about it.

The same thing is with audio server (of course, it's much simpler due to its 
nature) --- app talks to pulseaudio and says "I want to play something and 
record something", and the pulseaudio is the one to decide what will be the 
actual source and sink used for each particular app. So just like when you 
want to move the window around you give instructions to the window manager and 
*not* the app itself, so also when you choose this or that audio source/sink 
you give instructions to pulseaudio and *not* the app itself.

Finally, keep in mind that a proper audio server is there to enhance 
functionality, not to reduce it. :-)

HTH, :-)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]