[pulseaudio-discuss] [PATCH 02/11] pulsecore: srbchannel: Introduce per-client SHM files

Ahmed S. Darwish darwish.07 at gmail.com
Sun Dec 27 10:34:41 PST 2015


On Sun, Dec 27, 2015 at 02:10:47PM +0200, Tanu Kaskinen wrote:
> On Sat, 2015-12-26 at 21:51 +0200, Ahmed S. Darwish wrote:
...
> > 
> > > If I understand vacuuming correctly, it means telling the kernel that
> > > the memory in unused memblocks probably won't be used any time soon,
> > > and that we also don't care about the current data in them, so the
> > > kernel can optimize memory usage accordingly. pa_core_maybe_vacuum()
> > > only vacuums when there's no audio moving in the system.
> > 
> > That's what I understood from the code, yes.
> > 
> > > When you
> > > change rw_mempools to be created separately for each client, I think it
> > > would make sense to vacuum the per-client mempool every time the client
> > > stops streaming. That logic could live inside the native protocol, so
> > > the core wouldn't have to know about rw_mempools.
> > > 
> > 
> > I see, makes sense.
> > 
> > I've implemented this by vacuuming upon receiving CORK_PLAYBACK_STREAM
> > or CORK_RECORD_STREAM. Hopefully this is the right approach.
> 
> Do you take into account the case where there are two streams and only
> one of them stops? I think vacuuming should be done only when the state
> changes from "some streams active" to "no streams active".

Hmm, my knowledge is still limited in this area. I thought
there's a one-to-one relation between a per-client connection
and a stream. 

After some thinking, I guess this can happen when one client
creates both a playback stream and a recording one?

>
> In addition to corking, the active -> not active transition can also
> happen when the client tears down a stream.
>

PA_COMMAND_FLUSH_{PLAYBACK,RECORDING}`_STREAM?

Thanks a lot,

-- 
Darwish
http://darwish.chasingpointers.com


More information about the pulseaudio-discuss mailing list