From: Michael R. <mr...@us...> - 2003-11-15 16:10:05
|
Hi Miguel, > yes, i got that before. even though, strictly speaking, the slave > metronom idea also follows the "one metronom to rule them all" > principle. it does not implement a new metronom, just wraps the > existing one... it's a "metronom fellowship" :) > > seriously, i'd be slightly inclined to the slave idea, but both > approaches seem very good to me. I just realized that the slave idea has some additional benefit: It automatically accounts for sound card drift. My solution does not. So the slave (or, speaking in some more movie titles: master and commander ;) ) idea it is. If noone else wants to start, I could have this done by tomorrow morning. But some clarification would be good: * Should the slave have the same metronom_t interface or should it have a new, more limited slave_metronom_t interface, only providing the got_* functions? (I think it should, as Thibaut initally suggested, have the same metronom_t interface to hide the details from the metronom clients.) * Should the functions a slave should not use be dummies? (That is: discontinuity handling is not used by slaves.) * When reading vpts_offset from the master, shall we lock the master? (I think so, since reading an int64_t is not necessarily atomic.) * Should slaves be allowed to set their own options (like av_offset) or should these be passed on to and copied from the master as well? (I think the latter is more useful. This way, the av_offset of the master would also apply to the viz plugins.) Michael -- printk("VFS: Busy inodes after unmount. " "Self-destruct in 5 seconds. Have a nice day...\n"); 2.3.99-pre8 /usr/src/linux/fs/super.c |