[pulseaudio-discuss] Potential module: persistent-sink

[Chris Hamilton]

>> Is it possible to have a network sink and a local sink synchronized?  Or
>> multiple network sinks?  (In all cases, they have been combined using
>> module-combine).  I'm running 0.9.10, and use a module-esound-sink
>> because the module-tunnel-sink is extremely flaky (immediately get
>> buffer underrun complaints, and choppy sound out of the remote system).
>>  Using the esound sink, there is a noticeable lag between the two
>> systems, which one would think could be at least synchronized.  Any
>> feedback on this would be great.
> 
> Sadly the "correct" fix here is to make the module-tunnel sink work 
> nicer! In theory in 0.9.13+, it should be possibly to dynamically change 
> the buffering of the tunnel on the fly to cope with underruns etc. (not 
> 100% sure if it really needs 0.9.13 here but it certainly fits with the 
> glitch-free, watermark level stuff).
> 
> The esound protocol does not contain any information about 
> timing/latency to the best of my knowledge so it will be very hard to 
> get synchronised correctly.

I figured that would be the response I'd get ;)  I tried upgrading to
0.9.13 the other day, but it turned out there were too many dependencies
I was going to have to drag in (newer version of alsa, libspeex, etc)
that weren't in the Hardy repositories (my laptop currently runs hardy).
 I'd like to get my hands dirty with some development work, so I suppose
I'm going have to bite the bullet and perform all of the necessary upgrades!

>> Something that I would love to see one day (sooner rather than later):
>>
>> A virtual 'switchboard' type system for configuring pipes, where
>> connections are drawn with the mouse, etc.  This could have a nice
>> graphical and intuitive switchboard (with cables, etc) view, and a
>> simpler more compact matrix view (inputs on one side, outputs on the
>> other, combiners living as both inputs and outputs).  Ideally, this
>> would keep information about all past clients (even though they may not
>> be presently active), as well as past sinks (even through they may be
>> down temporarily).  Status of the sinks/sources could be indicated
>> through color.  A 'recursive' behaviour would be nice, wherein if the
>> local user had access, they could zoom into the switchboard panel of a
>> remote server as well.  Does this sound like something anybody else
>> would like to see?  I can easily put together a UI mock-up illustrating
>> exactly what I envision...
> 
> Please do some mockups. It's important to realise that pulse is not 
> jack, and this it's not really meant to be an all singing interconnect 
> type app, but IMO this kind of visualisation is quite nice.
> 
> I presume this interface would kinda be like a pavucontrol on steroids? 
> Viewing remote servers should be easy enough (effectively the same as 
> running pavucontrol via "PULSE_SERVER=remote pavucontrol").
> 
> Again, (as per my other mail) seeing non-active sinks and apps will not 
> currently be supported by the protocol (to the best of my knowledge) so 
> to get full feature out of this interface.

Yes, I was imagining a pavucontrol steroids, with a heavy focus on a
visual representation of what's going on (to make things quite easy for
beginners), and with the ability to drill as deep down into the guts of
things as possible.  I'll try and put together some mock-ups over the
next week to show what I mean.

And yes, modifying the protocol to be able to query for previous (but
not active) sinks and apps would be ideal, but can always come later.
Does the API allow querying for a list of plugins that are installed on
a server, with all of their metadata? (ie: name, description, parameters
plus default and valid values, etc)  This would be something else that
would be quite useful in such an application.

Cheers,

Chris