Re: [LAD] Fw: Re: Deriving a steady MIDI clock crossplatform?
On Thu, May 19, 2022 at 11:17:28PM +0200, Jeanette C. wrote: > Thanks both of you. Based on timed_wait, I looked at the boost libraries and > found two candidates in the Thread library: > conditional_varaible::timed_wait > and > thread::sleep_until > which can both take an absolute time. I suppose both should be equally > usable, since again absolute time can be calculated independent of the last > wait/sleep? Better check how this is implemented. It could just use usleep(). And then all precision is lost, even if the sleep times are adjusted to compensate for the latency of the previous event. Ciao, -- FA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Fw: Re: Deriving a steady MIDI clock crossplatform?
Thanks both of you. Based on timed_wait, I looked at the boost libraries and found two candidates in the Thread library: conditional_varaible::timed_wait and thread::sleep_until which can both take an absolute time. I suppose both should be equally usable, since again absolute time can be calculated independent of the last wait/sleep? Best wishes, Jeanette May 19 2022, Fons Adriaensen has written: On Thu, May 19, 2022 at 10:40:48PM +0200, Robin Gareus wrote: While there is a corresponding mach/clock.h, for the case at hand it is preferable to use Apple's Core Audio, CoreMIDI. MIDI Event scheduling is abstracted, and there is dedicated API to convert timestamped events with high precision: AudioConvertNanosToHostTime() and AudioConvertHostTimeToNanos() The problem here is not conversion, but what to wait for, In zita-convolver.h there is an implementation of sem_t for OSX (which only has a crippled implementation), using a condition variable. It doesn't have sem_timedwait(), (since zita-convolver doesn't need it) but that could be added quite easily. Ciao, -- FA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev -- * Website: http://juliencoder.de - for summer is a state of sound * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g * Audiobombs: https://www.audiobombs.com/users/jeanette_c * GitHub: https://github.com/jeanette-c If there's nothing missing in my life Then why do these tears come at night <3 (Britney Spears) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Fw: Re: Deriving a steady MIDI clock crossplatform?
On Thu, May 19, 2022 at 10:40:48PM +0200, Robin Gareus wrote: > While there is a corresponding mach/clock.h, for the case at hand it is > preferable to use Apple's Core Audio, CoreMIDI. MIDI Event scheduling is > abstracted, and there is dedicated API to convert timestamped events > with high precision: > > AudioConvertNanosToHostTime() and AudioConvertHostTimeToNanos() The problem here is not conversion, but what to wait for, In zita-convolver.h there is an implementation of sem_t for OSX (which only has a crippled implementation), using a condition variable. It doesn't have sem_timedwait(), (since zita-convolver doesn't need it) but that could be added quite easily. Ciao, -- FA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Fw: Re: Deriving a steady MIDI clock crossplatform?
On 5/19/22 22:27, Fons Adriaensen wrote: > Don't know about Apple. Last time I looked it didn't have clock_gettime(), While there is a corresponding mach/clock.h, for the case at hand it is preferable to use Apple's Core Audio, CoreMIDI. MIDI Event scheduling is abstracted, and there is dedicated API to convert timestamped events with high precision: AudioConvertNanosToHostTime() and AudioConvertHostTimeToNanos() -- robin OpenPGP_signature Description: OpenPGP digital signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Fw: Re: Deriving a steady MIDI clock crossplatform?
- Forwarded message from Fons Adriaensen - Date: Thu, 19 May 2022 22:22:12 +0200 From: Fons Adriaensen To: "Jeanette C." On Thu, May 19, 2022 at 07:52:33PM +0200, Jeanette C. wrote: > I know about one or two applications that use the timeofday/sleep mechanism, > but from first hand experience I know that these tend to drift and wobble. The key to do this is to have a high priority thread waiting for an *absolute* time, and then each time increment that time by the required delta. Note that this is fundamentally different from using sleep or similar functions. With those you wait for a certain time. So if your previous event was late, the next one will be late as well just because you start waiting for it too late. So all the errors will add up, and you will *never* get the correct event frequency. When you wait until an absolute time, any latency on the previous event does not affect the following ones. The errors don't accumulate. So what to wait for ? That could be any system call that takes an absolute timeout rather than a maximum waiting time. On Linux I'd use something like sem_timedwait(). To set the initial timeout, the corresponding clock can be read with clock_gettime(), using the CLOCK_MONOTONIC option. Don't know about Apple. Last time I looked it didn't have clock_gettime(), but it has gettimeofday(). Note that it is not gettimeofday() that is the cause of the problem you mentioned, it is using sleep() or usleep(). Ciao, -- FA - End forwarded message - ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Deriving a steady MIDI clock crossplatform?
Hey hey, I wonder how would you best derive a steady MIDI clock in software for a cross platform application? Cross platform in this case almost certainly means Linux and mac. I know about one or two applications that use the timeofday/sleep mechanism, but from first hand experience I know that these tend to drift and wobble. This becomes apparent when syncing a synth with clock synced delays to that clock. There is a slight chorus effect. Furthermore, subsequent renderings of the same song is too much out of sync. Exact re-runs are necessary with connected mono timbral instruments that have to contribute several sounds to the same song. I did think about using RtAudio with a very low blocksize. The callback function could supply a steady time source at the connected soundcard's samplerate (or any subdivision thereof). Is that feasible? Or will some function from any of the Boost libraries do? I haven't found the right one yet. The Thread library contains its versions of sleep (i.e. sleep_for) and other libraries supply all kinds of finely grained time formats. But apparently, they too are based on a timeofday based mechanism. Being new to this kind of task, I am a bit at a loss. So any practical pointers and hints are welcome. Best wishes, Jeanette -- * Website: http://juliencoder.de - for summer is a state of sound * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g * Audiobombs: https://www.audiobombs.com/users/jeanette_c * GitHub: https://github.com/jeanette-c If there's nothing missing in my life Then why do these tears come at night <3 (Britney Spears) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev