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 > client > > between client connects. So the next time the same client connects, > > module-volume-restore will not assign its streams to the default sink > but > > 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 > the > > current default sink (by default pulseaudio uses the default sink for > any > > new sink-inputs). However, if the client disconnects and connects again, > it > > 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 previously)? Ritesh -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20071219/233a78b9/attachment.htm>