Define exact behaviour of .start() / .pause() / .stop()
#1357
Replies: 9 comments 9 replies
|
Im post-op right now at hospital, so i don’t know how lucid I am, why can’t we drain stop in web backend by instead of calling the normal user callback that time we just call fill_equilibrium |
|
because that wouldn't change how long hope your op went well |
|
All the best to you, @Marco-Farruggio! @LastExceed prior art:
No. It returns once the stream is transitioned to RUNNING (ALSA parlance). After that the data callback is allowed to fire.
No, same reasoning. What it should is that once it returns, the data callback isn't entered again.
Yes, bounded by the timeout, and yes, that makes blocking part of the contract. A
The web backends are the documented exception, not evidence against the rule.
Yes, but only internally to cpal and with silence. The line is that the data callback must not fire before
Option 2, discard. 1 is out because playing back audio that a user explicitly paused is a nasty surprise. You'd get a burst of sound on a stream that you asked to be quiet. 3 replays stale audio on
It does, and if it's not clear to you, it may not be clear to others, and is worthwhile documenting. |
|
Is |
|
When would it need to? I have difficulties to imagine when. The data callback always supplies a full buffer, so it shouldn’t need to append anything to flush. Or maybe depending on backend idiosyncrasies it might need to append one period of silence to ensure the last user buffer gets moved into DMA? As opposed to letting it underflow, but normal system APIs would handle that themselves. Other circumstances we should consider? |
|
WASAPI's ring buffer is not an integer multiple of the engine period, so the last period is incomplete. Our current implementation deals with this by effectively appending uninitialized memory, sleeping for the approximate duration of the buffered data, and then queueing a message for the processing thread to call I have also observed that both my native ASIO driver and WASAPI-exclusive mode consume the buffer continuously, rather than in chunks, which makes stopping exactly at the end of user provided data racy, and the only way to deal with that (that I can think of) is appending some silence and deliberately overshooting the goal |
|
Yes, in those cases we need to do something on a best-effort basis. They don't have an API to query the available buffer fill, do they?We could argue whether it's preferred to risk undershoot or to risk overshoot, and whether a millisecond or two will matter at all. |
WASAPI does have Thinking about it some more, I am actually becoming increasingly sceptical about the draining feature entirely. Even in WASAPI's case, the moment the padding reaches 0 is not necessarily the moment the last sample of user data has become audible. In fact, in shared mode it is guaranteed not to be, because after exiting the ring buffer, the data first moves to the sound server's mixing buffer, and we don't know how big that one is, nor how much more comes after that. The latter in particular is a problem that applies to every backend. We may be able to retrieve some latency information if the device manufacturer provided it (and if the respective backend supports it in the first place), but even if that information is accurate down to the nanosecond, we'd still be at the mercy of the thread scheduler to get the timing right.
This entirely depends on the use-case, and isn't something we should be deciding for users at all. The same probably goes for whether or not it is ok to append silence. I think what we should do is revoke the draining feature while we still can (since it is not released yet), and instead introduce an API for latency information (which we should probably have anyway). So if someone absolutely wants the best possible timing precision, then they can use spin-waits or whatever in their own code. There is also the question of how the potentially upcoming buffer depth option plays into all of this, which I'll have to think about some more... |
WASAPI already does that. Many others do too: #1129
Hard disagree. The draining stop addresses real community reports and non-intuitive behavior where "I fed the stream audio but it doesn't even play [in full] when I stop & drop [without my own plumbing]." The fact that it may be more accurate on one backend and less on another, does not remove its convenience.
#1129 worked it into the timestamps, but definitely we can consider exposing it separately as well.
They already could and still can without relying on what |
|
Does draining require anything platform specific on any backend? (other than knowing the buffer depth, which we just haven't abstracted yet) |
|
What were you thinking of? Some backends simply have an API call for it, like ALSA. That’s ideal. Buffering strategy currently is double-buffering everywhere, backends allowing (I’m talking buffer counts not sizes). |
Exactly that. Somehow this possibility had not occurred to me until now 😅 I rest my case.
WASAPI's ring buffer begs to differ (its total size is notably distinct from the period size)
Is there a word missing here somewhere? My brain fails to parse this part of the sentence |
"...backends allowing" ALSA, PulseAudio, WebAudio, AAudio, ASIO double-buffer.
I'm trying to say |
|
Sry I am very confused (probably language barrier). Can you try rephrasing the whole sentence please? |
|
I am trying to explain the representation of an audio ring buffer, which you may already know, but want to be sure that we’re on the same page. The way WASAPI’s shared mode represents buffers is not the norm. Plus, different backends use different words — period, quantum, buffer, length — and there is no single standard to say what’s wrong or right. What cpal calls a “buffer” (one data callback buffer) therefore does not uniformly map to how each backend calls it. An audio buffer is represented ring buffer containing a number of elements (periods; period count; buffer depth), and each element having a certain length (period size; quantum; length). The first period is the one in hardware DMA, the ones after it are queued in software to backfill the hardware DMA. This is true at the hardware level, even if backends have a layer on top of it. When the period count (buffer depth; number of periods) is 2, it’s called double buffering. 3, triple buffering, and so on. Typically the buffer depth is 2-4 where lower depth has shorter latency but higher risk of underrun. Today, cpal is hardcoded to attempt setting double buffering (period count of two) where it can. It can’t do that everywhere, like on WASAPI shared mode which because of its mixing and resampling has a layer on top of, at its core, the ring buffer mechanism I described above. This is true for CoreAudio, JACK, PipeWire as well.
I hope this clarifies. |
|
Turns out it really was a language barrier: "[...], backends allowing" being a short form of "[...] where the backends allow it" is a construct in english grammar which I simply was not familiar with, so the sentence's structure seemed broken to me (hence the question about potential missing words). Now that I understand this, I realize that my response is kind of dense, because subverting it is probably the whole point of the "backends allowing" bit +.+ so just disregard. The last message too has a few places where I suspect that my english skills are failing me, but ultimately, my point is already fully addressed by the fact that some backends feature dedicated draining functionaly. Idk how I didn't think of that myself, sometimes I'm just not very bright 😅 |
|
What should happen when |
|
No-op. After calling |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
.start()block until the stream is running? (e.g. when.start()triggers priming first).pause()block until the processing thread is ready to continue?.stop()block until the buffer is fully drained?.start()is called?.start()ed (populating the buffer), then.pause()d (keeping the buffer), and then.stop()ped (without another call to.start()in between)?Ok(())All reactions