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 <[email protected]>
---
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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
