Zakhar Levchenko kirjoitti: > Hi, > > Now for almost all devices syncstart is emulated with a sequence of > SNDCTL_DSP_SETTRIGGER calls. I want however to have a possibility to > start several devices really simultaneously for envy24ht devices (this > may be useful for instance for accurate synchronization of input and > output streams for recording full-duplex applications). As far as I > can see from audio core code, device driver adrv_sync_control is > supposed to be used for such things. However I can't quite understand > how it should work. handle_syncstart() calls sync_control for all > devices first with SYNC_PREPARE flag, then with SYNC_TRIGGER one. > These calls are independent so device driver does not know anything > about how many devices and what exactly devices it should start > simultaneoulsy. Without this knowledge device driver won't be able to > start several device at one time even if sound card supports this. This is correct observation. The delay between starting different devices is as minimal as it can be. However there is no way to start multiple sound cards exactly at the same instant ot time. The "PC" architecture has no support for this feature.
So you will be able to start all sub-devices of given sound card at the same moment (provided that the driver has been modified to support it). However there will be minimal error if you try to start two or more sound cards (even if they share the same driver). > Now I could find the only way to do what I want: > Device driver supposes that for all devices SYNC_PREPARE should be > called fisrt, then SYNC_TRIGGER for the same devices. Thus it > memorizes the last device for which SYNC_PREPARE was called. When > SYNC_TRIGGER are called driver links all devices into a chain and > starts all devices when a SYNC_TRIGGER is called for the device > memorized on SYNC_PREPARE stage. But it's quite tricky, besides I see > some potential problems: The idea is that the driver remembers which sub-devices have added to the sync group during the SYNC_PREPARE step. The SYNC_TRIGGER step will start each of them by using an atomic write to a common "start" register. This doesn't work properly with multiple sound cards because they all have private registers for this purpose. If the planets are in correct positions then all devices will start during the same sample period. However in the worst case there will be significant slag between the devices. > 1) handle_syncstart potentially may be terminated prematurely, in this > case some devices may get SYNC_PREPARE command without SYNC_START, > it's rather confusing situation (it depends of course on sync_control > implementation, this is not a problem for the approach described above). If syncstart is terminated prematurely then none of the devices will start at all. This should not be possible unless the application gets killed between SNDCTL_DSP_SYNCGROUP and SNDCTL_DSP_SYNCSTART. Even in such case the situation will be cleared when the devices get closed and opened for the next time. > 2) If several processes call syncstart in parallel, the order of > sync_control calls may be totally messed up, in this case it's rather > difficult to predict driver behaviour. It is not possible that the same sync group gets started by multiple applications at the same time. If it happens then it's an application design error. It is possible to have multiple sync groups and to start them independently in any order. However to start any of the (parallel) groups the application that calls SNDCTL_DSP_SYNCSTART needs to know the right group ID. This can only happen if the original application communicates the group ID to some other process. > So my questions are: > 1) Is there any sane and simple (not so tricky) way to start several > devices simultaneously with the current framework? Maybe I missed > something? The current approach is perfectly sane but (kind of) limited to single sound card. There will not be any way to start multiple sound cards reliably at the same time until the (PCI) hardware layer is modified to support this. > 2) What about potential multi process problems? Wouldn't be worth to > use a lock in handle_syncstart itself? I don't see there any multi process problems unless some bogus application creates them. > 3) I'm not sure about that, but may be there is a way to improve the > framework itself (this probably may require changes in some drivers > though)? I understand that syncgroups may contain devices belonging to > different sound cards etc, this complicates things a lot, but anyway... In case of multiple sound cards the SYNCSTART approach works as well as it can. In software level the start operation is atomic which guarantees that all the devices will start within few microseconds. However there is (and cannot be) no guarantee that that the start is "sample-acurrate". Best regards, Hannu _______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
