Hi David Today I set out to write a new jack output plugin based on my experiences collected during my recent hacking on this topic.
I realized that it's crucial that there are absolutely no blocking calls in jack's process callback and the subsequent call hierarchy. This can be realized only if xmms_output_read is not used at all as in its call hierarchy multiple locks can occur. The reason for this is the real-time nature of the jack process callback. If it gets locked jack will consider this as an error because real-time callbacks can not be rescheduled. And rescheduling is what any lock will do. Therefore I changed the output plugin mode from thread driven (using the status callback) to xmms2 driven (write callback set). Now real state of the art jack programming comes into play: Use a so called non locking ring buffer (nlrb) and signal the blocking producer (the xmms2 write thread) by a polling condition (never try to lock a locked mutex). If the producer thread can not be woken up because it keeps the mutex locked in the wrong times, the condition times out and can fill the ring buffer independently. There are several advantages of this architecture: * We do not have to modify output.c or introduce any new stuff into the xmms core (will make the xmms crew happy!!). * Any callbacks of the xmms are handled much easier as none of them happens in the jack process callback context. A rate change interface for instance becomes very easy to implement. No timers or anything equally dirty. * The bug in the xmms output in the other plugin mode when reaching the end of the playlist is gone. I will report this to the xmms guys all the same (won't make the xmms crew happy :), but afaik there are few plugins using the output thread driven mode). * Underruns in the xmms (not x-runs) are identified easily and there are means how the user can adapt the settings to avoid them. This was much more difficult with the previous architecture. * I experienced no crash up to now, especially during the typically crash- sensitive operations like skipping and seeking, even with several rate changes. So perhaps we can just drop the extra git repos/trees and go over the existing ones. In the beginning of the next week I'll prepare a xmms-ish version of the plugin as it's currently spoiled with rate changing functionality which is too unportable to be included into the xmms. Then some testing can begin. Uli -- / uli franke / archas 199 / 7554 sent / www.nebadje.org / -- _______________________________________________ Xmms2-devel mailing list Xmms2-devel@lists.xmms.se http://lists.xmms.se/cgi-bin/mailman/listinfo/xmms2-devel
