Le 31 juil. 09 à 09:20, Hannu Savolainen a écrit : > Stéphane Letz wrote: >> Hi, >> >> Our jack OSS (or Boomer) driver uses a 2 threads model (one used for >> reading and one used for writing). In duplex mode, we typically open >> the input and output devices separately, then use blocking "read" on >> input side and blocking "write" on output side. Both threads are >> synched using semaphores so that we know when to trigger a "server >> cycle", that is when input have been read and ouput have been >> written. >> >> In some cases and some hardware (like RME MADI card), it seems record >> in not correctly started and the input stream shows some missing >> frames (like 128 frames of 0 value) or duplicated frames (like 128 >> frames repeated twice.) >> > This problem is specific for RME MADI. In hardware level all the > channels are bound together. When playback "DMA" engine is started > then > the recording engine will start too. If recording and playback streams > are not started as an atomic operation then some samples may get > lost or > inserted. >> It seems that the SNDCTL_DSP_SETTRIGGER ioctl (http:// >> manuals.opensound.com/developer/SNDCTL_DSP_SETTRIGGER.html) should be >> used for that. Is it still the case with OSS 4.0? >> > It is still the case. If recording and playback need to be started in > sync then SETTRIGGER or SYNCGROUP/SYNCSTART must be used. >> Are the following code example still correct? >> >> > They are supposed to be correct. >> http://manuals.opensound.com/developer/fulldup.c.html#LOC79 >> >> http://manuals.opensound.com/developer/iosync.c.html#LOC16 >> >> Any advice how to use SNDCTL_DSP_SETTRIGGER correctly? >> > SNDCTL_DSP_SETTRIGGER cannot be used with RME MADI because the input > and > output device files are separate. Instead you need to use > SNDCTL_DSP_SYNCGROUP and SNDCTL_DSP_SYNCSTART. See > http://manuals.opensound.com/developer/synctest.c.html for more info.
Thanks for the explanations. So it I understand correctly what is written in (http://manuals.opensound.com/developer/synctest.c.html ) like "In applications that record audio, process it and then play back it's necessary to write two fragments of silence to the output device(s) before starting the group" since "jack" server does exactly "Read/Process/Write" kind of audio cycle, I'll have to write 2 fragments of silence in may case before using SNDCTL_DSP_SYNCSTART. OK. > > This may be easier to do if the input and output threads are created > only after recording and playback have been started. The sync group ID > returned by the first call to SYNCGROUP can be communicated between > threads or processes if necessary but doing the setup in one thread is > easier. > > Best regards, > > Hannu > Ok. My driver has it's "main" thread that open input and output devices, configure everything, then starts the 2 input and output threads. So I guess the proper way to do is have the SNDCTL_DSP_SYNCGROUP stuff (and write the 2 silences fragments) be done in this main thread. One last question: I try to have only one code working for all cases, so my driver always opens different devices ID for input and output. Can the SNDCTL_DSP_SYNCGROUP/SNDCTL_DSP_SYNCSTART code be used in any cases? That is even for "consumer" kind of card where maybe the input and output device ID are actually the same? Or do I need to have two different code path? Thanks Stephane Letz _______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
