Saying about multi process issues I meant the following situation:
Suppose a souncard has 3 sub-devices 1, 2, 3.
There are two processes that create two different syncgroups, the first
group contains only subdevices 1 and 2, the second group contains only
subdevice 3.
Suppose they try to start their syncgroups in parallel, suppose
sync_controls are executed in the following order:
SYNC_PREPARE for sub-device 1 (1st process)
SYNC_PREPARE for sub-device 2 (1st process)
SYNC_PREPARE for sub-device 3 (2nd process)
SYNC_TRIGGER for sub-device 1 (1st process)
SYNC_TRIGGER for sub-device 3 (2nd process)
SYNC_TRIGGER for sub-device 2 (1st process)
(the last two calls are executed in "reversed" order)
This may confuse driver, if I implement, say, my idea, devices 1 and 3 will
be started simultaneously (instead of 1 and 2), as to device 2. the driver
just won't know what to do with it.
I hardly can imagine any situation when somebody will to try to do such
things on purpose, but from theoretical point of view it is absolutely valid
usecase. Both processes do absolutely valid things with potentially invalid
result. Should this be handled somehow or ignored because nobody does this?
Actually it is the only problem that bothers me.
Regards,
Zakhar Levchenko
On 6/8/08, Hannu Savolainen <[EMAIL PROTECTED]> wrote:
>
> 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
>
_______________________________________________
oss-devel mailing list
oss-devel@mailman.opensound.com
http://mailman.opensound.com/mailman/listinfo/oss-devel
