Stéphane Letz wrote: > > 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. > > There must be enough data written to the playback device. It can be silence or valid audio data (if available).
> >> 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. > Correct. > 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? > These calls can be used in all cases. However I'm not 100% sure if Boomer supports it. Hannu _______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
