I'm having difficutly in getting this to work. I can eventually try to develop the sync code, but maybe, the manual time shift setting is sufficient in this case. Please, if you like, try the suggested solution. The above solution might be improved with the adaptive resampling, but the driver and/or the multi plugin in alsa-lib must be enhanced to do the clock sync. The minimal delay can be about 25-40ms - depending on the configuration. There is one drawback with this solution - the delay on the "monitoring" output from the alsaloop. I believe that you can find the shift value to keep the clock differences (clicks) at minimum. Also note that the sync mode for alsaloop must be 'samplerate', otherwise the alsaloop will try to play with the 'PCM Rate Shift 100000' (adaptive resampling), but this will not work in this case, because the goal is to keep sync with the primary sound card and alsaloop cannot be instructed to do it. You can control the drift manually using 'PCM Rate Shift 100000' control (see 'amixer controls' command on the command line when the snd-aloop kernel module is loaded). You can grab the returned samples using the alsaloop utility (in the alsa-utils package) and copy them with the resampling (not adaptive at the time) to the monitoring sound card. I think that the easiest solution - in this case - is to keep the primary soundcard in the multi plugin configuration and use the ALSA's loopback driver (snd-aloop) as the second "monitoring" output. Unfortunately, alsa-lib does not have this implemented. The solution is to put the adaptive resampling for one soundcard to maintain the clock differences. So, it's a design issue and not the problem with the multi plugin itself. Even if the clock drift is about 1%, the timing will be broken after some minutes, because the queue with samples for one soundcard will be empty or full (depending which consumer is the master for the multi plugin). There is no way to use same clock for them (the hardware limitation in this case). Both sound cards have own timing to "eat" samples. Basically, we have one producer (application) and two consumers (sound cards). As I wrote in e-mail, the problem is in the two clock sources.
0 Comments
Leave a Reply. |