I cannot figure this out from manual.
I dont have xruns but need to know if it does happen.
Questions
While recording a track, what does mixbus do when xrun occur.
Does it
1) Introduce a dead period equal to length of xrun and keep track timing accurate with a dead spot
or
2) just waits until it has data and join it to previous data before xrun encountered, in effect making the track shorter than actual without a deadspot but transition error where the xrun occurred.
Wch of the two is it ?
(07-28-2019, 11:34 AM)zimbodel Wrote: [ -> ]I cannot figure this out from manual.
I dont have xruns but need to know if it does happen.
Questions
While recording a track, what does mixbus do when xrun occur.
Does it
1) Introduce a dead period equal to length of xrun and keep track timing accurate with a dead spot
or
2) just waits until it has data and join it to previous data before xrun encountered, in effect making the track shorter than actual without a deadspot but transition error where the xrun occurred.
Wch of the two is it ?
I haven't tried to record anything in mixbus since version 4 but when a xrun occurred it stopped recording. Thats why I don't record with mixbus.
(07-28-2019, 08:46 PM)Pro-Doucher Wrote: [ -> ] (07-28-2019, 11:34 AM)zimbodel Wrote: [ -> ]I cannot figure this out from manual.
I dont have xruns but need to know if it does happen.
Questions
While recording a track, what does mixbus do when xrun occur.
Does it
1) Introduce a dead period equal to length of xrun and keep track timing accurate with a dead spot
or
2) just waits until it has data and join it to previous data before xrun encountered, in effect making the track shorter than actual without a deadspot but transition error where the xrun occurred.
Wch of the two is it ?
I haven't tried to record anything in mixbus since version 4 but when a xrun occurred it stopped recording. Thats why I don't record with mixbus.
This is adjustable in preferences. You can chose to stop recording if an xrun occurs, or continue. I continue recording. I have not had such major xruns that I have noticed them in the final recordings.
If you disable the preference to stop recording at an x-run, Mixbus does (2), because there is no way to accurately determine the duration of the x-run.
Tech-details:
Under the hood, x-run recovery on the driver-level flushes the buffers and restarts the stream (but that depends on the driver and OS, as well). An x-run's actual duration is not usually a multiple of the block-size.
When you use jack on Linux, jackd has a --clocksource option. The sole purpose of this is to determine x-run duration. But even so, it is not generally useful either, since it does not take kernel-side buffer alignment into account. It's mainly intended for dedicated systems.
(07-28-2019, 10:06 PM)x42 Wrote: [ -> ]If you disable the preference to stop recording at an x-run, Mixbus does (2), because there is no way to accurately determine the duration of the x-run.
It should be able to do (1), I cannot technically really see why it is impossible.Just keep recording.. the sound will be back at the right time.
I would rather have gaps than to sit with malaligned racks.
So x42, if you did have unfortunate xruns recording a track how do you realign?
A do-over would be disasterous in certain unique cases as a blank can be dealt with synthetically.
There must be a mixbus "art of realignment".
Technically, Mixbus just keeps recording. Mixbus' processing engine itself is not even aware that there is an x-run. Mixbus is only told by the driver that there has been a discontinuity.
To correctly recover like you suggested, Mixbus would have to explicily insert silence of the correct duration, except the audio-driver itself doesn't keep track of the passed time of under/over-runs..
The art is really called: tuning your system to work reliably without x-runs
(07-28-2019, 11:18 PM)x42 Wrote: [ -> ]The art is really called: tuning your system to work reliably without x-runs
Understood, that is why I record with large buffers with about 25ms latency.
No contest, as latency doesnt matter there.
But I have applications where I have to record and monitor with low latency as possible, and there are going to be sporadic x-runs which will cause alignment trouble.
I see it as trivial to implement accurate deadspace. I will request it as a feature as it has use.