On Dec 17, 2007 11:29 AM, Tanu Kaskinen <<a href="mailto:tanuk@iki.fi">tanuk@iki.fi</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Mon, Dec 17, 2007 at 01:23:53AM -0500, Ritesh Kumar wrote:<br>> That works. However, now it seems that the current default sink is also used<br>> for any new sink-inputs. I was hoping that the client would be associated to
<br>> the default sink when it connected and any new sink-inputs from the client<br>> always went to that sink. Seems more intuitive, doesn't it?<br><br></div>I'd say the intuitiveness depends on whether one's intuition
<br>says that the client connects to a sink (routing decision<br>done at client connection time) or to the pulseaudio daemon<br>(routing decision done at stream creation time). The<br>asynchronous client API supports the view that client
<br>connects to the daemon, because the desired sink is supplied<br>only when creating a new stream.<br><div><div></div><div class="Wj3C7c"></div></div></blockquote><div><br>I guess you are right... probably I will write a module on the lines of volume-restore to achieve the effect I need. I seems intuitive to me because the media player that I use (quodlibet through alsa-pulse), creates a new stream for every song (I don't know the details but I am guessing that every media player may need to do this because different songs can have different sample rates/formats). This causes subsequent songs from the same media player to move to a different sink if the default sink is changed... which in my view is non-intuitive :).
<br><br>Thanks for your comments.<br><br>Ritesh<br><br></div></div>