[pulseaudio-discuss] default sink
ritesh at cs.unc.edu
Wed Dec 19 14:26:00 PST 2007
On Dec 19, 2007 5:10 AM, Lennart Poettering <lennart at poettering.net> wrote:
> On Tue, 18.12.07 16:11, Ritesh Kumar (ritesh at cs.unc.edu) wrote:
> > That's right... but module-volume-restore remembers the sink for the
> > between client connects. So the next time the same client connects,
> > module-volume-restore will not assign its streams to the default sink
> > one that it has saved.
> > Basically, I need a module which assigns the default sink to a new
> > connecting client and passes all its streams to that sink regardless of
> > current default sink (by default pulseaudio uses the default sink for
> > new sink-inputs). However, if the client disconnects and connects again,
> > should use the new default sink for the streams of the client
> > (module-volume-restore preserves the sink for the client between client
> > connects). The module could be called some thing like
> > module-preserve-client-sink or something.
> The problem is that currently not a single client I know is able to
> reuse its connection. I.e. each time a new stream is created it is
> created inside a new connection.
Oh... I see the problem in my previous logic now... the media player
reconnects as a *different* client (and a different sink-input). I was
wondering, is this because of the alsa API not having a client/sink-input
abstraction (and my usage for alsa-pulse for playback)? I took a brief look
at the alsa PCM API at
http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html ... and it does seem
to be the case from whatever I could tell.
> And thus I fear what you want to do is practically not implementable,
> unless you resort to evil hacks like basing your decision on timeouts.
Hmmm... that's too bad. Do you think directly supporting the pulse API in
the application will do the trick (along with the module I described
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pulseaudio-discuss