[pulseaudio-discuss] [PATCH 08/11] client: Allow client to receive the srchannel memblock

[David Henningsson]

On 2014-05-29 12:37, Tanu Kaskinen wrote:
> On Tue, 2014-05-27 at 14:27 +0200, David Henningsson wrote:
>>
>> On 2014-05-06 13:59, Tanu Kaskinen wrote:
>>> On Tue, 2014-04-29 at 17:29 +0200, David Henningsson wrote:
>>>>
>>>> On 2014-04-29 15:22, David Henningsson wrote:
>>>>> We assume it's an srchannel memblock if it is writable and does not come
>>>>> from our own mempool.
>>>>>
>>>>> In a future implementation, maybe we can have more than one
>>>>> srchannel open at the same time, but at this point we only
>>>>> support one.
>>>>>
>>>>> Signed-off-by: David Henningsson <david.henningsson at canonical.com>
>>>>> ---
>>>>>     src/pulse/context.c  | 26 ++++++++++++++++++++++++++
>>>>>     src/pulse/internal.h |  1 +
>>>>>     2 files changed, 27 insertions(+)
>>>>>
>>>>> diff --git a/src/pulse/context.c b/src/pulse/context.c
>>>>> index f3adf4c..7456ee5 100644
>>>>> --- a/src/pulse/context.c
>>>>> +++ b/src/pulse/context.c
>>>>> @@ -213,6 +213,11 @@ static void context_unlink(pa_context *c) {
>>>>>             c->pstream = NULL;
>>>>>         }
>>>>>
>>>>> +    if (c->srmemblock) {
>>>>> +        pa_memblock_unref(c->srmemblock);
>>>>> +        c->srmemblock = NULL;
>>>>> +    }
>>>>> +
>>>>>         if (c->client) {
>>>>>             pa_socket_client_unref(c->client);
>>>>>             c->client = NULL;
>>>>> @@ -338,6 +343,17 @@ static void pstream_packet_callback(pa_pstream *p, pa_packet *packet, const pa_a
>>>>>         pa_context_unref(c);
>>>>>     }
>>>>>
>>>>
>>>> Btw, I wasn't sure if the below is a good heuristic for figuring out
>>>> whether this is an srchannel memblock or not. I was considering
>>>> (ab)using pa_seek_mode_t instead, i e, add a new seek mode indicating
>>>> that this is an srmemblock. What do you think?
>>>
>>> It would nice to have explicit information available. What would you
>>> think about adding a new memblock type, or adding function
>>> pa_memblock_is_srchannel_buffer()?
>>
>> Hmm, looking at the code now, it feels somewhat wrong to have that
>> information on memblock level.
>
> Yes, but I don't have better suggestions. The problem is that
> transferring memblocks and tagstructs is handled with completely
> different APIs. I'd like to send the srchannel buffer as part of the
> "enable ringbuffer" command, but currently there's no way to include
> memblocks in tagstructs. Changing the code to allow this doesn't seem
> easy, but if you want to try, that would be great.

Good point. If we don't want to change all the APIs, the second best 
would be to send the enable command first and the memblock directly 
after, and make that restriction part of the protocol (an enable 
ringbuffer command must be directly followed by its memblock).

Will do that for next revision.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic