summaryrefslogtreecommitdiffstats
path: root/src/pulsecore/shm.h
diff options
context:
space:
mode:
authorTanu Kaskinen <tanu.kaskinen@digia.com>2011-02-24 16:16:43 +0200
committerColin Guthrie <cguthrie@mandriva.org>2011-02-26 10:40:06 +0000
commit6bd34156b130c07b130de10111a12ef6dab18b52 (patch)
tree08d635f07c2165c669eed2bfcd1310babed74e38 /src/pulsecore/shm.h
parentb3644c1bcd5f5d73fd2dc7b898e66b11ca3ad588 (diff)
virtual-sink: Fix a crash when moving the sink to a new master right after setup.
If the virtual sink is moved to a new master right after it has been created, then the virtual sink input's memblockq can be rewound to a negative read index. The data written prior to the move starts from index zero, so after the rewind there's a bit of silence. If the memblockq doesn't have a silence memchunk set, then pa_memblockq_peek() will return zero in such case, and the returned memchunk's memblock pointer will be NULL. That scenario wasn't taken into account in the implementation of sink_input_pop_cb. Setting a silence memchunk for the memblockq solves this problem, because pa_memblock_peek() will now return a valid memblock if the read index happens to point to a hole in the memblockq. I believe this isn't the best possible solution, though. It doesn't really make sense to rewind the sink input's memblockq beyond index 0 in the first place, because now when the stream starts to play to the new master sink, there's some unnecessary silence before the actual data starts. This is a small problem, though, and I don't grok the rewinding system well enough to know how to fix this issue properly. I went through all files that call pa_memblockq_peek() to see if there are more similar bugs. play-memblockq.c was the only one that looked to me like it might be broken in the same way. I didn't try reproducing the bug with play-memblockq.c, though, so I just added a FIXME comment there.
Diffstat (limited to 'src/pulsecore/shm.h')
0 files changed, 0 insertions, 0 deletions