2011/8/14 Tanu Kaskinen <tanuk at iki.fi>: > So the problem is that after unlinking the sink, there may still be > pending volume changes. The crash could be worked around, in addition to > your solution, by removing the assertion and calling s->write_volume() > only if it's set, or by removing reset_callbacks() from > pa_sink_unlink(), or by adding a check to the beginning of > pa_sink_volume_change_apply() that returns immediately if the sink is > not linked. This third approach is what I've taken in the first patch. However, that did make the second patch necessary. Is this the right way to fix that, or is it a sign that this whole approach is faulty? Maarten > What would be the correct solution? I think the sink implementation > (alsa sink in this case, I assume) should tear down the "audio > link" (ie. close the alsa device in this case) already when the sink > state gets changed to unlinked. Currently at least the alsa sink closes > the device only after pa_sink_unlink() has finished. If we can assume > that the device is closed after the sink implementation has had the > chance to do it in the PA_SINK_MESSAGE_SET_STATE handler, the pending > volume changes can't do anything useful anymore, so we can drop all > pending volume changes in the PA_SINK_MESSAGE_SET_STATE handler of > pa_sink_process_msg(). > > -- > Tanu
