* Master Plan on rewinding @ 2014-09-07 15:16 Alexander E. Patrakov 2014-09-07 18:38 ` Tanu Kaskinen ` (6 more replies) 0 siblings, 7 replies; 52+ messages in thread From: Alexander E. Patrakov @ 2014-09-07 15:16 UTC (permalink / raw) To: ALSA Development Mailing List, Takashi Iwai, David Henningsson, Takashi Sakamoto Hello. (TL;DR: nothing really new except the strawman proposal about threads and the note about interaction of variable sample rate with rewindability) As Takashi Iwai told me that the audio miniconference is for discussion only, and not for presentation of anything, I guess that I need to present the plans and options now. That's why this e-mail. The goal here, besides merely presenting the plan, is to identify points that everyone agrees upon, so that they are not discussed pointlessly at the miniconference. Also, this e-mail serves as a justification for the pending seemingly-destructive work. First, the status quo. If anyone disagrees with the facts below, please complain loudly, before I make any conclusions! 1. PulseAudio does not call snd_pcm_rewindable(), because for some ALSA plugins it crashed. This crash is completely fixed in alsa-lib 1.0.28, but in some cases snd_pcm_rewindable() still returns wrong results. 2. PulseAudio blindly assumes that it can rewind up to hwbuf_frames - (snd_pcm_avail() + rewind_safeguard) frames. The rewind safeguard is needed due to reasons that I don't completely understand, but one of them is imprecise reporting of the hardware pointer, and another one is that the hardware transfers several bytes at a time, and the bytes we need to overwrite may be already cached by the hardware. 3. On the hw plugin, I could demonstrate two other bugs regarding snd_pcm_rewindable(): stale data and bogus negative return values. 4. There are ALSA plugins like "a52" or the "bluetooth" plugin from old version of bluez that return non-zero for snd_pcm_rewindable() and snd_pcm_rewind, but actually don't rewind, and where rewinding is almost impossible to implement (e.g. because this would seemingly involve unsending of already-sent bluetooth packets). See below why "almost", you need to search for "Alternative strawman proposal". 5. PulseAudio contains a workaround for non-rewindability of the a52 plugin that also happens to apply to other ioplug-based plugins. However, this workaround does not match extplug-based plugins (including "dca"), and my patch extending the workaround has been rejected with the argument that this has to be fixed in ALSA. 6. The rate plugin has been made non-rewindable in alsa-lib 1.0.28 because the old implementation was wrong and no simple fix exists. 7. Issues regarding rewindability of PulseAudio internals such as virtual sinks will be discussed separately. And now the topics for discussion. My immediate plan is to fix (3) and, if anyone replies to the rewind safeguard proposal, maybe start fixing (2) from the alsa-lib side. For all proposals below, unless I say otherwise, I intend to write the required alsa-lib code myself if the proposal is accepted. === On the rewind safeguard === The consensus is that rewind_safeguard is a workaround for an ALSA bug. This information should come from snd_pcm_rewindable() from the hw plugin. I.e., on a hw device, it should not be equal to snd_pcm_mmap_hw_avail(). While the method of dealing with stale data and negative returns is obvious to me, I am not completely sure about the safeguard. Where should this value come from? Proposal (credit goes to Raymond Yau): the safeguard should be ideally equal to the granularity of hardware pointer updates. However, we don't know this granularity a priori, and cannot know this because nobody will find out this information for old cards. Since we can't get this, let's instead use the upper bound: the minimum possible period size for the given sample rate, sample format and the number of channels. On my desktop PC, on snd-hda-intel with analog outputs for S16LE stereo, the granularity is 32 bytes (= 8 samples), and I get the pointer granularity of 64 bytes (=16 samples) over HDMI. The minimum period size is 32 samples in both cases. Thus Raymond's method will overestimate the required safeguard on my cards, but it is still better than no safeguard at all, and less than the hard-coded value in PulseAudio. On ymfpci, the pointer granularity is 5 ms, thus the value currently hard-coded in PA is insufficient. If I understand the card's limitations correctly, Raymond's method will yield the spot-on result for this card. For the allegedly existing cards where the pointer granularity is always the same as the period size, Raymond's method will not work. However, I don't know any concrete example of such card (I didn't look at snd-firewire in detail, though). And in any case, my opinion is that this "pointer granularity = period size" limitation on such cards can be treated as a driver bug that needs to be fixed (by someone who knows the driver, not by me). On cards where pointer updates happen only on interrupts, the driver should not configure the card in such a way that one period visible to the userspace corresponds to one interrupt. Instead, it should always configure the card for the minimum possible period size, and report only part of the period interrupts to period_elapsed(). I.e.: userspace asked for 2 periods 64 ms each, but let's configure the card for, say, 64 periods 2 ms each, and use the "extra" interrupts only for updating the pointer. Hopefully, the above heuristic and driver fix will also let PulseAudio get rid of special treatment of the "batch" cards, simply because they (in the "pointer granularity = period size" definition which is currently used in PulseAudio) will no longer exist. If the heuristic (or something else) is accepted, then the question remains how to enable the use of snd_pcm_rewindable in PulseAudio. The problem is compatibility with older ALSA versions that, let me remind you, crash if snd_pcm_rewindable is called. I don't have proposals or opinions here. The obvious options are: compile-time alsa-lib version check with fallback to old code on buggy versions, run-time alsa-lib version check with the same fallback, add a (both compile-time and run-time) hard requirement of a fully-fixed alsa-lib version, or do nothing at all. Possible discussion: alternative heuristics and, as mentioned, migration path in PulseAudio. === On non-rewindability of the rate plugin === I intend to write a rewindable resampler eventually, but don't have time now. I understand that it is an important task, but issues below (and the dayjob which you can change by offering me a new one) have higher priority for me. However, I want everyone to understand the following point now: "The resampler has to be written from scratch for the reasons explained in http://permalink.gmane.org/gmane.linux.alsa.devel/122179 , and similar arguments apply to all other kinds of sound processing code that needs history." For PulseAudio, it is also needed to figure out the desired interaction between variable rate and rewindability. Should rewinding other than "discard everything completely" be allowed at all on variable rate streams when the rewind crosses the sample rate change point? I.e., write 100 samples, change rate, write 50 samples, rewind 100 samples, what should be the resulting rate? Should we special-case small changes vs big ones? Slightly off-topic, but still a discussion point. === On possibly-incomplete rewindability of the file plugin === The file plugin has quite hairy code involving the use of the write buffer. I have not verified its correctness or studied the code in detail. Anyway, it looks like it allows rewinding over that buffer only, even though its slave may allow rewinding further. If true, this would make the apparent rewindability useless, as the applications depend on being able to rewind almost everything, and won't like the apparently-random limitation (random because it depends on some obscure "wbuf" implementation detail). I think that the plugin has to be changed to avoid this limitation if it really exists (which I still need to verify). Namely, I propose keeping a shadow copy of the slave's buffer, and, at the beginning of each API call, querying the slave about its hardware pointer. Only the part of the shadow buffer that corresponds to the distance covered by the slave's hardware pointer since the last call has to be written to the file. The same applies to recording. As the code is much simpler there, it is obvious that the problem exists: if one rewinds in order to look at the past recorded samples again, the plugin will read further samples from the file instead of supplying the already-looked-at samples. The same solution with the slave hardware pointer should be applicable. The possible discussion here amounts to suggesting alternative proposals. === On bogus rewindability of ladspa and extplug plugins === For ioplug, see below, because the situation is different enough. Neither LADSPA nor snd_pcm_extplug_t have an API that allows to tell the corresponding plugin to forget the last N samples. We cannot fix LADSPA, as it is beyond our control. And we cannot really fix extplug, because this just means moving the problem down one level. External libraries (which are depended upon by the extplug-based plugins) are almost universally not rewindable, are beyond our control, and will not be made rewindable, because rewindability is hard and is not needed by anyone except ALSA and PulseAudio. Still, neither .rewindable not .rewind currently return 0. So, I'd argue that the only correct result from snd_pcm_rewindable() is 0 for ladspa and extplug plugins. However, right now, they forward the result from the slave. This needs to be fixed, and I have a patch. With snd_pcm_rewind(), the situation is a bit different. It, obviously, does nothing to tell the LADSPA or extplug plugin that the rewind happened (because it can't). It also performs a rewind on the slave. So, assuming that the rewind succeeds and the DSP algorithm in the plugin uses N samples from the past, we'll end up with the output of the correct duration but with N corrupted samples. Not ideal. But if we don't perform the rewind at all and return 0, we'll end up with regressing PulseAudio: huge latency when applying software volume changes or starting new streams. By setting up the large buffer size, it essentially assumes that any rewind will succeed. So, my hackish proposal is: make the .rewindable callbacks on ladspa and extplug return 0, keep the current implementation of the .rewind callback for compatibility with the current versions of PulseAudio, document this hack. I already have patch for this, will send out if we agree that the proposal is good. An alternative proposal (that I would implement if the proposal above is rejected and someone actively confirms this one - but I don't like it) would be to keep the current versions of the .rewindable and .rewind callbacks and add new versions of them (and new user-visible ALSA API) for the situation when imperfect results are unacceptable. A completely strawman proposal would be to introduce a low-latency thread, see below in the ioplug section. Same for .forwardable and .forward. Any other alternatives that I missed? === On bogus rewindability of some ioplug-based plugins === Ioplug-based plugins currently report rewindability according to the same "appl.ptr - hw.ptr" rule that is used by the hw plugin. However, this is incorrect. In fact, there are two types of ioplug-based plugins. The jack plugin does not even have a .transfer callback, and does all the work of irrevocably submitting samples to the JACK server in a thread. So, it is almost completely rewindable (with that "almost" being equal to JACK buffer size). Proposal: keep this logic for all plugins without the .transfer callback. Expose the JACK buffer size as the minimum period size. Then the same rule proposed in the section about the hw plugin will work for .rewindable. Other plugins do their irrevocable work in the .transfer callback and thus are not really rewindable. Proposal: return 0 from .rewindable and rewind ioplug callbacks for all plugins with a .transfer callback (but see the next section for an amendment). Document that the best practice is to have no .transfer callback. Alternative strawman proposal (speculative): if a .transfer callback exists, call it from an alsa-lib-created thread (not from snd_pcm_writei!) at the last possible moment, using the least possible amount of data (that truly cannot be rewound) in the mmap-style buffer. The new mantra is: .transfer is the thing that moves the hardware pointer. This way, previously non-rewindable plugins could become rewindable. Not sure if this is possible without changing the ABI or possible at all, though - it essentially forces all plugins to declare mmap support. Also not sure what to do with the .pointer callback. For the strawman proposal, the benefit is a possibility to have dmix on top of a52 (because freewheeling will now work), the downside is that all programs (not only those intending to do rewinds) now pay the cost of the background low-latency thread. Can we avoid this (e.g. with a new flag for snd_pcm_open), so that only programs that intend to do rewinds pay the price? Can this new flag apply to the batch hw drivers? Won't that inflate the test matrix for plugin code? For discussion: do we implement the first proposal or try the strawman proposal? Any other suggestions regarding ioplug internals? Anyone else has a problem with two completely different interfaces (with and without .transfer) being exposed under the same ioplug framework? === On the pulse plugin === PulseAudio natively supports rewinding on the wire. However, the ioplug-based plugin doesn't. It pretends that it rewound something, but always passes 0, 0 as the last two parameters to pa_stream_write(). That's bad. It looks possible (but I haven't checked) to figure out the correct arguments (i.e. to detect the rewinds done before the call to snd_pcm_writei) by looking at the application pointer. This way, it looks possible to support rewinds, but does not look possible to get the correct result (and not the result implied by the circular-buffer model) from the snd_pcm_rewindable() function. Also, we apply proposals from the previous section, we'll either end up with a plugin that is truly non-rewindable and doesn't pretend to be rewindable, or (with a strawman proposal) a rewindable plugin that forces low latency on the PulseAudio side and causes a lot of wakeups. Both situations are suboptimal. So, I see no way around adding the .rewind and .rewindable callbacks to snd_pcm_ioplug_callback, and treating the plugins with them as rewindable. I guess .forward and .forwardable should be added, too. For discussion: do we do the above or declare that ioplug is not really a suitable infrastructure for the pulse plugin? What other alternatives can be proposed? === On communication of non-rewindability to the program === PulseAudio attempts to use timer-based scheduling and rewinds. It makes a big hardware buffer in expectation that it will be able to rewind - with the exception of a workaround for ioplug-based plugins. It should not set big latency for non-rewindable plugins, but currently has no idea how to get this bit of information. See http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-April/020457.html for the initial problem statement. If all of the proposals above are implemented, then we'll be at a point where each ALSA plugin is either almost fully rewindable, or not rewindable at all. So, contrary to the end of http://permalink.gmane.org/gmane.linux.alsa.devel/122191 , I think we need just snd_pcm_hw_params_is_seekable() (or rename it if you wish) with an essentially boolean result. For discussion: 1. Decide, finally, on this bit of API, so that I can start working. 2. Decide what to do with old alsa-lib versions in PulseAudio. I.e. transition plan. === On the programmer expectations === (social issue) Some people, including at least Andrew Eikum and Clemens Ladisch, at least once in the past expressed the opinion that amounts to "any plugin that does not allow random access is, as far as the ALSA API is concerned, buggy" (quoting http://permalink.gmane.org/gmane.linux.alsa.devel/122159 ), i.e. they are maybe asking for the impossible. We need to do something about that. Choices: 1. Document clearly that there exist non-rewindable plugins, and that it is not a bug until someone implements a working time machine. 2. Implement a strawman proposal with the background low-latency thread if it is doable (and I am not sure that it is doable). 3. Remove ioplug, extplug and ladspa as unfixable, fix the rate and adpcm plugins (or remove adpcm). Do something about pulse and jack because they rely on the to-be-removed ioplug infrastructure. Then all remaining plugins will indeed be fully rewindable. 4. Something else? Sorry for the negative tone here, I know I am bad at formulating and resolving social issues. === Conclusion === When all the proposals are implemented, we'll have correct implementations of the rewind operation in all plugins (where "return 0" counts as correct), and "return 0" only where it is truly unavoidable. PulseAudio will be able to use all of that, and avoid doing rewinds on non-rewindable plugins. On this positive note, I'd like to finish writing this long e-mail. -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-07 15:16 Master Plan on rewinding Alexander E. Patrakov @ 2014-09-07 18:38 ` Tanu Kaskinen 2014-09-07 19:05 ` Alexander E. Patrakov 2014-09-07 20:51 ` Clemens Ladisch ` (5 subsequent siblings) 6 siblings, 1 reply; 52+ messages in thread From: Tanu Kaskinen @ 2014-09-07 18:38 UTC (permalink / raw) To: Alexander E. Patrakov; +Cc: ALSA Development Mailing List On Sun, 2014-09-07 at 21:16 +0600, Alexander E. Patrakov wrote: > === On non-rewindability of the rate plugin === > > I intend to write a rewindable resampler eventually, but don't have time > now. I understand that it is an important task, but issues below (and > the dayjob which you can change by offering me a new one) have higher > priority for me. However, I want everyone to understand the following > point now: > > "The resampler has to be written from scratch for the reasons explained > in http://permalink.gmane.org/gmane.linux.alsa.devel/122179 , and > similar arguments apply to all other kinds of sound processing code that > needs history." > > For PulseAudio, it is also needed to figure out the desired interaction > between variable rate and rewindability. Should rewinding other than > "discard everything completely" be allowed at all on variable rate > streams when the rewind crosses the sample rate change point? I.e., > write 100 samples, change rate, write 50 samples, rewind 100 samples, > what should be the resulting rate? Should we special-case small changes > vs big ones? This last paragraph isn't related to the rate plugin, right? So you're talking about PulseAudio internals only? If so, perhaps the best approach would be to make the current stream buffer contents non-rewindable when a rate change occurs, at least until someone points out a real use case where it is important to be able to rewind past rate change points in the buffer. Without any example use cases, I don't feel qualified to answer the question what should happen if a rewind crosses a rate change point (or possibly several!). Another question is that should we do something to previously buffered stream data when the rate changes. If the audio rate changes completely, e.g. from 44.1 kHz to 8 kHz, any previously buffered audio was probably meant to be played at 44.1 kH, but with the current code it will be played at 8 kHz. I don't know if there are any applications that (ab)use the dynamic rate feature this way, though. Maybe we could just document that the dynamic rate feature is only meant for small adjustments. -- Tanu ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-07 18:38 ` Tanu Kaskinen @ 2014-09-07 19:05 ` Alexander E. Patrakov 0 siblings, 0 replies; 52+ messages in thread From: Alexander E. Patrakov @ 2014-09-07 19:05 UTC (permalink / raw) To: Tanu Kaskinen; +Cc: ALSA Development Mailing List 08.09.2014 00:38, Tanu Kaskinen wrote: > On Sun, 2014-09-07 at 21:16 +0600, Alexander E. Patrakov wrote: >> === On non-rewindability of the rate plugin === >> >> I intend to write a rewindable resampler eventually, but don't have time >> now. I understand that it is an important task, but issues below (and >> the dayjob which you can change by offering me a new one) have higher >> priority for me. However, I want everyone to understand the following >> point now: >> >> "The resampler has to be written from scratch for the reasons explained >> in http://permalink.gmane.org/gmane.linux.alsa.devel/122179 , and >> similar arguments apply to all other kinds of sound processing code that >> needs history." >> >> For PulseAudio, it is also needed to figure out the desired interaction >> between variable rate and rewindability. Should rewinding other than >> "discard everything completely" be allowed at all on variable rate >> streams when the rewind crosses the sample rate change point? I.e., >> write 100 samples, change rate, write 50 samples, rewind 100 samples, >> what should be the resulting rate? Should we special-case small changes >> vs big ones? > > This last paragraph isn't related to the rate plugin, right? Right. > So you're > talking about PulseAudio internals only? Yes, in the last paragraph only. > If so, perhaps the best > approach would be to make the current stream buffer contents > non-rewindable when a rate change occurs, at least until someone points > out a real use case where it is important to be able to rewind past rate > change points in the buffer. Without any example use cases, I don't feel > qualified to answer the question what should happen if a rewind crosses > a rate change point (or possibly several!). > > Another question is that should we do something to previously buffered > stream data when the rate changes. If the audio rate changes completely, > e.g. from 44.1 kHz to 8 kHz, any previously buffered audio was probably > meant to be played at 44.1 kH, but with the current code it will be > played at 8 kHz. I don't know if there are any applications that (ab)use > the dynamic rate feature this way, though. Maybe we could just document > that the dynamic rate feature is only meant for small adjustments. Thanks for the feedback. Let's see if others say anything else on this topic. -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-07 15:16 Master Plan on rewinding Alexander E. Patrakov 2014-09-07 18:38 ` Tanu Kaskinen @ 2014-09-07 20:51 ` Clemens Ladisch 2014-09-08 3:06 ` Raymond Yau 2014-09-08 7:31 ` Alexander E. Patrakov 2014-09-07 23:12 ` David Henningsson ` (4 subsequent siblings) 6 siblings, 2 replies; 52+ messages in thread From: Clemens Ladisch @ 2014-09-07 20:51 UTC (permalink / raw) To: Alexander E. Patrakov, ALSA Development Mailing List, Takashi Iwai, David Henningsson, Takashi Sakamoto Alexander E. Patrakov wrote: > The consensus is that rewind_safeguard is a workaround for an ALSA bug. I do not agree with this consensus. > This information should come from snd_pcm_rewindable() from the hw > plugin. I.e., on a hw device, it should not be equal to > snd_pcm_mmap_hw_avail(). [...] > the safeguard should be ideally equal to the granularity of hardware > pointer updates. When snd_pcm_rewindable() is called, it uses the last reported hardware pointer position, which is the boundary between safe-to-rewrite and already-used data. Subtracting the amount of one pointer update step makes it safe for the next pointer update, but it is not known how much time will elapse until the hardware does this update. This time might be too small for the software to have any chance, or even zero, but it is also possible that there is still enough time to do the rewriting up until the reported boundary. And if the software is too slow, it is even possible that two or more pointer updates happen, which would have required a larger safeguard. In other words: the snd_pcm_mmap_hw_avail() value is possibly ouf of date, but due to the real-time nature of hardware pointer updates, it is not possible to define a safeguard that would be more correct. Writing the buffer near the DMA pointer is always racy. The only somewhat reliable way to determine if a rewrite is successful is to check _afterwards_ whether the hardware pointer has advanced by too much. > [...] On cards where pointer updates happen only on interrupts, the > driver should not configure the card in such a way that one period > visible to the userspace corresponds to one interrupt. Instead, it > should always configure the card for the minimum possible period > size, and report only part of the period interrupts to period_elapsed(). Such stupid DMA controllers are typically found on mobile devices, which cannot afford extraneous interrupts. > === On the programmer expectations === > > Some people, including at least Andrew Eikum and Clemens Ladisch, at > least once in the past expressed the opinion that amounts to "any > plugin that does not allow random access is, as far as the ALSA API is > concerned, buggy" (quoting http://permalink.gmane.org/gmane.linux.alsa.devel/122159 ), > i.e. they are maybe asking for the impossible. This was merely a description of the current API and its implementation, which assume that all devices/plugins have a rewritable ring buffer. I am fully aware that this assumption is wrong. Regards, Clemens ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-07 20:51 ` Clemens Ladisch @ 2014-09-08 3:06 ` Raymond Yau 2014-09-08 7:31 ` Alexander E. Patrakov 1 sibling, 0 replies; 52+ messages in thread From: Raymond Yau @ 2014-09-08 3:06 UTC (permalink / raw) To: Clemens Ladisch Cc: Takashi Iwai, ALSA Development Mailing List, Alexander E. Patrakov, David Henningsson, Takashi Sakamoto > > The consensus is that rewind_safeguard is a workaround for an ALSA bug. > > I do not agree with this consensus. > > > This information should come from snd_pcm_rewindable() from the hw > > plugin. I.e., on a hw device, it should not be equal to > > snd_pcm_mmap_hw_avail(). [...] > > the safeguard should be ideally equal to the granularity of hardware > > pointer updates. > > When snd_pcm_rewindable() is called, it uses the last reported hardware > pointer position, which is the boundary between safe-to-rewrite and > already-used data. Subtracting the amount of one pointer update step > makes it safe for the next pointer update, but it is not known how much > time will elapse until the hardware does this update. This time might > be too small for the software to have any chance, or even zero, but it > is also possible that there is still enough time to do the rewriting up > until the reported boundary. And if the software is too slow, it is > even possible that two or more pointer updates happen, which would have > required a larger safeguard. > > In other words: the snd_pcm_mmap_hw_avail() value is possibly ouf of > date, but due to the real-time nature of hardware pointer updates, it is > not possible to define a safeguard that would be more correct. Writing > the buffer near the DMA pointer is always racy. > > The only somewhat reliable way to determine if a rewrite is successful > is to check _afterwards_ whether the hardware pointer has advanced by > too much. snd_pcm_rewindable is properly not any SAFE value for rewind, it should return zero for those hardware which don't support rewind(e.g, non interleaved or cs46xx) It is just a theoretical value for rewind since the application don't rewrite immediately So the application need to estimate the safe guard value from the processing time of the amount of data need to be reprocess /rewrite and CPU speed Should pulseaudio enable timer scheduling only on those cards which support disable of period interrupt (e.g. hda-Intel and oxygen )? _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-07 20:51 ` Clemens Ladisch 2014-09-08 3:06 ` Raymond Yau @ 2014-09-08 7:31 ` Alexander E. Patrakov 2014-09-09 8:43 ` Clemens Ladisch 1 sibling, 1 reply; 52+ messages in thread From: Alexander E. Patrakov @ 2014-09-08 7:31 UTC (permalink / raw) To: Clemens Ladisch, ALSA Development Mailing List, Takashi Iwai, David Henningsson, Takashi Sakamoto 08.09.2014 02:51, Clemens Ladisch wrote: > Alexander E. Patrakov wrote: >> The consensus is that rewind_safeguard is a workaround for an ALSA bug. > > I do not agree with this consensus. OK, disagreements are what this thread is for :) > >> This information should come from snd_pcm_rewindable() from the hw >> plugin. I.e., on a hw device, it should not be equal to >> snd_pcm_mmap_hw_avail(). [...] >> the safeguard should be ideally equal to the granularity of hardware >> pointer updates. > > When snd_pcm_rewindable() is called, it uses the last reported hardware > pointer position, which is the boundary between safe-to-rewrite and > already-used data. Subtracting the amount of one pointer update step > makes it safe for the next pointer update, but it is not known how much > time will elapse until the hardware does this update. This time might > be too small for the software to have any chance, or even zero, but it > is also possible that there is still enough time to do the rewriting up > until the reported boundary. And if the software is too slow, it is > even possible that two or more pointer updates happen, which would have > required a larger safeguard. I disagree with the words "boundary between safe-to-rewrite and already-used data". They describe a point that hardware knows, but software cannot know. My viewpoint is that, even with a perfect scheduler, known-safe-to-rewrite and known-already-used data are not separated with a point. See below for an example. You indeed have a strong argument for keeping the safeguard in PulseAudio as a protection against scheduler glitches, but look what happens on ymfpci. Having read David's email, I understand that it is not the same reason why the safeguard has been originally added. On ymfpci, interrupts (that don't correspond 1:1 to periods) happen every 5 ms, and pointer (which is a hardware register) is updated only during interrupts by the hardware. |---------|---------P----h----p---------|-a-------|---------| Here each character corresponds to 0.5 ms, "-" means nothing interesting, "|", "P" and "p" mark interrupt positions, "h" marks the place where the card reads the sound data from (i.e. the true boundary between safe-to-rewrite and already-used data). Thus, the interrupt at "P" has already happened, but the interrupt at "p" hasn't. "a" is the application write pointer. So, what should alsa-lib return for snd_pcm_avail() and snd_pcm_rewind()? The driver only knows that "P" is already used, can infer that "p" isn't used yet, and knows nothing about samples in the middle. For snd_pcm_avail(), it can only say that the application may only write up to "P" from the left. Everything else would be a possible lie leading to not-yet-played data possibly being overwritten. For snd_pcm_rewindable(), it can only say that the application may try to go to "p" from the right. Everything further to the left is at risk of being already-played, even with a perfect scheduler and infinitely fast CPU. > In other words: the snd_pcm_mmap_hw_avail() value is possibly ouf of > date, but due to the real-time nature of hardware pointer updates, it is > not possible to define a safeguard that would be more correct. Writing > the buffer near the DMA pointer is always racy. Correct. The problem is that, on some cards, the uncertainty here (described above) is an order of magnitude bigger than typical scheduler glitches, and depends on sound card hardware. I don't want to introduce an unnecessarily-big safeguard for all sound cards because of a few bad ones. So it looks like we need both the hardware-independent safeguard in PulseAudio (against scheduler glitches) and the hardware-dependent safeguard in alsa-lib (against known imprecise reporting by the card). > The only somewhat reliable way to determine if a rewrite is successful > is to check _afterwards_ whether the hardware pointer has advanced by > too much. PulseAudio does that in addition to the safeguard. >> [...] On cards where pointer updates happen only on interrupts, the >> driver should not configure the card in such a way that one period >> visible to the userspace corresponds to one interrupt. Instead, it >> should always configure the card for the minimum possible period >> size, and report only part of the period interrupts to period_elapsed(). > > Such stupid DMA controllers are typically found on mobile devices, which > cannot afford extraneous interrupts. Thanks for the information, I didn't know that, and hereby retract the quoted proposal. Still, to support this type of stupid DMA controllers properly, we need a vocabulary of such weirdnesses and an agreed-upon way to communicate them from the kernel to userspace. I don't think that I can build such vocabulary. > >> === On the programmer expectations === >> >> Some people, including at least Andrew Eikum and Clemens Ladisch, at >> least once in the past expressed the opinion that amounts to "any >> plugin that does not allow random access is, as far as the ALSA API is >> concerned, buggy" (quoting http://permalink.gmane.org/gmane.linux.alsa.devel/122159 ), >> i.e. they are maybe asking for the impossible. > > This was merely a description of the current API and its implementation, > which assume that all devices/plugins have a rewritable ring buffer. > I am fully aware that this assumption is wrong. OK. Now I see that in your case it was a misinterpretation from my side - sorry for that! But this doesn't cancel the attitude "if a function is documented without any caveats, it must always work, usefully" that I have seen from others. So I'll put a documentation patch on my TODO list. -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-08 7:31 ` Alexander E. Patrakov @ 2014-09-09 8:43 ` Clemens Ladisch 2014-09-09 8:55 ` Alexander E. Patrakov 0 siblings, 1 reply; 52+ messages in thread From: Clemens Ladisch @ 2014-09-09 8:43 UTC (permalink / raw) To: Alexander E. Patrakov, ALSA Development Mailing List, Takashi Iwai, David Henningsson, Takashi Sakamoto Alexander E. Patrakov wrote: > |---------|---------P----h----p---------|-a-------|---------| > > So, what should alsa-lib return for snd_pcm_avail() and snd_pcm_rewind()? > The driver only knows that "P" is already used, can infer that "p" isn't > used yet, and knows nothing about samples in the middle. Indeed. However, the DMA pointer moves asynchronously, so it is possible that it has already moved beyond p when snd_pcm_rewindable() returns. For the samples between P and p, the risk is larger than for those after p, but p is not a boundary where the risk abruptly decreases. It would make sense to report the pointer update granularity, but not to adjust the return value of snd_pcm_avail/rewindable(). Regards, Clemens ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-09 8:43 ` Clemens Ladisch @ 2014-09-09 8:55 ` Alexander E. Patrakov 2014-09-09 9:08 ` David Henningsson 2014-09-09 13:45 ` Clemens Ladisch 0 siblings, 2 replies; 52+ messages in thread From: Alexander E. Patrakov @ 2014-09-09 8:55 UTC (permalink / raw) To: Clemens Ladisch, ALSA Development Mailing List, Takashi Iwai, David Henningsson, Takashi Sakamoto 09.09.2014 14:43, Clemens Ladisch wrote: > Alexander E. Patrakov wrote: >> |---------|---------P----h----p---------|-a-------|---------| >> >> So, what should alsa-lib return for snd_pcm_avail() and snd_pcm_rewind()? >> The driver only knows that "P" is already used, can infer that "p" isn't >> used yet, and knows nothing about samples in the middle. > Indeed. However, the DMA pointer moves asynchronously, so it is possible > that it has already moved beyond p when snd_pcm_rewindable() returns. > For the samples between P and p, the risk is larger than for those after > p, but p is not a boundary where the risk abruptly decreases. > > It would make sense to report the pointer update granularity, but not > to adjust the return value of snd_pcm_avail/rewindable(). OK, I understand your viewpoint, and the phrase "some indicator of the actual rewind granularity and/or safeguard ... should be enough for PA to be able to pick a suitable default latency" from David indicates that he has a similar opinion. Now the remaining question is: can the proposed heuristic (minimum period size for a given sample rate, number of channels and sample format) be useful as an upper-bound approximation of the pointer update granularity for cards that are "rewindable even further than the nearest period"? -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-09 8:55 ` Alexander E. Patrakov @ 2014-09-09 9:08 ` David Henningsson 2014-09-09 9:31 ` Alexander E. Patrakov 2014-09-09 13:45 ` Clemens Ladisch 1 sibling, 1 reply; 52+ messages in thread From: David Henningsson @ 2014-09-09 9:08 UTC (permalink / raw) To: Alexander E. Patrakov, Clemens Ladisch, ALSA Development Mailing List, Takashi Iwai, Takashi Sakamoto On 2014-09-09 10:55, Alexander E. Patrakov wrote: > 09.09.2014 14:43, Clemens Ladisch wrote: >> Alexander E. Patrakov wrote: >>> |---------|---------P----h----p---------|-a-------|---------| >>> >>> So, what should alsa-lib return for snd_pcm_avail() and >>> snd_pcm_rewind()? >>> The driver only knows that "P" is already used, can infer that "p" isn't >>> used yet, and knows nothing about samples in the middle. >> Indeed. However, the DMA pointer moves asynchronously, so it is possible >> that it has already moved beyond p when snd_pcm_rewindable() returns. >> For the samples between P and p, the risk is larger than for those after >> p, but p is not a boundary where the risk abruptly decreases. >> >> It would make sense to report the pointer update granularity, but not >> to adjust the return value of snd_pcm_avail/rewindable(). > > OK, I understand your viewpoint, and the phrase "some indicator of the > actual rewind granularity and/or safeguard ... should be enough for PA > to be able to pick a suitable default latency" from David indicates that > he has a similar opinion. > > Now the remaining question is: can the proposed heuristic (minimum > period size for a given sample rate, number of channels and sample > format) be useful as an upper-bound approximation of the pointer update > granularity for cards that are "rewindable even further than the nearest > period"? Aha, thanks for the explanation. Now I understand that approximation idea. I don't know if that's a reasonable approximation, but even if it is, how would you determine if a card actually has that pointer granularity, or if the pointer granularity varies with period size? (I e without actually running a stream and measure it) -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-09 9:08 ` David Henningsson @ 2014-09-09 9:31 ` Alexander E. Patrakov 2014-09-21 2:02 ` Raymond Yau 0 siblings, 1 reply; 52+ messages in thread From: Alexander E. Patrakov @ 2014-09-09 9:31 UTC (permalink / raw) To: David Henningsson, Clemens Ladisch, ALSA Development Mailing List, Takashi Iwai, Takashi Sakamoto 09.09.2014 15:08, David Henningsson wrote: > > > On 2014-09-09 10:55, Alexander E. Patrakov wrote: >> 09.09.2014 14:43, Clemens Ladisch wrote: >>> Alexander E. Patrakov wrote: >>>> |---------|---------P----h----p---------|-a-------|---------| >>>> >>>> So, what should alsa-lib return for snd_pcm_avail() and >>>> snd_pcm_rewind()? >>>> The driver only knows that "P" is already used, can infer that "p" >>>> isn't >>>> used yet, and knows nothing about samples in the middle. >>> Indeed. However, the DMA pointer moves asynchronously, so it is >>> possible >>> that it has already moved beyond p when snd_pcm_rewindable() returns. >>> For the samples between P and p, the risk is larger than for those after >>> p, but p is not a boundary where the risk abruptly decreases. >>> >>> It would make sense to report the pointer update granularity, but not >>> to adjust the return value of snd_pcm_avail/rewindable(). >> >> OK, I understand your viewpoint, and the phrase "some indicator of the >> actual rewind granularity and/or safeguard ... should be enough for PA >> to be able to pick a suitable default latency" from David indicates that >> he has a similar opinion. >> >> Now the remaining question is: can the proposed heuristic (minimum >> period size for a given sample rate, number of channels and sample >> format) be useful as an upper-bound approximation of the pointer update >> granularity for cards that are "rewindable even further than the nearest >> period"? > > Aha, thanks for the explanation. Now I understand that approximation idea. > I don't know if that's a reasonable approximation, but even if it is, > how would you determine if a card actually has that pointer granularity, > or if the pointer granularity varies with period size? (I e without > actually running a stream and measure it) Currently, as you have already said, we have no such information. This information is, however, static for a given card model and should, in the future, come from the kernel. Therefore: 1. We need a new flag alongside SNDRV_PCM_INFO_BATCH that kernel drivers would set, and alsa-lib to act upon. As indicated in the following posts, SNDRV_PCM_INFO_BATCH means a different and not-useful-here thing: http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/073816.html http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/073817.html 2. We need a volunteer to crawl through kernel sources and mark drivers that cannot report the pointer position with a better-than-one-period granularity. 3. Until this is done, we have to either assume that all cards are good, or that all cards are bad, or maybe misuse the SNDRV_PCM_INFO_BATCH flag as a pessimistic approximation of what we want (and document this approximation) if anyone thinks that such misuse will be beneficial in the short term. This leaves the question of "old kernel + new alsa-lib" open. -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-09 9:31 ` Alexander E. Patrakov @ 2014-09-21 2:02 ` Raymond Yau 2014-09-22 13:20 ` Lars-Peter Clausen 0 siblings, 1 reply; 52+ messages in thread From: Raymond Yau @ 2014-09-21 2:02 UTC (permalink / raw) To: Alexander E. Patrakov Cc: Takashi Iwai, ALSA Development Mailing List, Clemens Ladisch, David Henningsson, Takashi Sakamoto >>>>> >>>>> |---------|---------P----h----p---------|-a-------|---------| >>>>> >>>>> So, what should alsa-lib return for snd_pcm_avail() and >>>>> snd_pcm_rewind()? >>>>> The driver only knows that "P" is already used, can infer that "p" >>>>> isn't >>>>> used yet, and knows nothing about samples in the middle. >>>> >>>> Indeed. However, the DMA pointer moves asynchronously, so it is >>>> possible >>>> that it has already moved beyond p when snd_pcm_rewindable() returns. >>>> For the samples between P and p, the risk is larger than for those after >>>> p, but p is not a boundary where the risk abruptly decreases. >>>> >>>> It would make sense to report the pointer update granularity, but not >>>> to adjust the return value of snd_pcm_avail/rewindable(). >>> >>> >>> OK, I understand your viewpoint, and the phrase "some indicator of the >>> actual rewind granularity and/or safeguard ... should be enough for PA >>> to be able to pick a suitable default latency" from David indicates that >>> he has a similar opinion. >>> >>> Now the remaining question is: can the proposed heuristic (minimum >>> period size for a given sample rate, number of channels and sample >>> format) be useful as an upper-bound approximation of the pointer update >>> granularity for cards that are "rewindable even further than the nearest >>> period"? >> >> >> Aha, thanks for the explanation. Now I understand that approximation idea. >> I don't know if that's a reasonable approximation, but even if it is, >> how would you determine if a card actually has that pointer granularity, >> or if the pointer granularity varies with period size? (I e without >> actually running a stream and measure it) > > > Currently, as you have already said, we have no such information. This information is, however, static for a given card model and should, in the future, come from the kernel. Therefore: > > 1. We need a new flag alongside SNDRV_PCM_INFO_BATCH that kernel drivers would set, and alsa-lib to act upon. As indicated in the following posts, SNDRV_PCM_INFO_BATCH means a different and not-useful-here thing: > > http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/073816.html > http://mailman.alsa-project.org/pipermail/alsa-devel/2014-March/073817.html > > 2. We need a volunteer to crawl through kernel sources and mark drivers that cannot report the pointer position with a better-than-one-period granularity. > > 3. Until this is done, we have to either assume that all cards are good, or that all cards are bad, or maybe misuse the SNDRV_PCM_INFO_BATCH flag as a pessimistic approximation of what we want (and document this approximation) if anyone thinks that such misuse will be beneficial in the short term. > > This leaves the question of "old kernel + new alsa-lib" open. > > -- https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/soc/soc-generic-dmaengine-pcm.c?id=478028e088d6a94666d8a776be2cd2291faf3bbd a) Set the SNDRV_PCM_INFO_BATCH if the granularity is per period or worse. b) Fallback to the (race condition prone) period counting if the driver does not support any residue reporting. Seem soc already have this granularity How can the granularity worse more than one period ? https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/include/linux/dmaengine.h enum dma_residue_granularity { DMA_RESIDUE_GRANULARITY_DESCRIPTOR = 0, DMA_RESIDUE_GRANULARITY_SEGMENT = 1, DMA_RESIDUE_GRANULARITY_BURST = 2, }; There are three type of granularity Does this mean the those sound card can report DMA_RESIDUE_GRANULARITY_BURST and driver use readl in pcm pointer callback ? A few PCI sound cards use SG buffer including hda It seem that pulseaudio expect the driver support DMA_RESIDUE_GRANULARITY_BURST for rewind/ timer scheduling /** * enum dma_residue_granularity - Granularity of the reported transfer residue * @DMA_RESIDUE_GRANULARITY_DESCRIPTOR: Residue reporting is not support. The DMA channel is only able to tell whether a descriptor has been completed or not, which means residue reporting is not supported by this channel. The residue field of the dma_tx_state field will always be 0. * @DMA_RESIDUE_GRANULARITY_SEGMENT: Residue is updated after each successfully completed segment of the transfer (For cyclic transfers this is after each period). This is typically implemented by having the hardware generate an interrupt after each transferred segment and then the drivers updates the outstanding residue by the size of the segment. Another possibility is if the hardware supports scatter-gather and the segment descriptor has a field which gets set after the segment has been completed. The driver then counts the number of segments without the flag set to compute the residue. * @DMA_RESIDUE_GRANULARITY_BURST: Residue is updated after each transferred burst. This is typically only supported if the hardware has a progress register of some sort (E.g. a register with the current read/write address or a register with the amount of bursts/beats/bytes that have been transferred or still need to be transferred). */ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-21 2:02 ` Raymond Yau @ 2014-09-22 13:20 ` Lars-Peter Clausen 2014-09-22 13:36 ` Alexander E. Patrakov 0 siblings, 1 reply; 52+ messages in thread From: Lars-Peter Clausen @ 2014-09-22 13:20 UTC (permalink / raw) To: Raymond Yau, Alexander E. Patrakov Cc: Takashi Iwai, ALSA Development Mailing List, Clemens Ladisch, David Henningsson, Takashi Sakamoto On 09/21/2014 04:02 AM, Raymond Yau wrote: [...] > https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/soc/soc-generic-dmaengine-pcm.c?id=478028e088d6a94666d8a776be2cd2291faf3bbd > > a) Set the SNDRV_PCM_INFO_BATCH if the granularity is per period or worse. > b) Fallback to the (race condition prone) period counting if the driver > does not support any residue reporting. > > Seem soc already have this granularity > > How can the granularity worse more than one period ? The granularity is the granularity that the DMA driver is able to report. In some cases the DMA driver is only able to tell whether a transfer has finished or not, but is not able tell any intermediate position. In case of a cyclic transfer the transfer never stops, so the DMA driver will only ever tell us that it hasn't finished the transfer yet. But the DMA driver will still generate a interrupt after every finished period. So we use this as a fallback mechanism and simply increase the pointer position after each interrupt by one period size. So userspace will never see a granularity that is worse than one descriptor. This is just something kernel internal. On a side node, this period counting scheme is prone to race conditions and we strongly discourage new drivers from using it. Its mainly for supporting old DMA drivers which do not implement progress reporting (yet). > > https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/include/linux/dmaengine.h > > enum dma_residue_granularity { > DMA_RESIDUE_GRANULARITY_DESCRIPTOR = 0, > DMA_RESIDUE_GRANULARITY_SEGMENT = 1, > DMA_RESIDUE_GRANULARITY_BURST = 2, > }; > > There are three type of granularity Only SEGMENT and BURST granularity are relevant for audio userspace. For ALSA we'd probably see different kind of categories of granularity though. E.g. one field which is the unit of the granularity PERIOD: The granularity is a multiple of the period size FRAME: The granularity is a multiple of the frame size BYTE: The granularity is a fixed number of bytes MS: The granularity is a fixed amount of time and then a second field that has a integer number of the granularity in that unit. And then there is of course the issue that for some chips you can trade granularity for e.g. power efficiency or similar (e.g. by changing the transfer burst size). And this needs to be modeled somehow as well. > > Does this mean the those sound card can report > DMA_RESIDUE_GRANULARITY_BURST and driver use readl in pcm pointer callback ? > > A few PCI sound cards use SG buffer including hda > > It seem that pulseaudio expect the driver support > DMA_RESIDUE_GRANULARITY_BURST for rewind/ timer scheduling Yes. This is why we set the BATCH flag if the granularity is not DMA_RESIDUE_GRANULARITY_BURST so for example pulse audio can disable timer scheduling. - Lars ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-22 13:20 ` Lars-Peter Clausen @ 2014-09-22 13:36 ` Alexander E. Patrakov 2014-09-22 13:44 ` Lars-Peter Clausen 2014-09-23 8:29 ` Raymond Yau 0 siblings, 2 replies; 52+ messages in thread From: Alexander E. Patrakov @ 2014-09-22 13:36 UTC (permalink / raw) To: Lars-Peter Clausen, Raymond Yau Cc: Takashi Iwai, ALSA Development Mailing List, Clemens Ladisch, David Henningsson, Takashi Sakamoto 22.09.2014 19:20, Lars-Peter Clausen wrote: >> >> Does this mean the those sound card can report >> DMA_RESIDUE_GRANULARITY_BURST and driver use readl in pcm pointer >> callback ? >> >> A few PCI sound cards use SG buffer including hda >> >> It seem that pulseaudio expect the driver support >> DMA_RESIDUE_GRANULARITY_BURST for rewind/ timer scheduling > > Yes. This is why we set the BATCH flag if the granularity is not > DMA_RESIDUE_GRANULARITY_BURST so for example pulse audio can disable > timer scheduling. For the record, disabling timer-based scheduling is IMHO a matter of further discussion. As long as there is enough safeguard, I think that timer-based scheduling can still be used, and is useful. A living proof is the whole story with the snd-usb-audio driver where (justified) addition of the BATCH flag was perceived as a performance regression and not as a fix to some real and obvious problem. I do agree that such devices need to be marked up with the BATCH flag, so that PulseAudio chooses reasonable hardware parameters. -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-22 13:36 ` Alexander E. Patrakov @ 2014-09-22 13:44 ` Lars-Peter Clausen 2014-09-23 8:29 ` Raymond Yau 1 sibling, 0 replies; 52+ messages in thread From: Lars-Peter Clausen @ 2014-09-22 13:44 UTC (permalink / raw) To: Alexander E. Patrakov, Raymond Yau Cc: Takashi Iwai, ALSA Development Mailing List, Clemens Ladisch, David Henningsson, Takashi Sakamoto On 09/22/2014 03:36 PM, Alexander E. Patrakov wrote: > 22.09.2014 19:20, Lars-Peter Clausen wrote: >>> >>> Does this mean the those sound card can report >>> DMA_RESIDUE_GRANULARITY_BURST and driver use readl in pcm pointer >>> callback ? >>> >>> A few PCI sound cards use SG buffer including hda >>> >>> It seem that pulseaudio expect the driver support >>> DMA_RESIDUE_GRANULARITY_BURST for rewind/ timer scheduling >> >> Yes. This is why we set the BATCH flag if the granularity is not >> DMA_RESIDUE_GRANULARITY_BURST so for example pulse audio can disable >> timer scheduling. > > For the record, disabling timer-based scheduling is IMHO a matter of further > discussion. As long as there is enough safeguard, I think that timer-based > scheduling can still be used, and is useful. A living proof is the whole > story with the snd-usb-audio driver where (justified) addition of the BATCH > flag was perceived as a performance regression and not as a fix to some real > and obvious problem. > > I do agree that such devices need to be marked up with the BATCH flag, so > that PulseAudio chooses reasonable hardware parameters. > When I tried things it looks like it was more than just the safeguard threshold. It looked as if the algorithm that adjusts the wake-up time gets confused if the granularity is not good enough and just wakes up at the wrong point which leads to glitches. This can probably be fixed though by modifying the algorithm to take the granularity into account. - Lars ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-22 13:36 ` Alexander E. Patrakov 2014-09-22 13:44 ` Lars-Peter Clausen @ 2014-09-23 8:29 ` Raymond Yau 2014-09-23 10:22 ` Alexander E. Patrakov 1 sibling, 1 reply; 52+ messages in thread From: Raymond Yau @ 2014-09-23 8:29 UTC (permalink / raw) To: Alexander E. Patrakov Cc: ALSA Development Mailing List, Lars-Peter Clausen, Takashi Iwai, Clemens Ladisch, Takashi Sakamoto, David Henningsson >>> >>> >>> Does this mean the those sound card can report >>> DMA_RESIDUE_GRANULARITY_BURST and driver use readl in pcm pointer >>> callback ? >>> >>> A few PCI sound cards use SG buffer including hda >>> >>> It seem that pulseaudio expect the driver support >>> DMA_RESIDUE_GRANULARITY_BURST for rewind/ timer scheduling >> >> >> Yes. This is why we set the BATCH flag if the granularity is not >> DMA_RESIDUE_GRANULARITY_BURST so for example pulse audio can disable >> timer scheduling. > The resolution of pulseaudio volume is higher than the number of steps of the hardware volume control, this mean any volume change by user force pulseaudio to rewind because of the change in software volume As user won't expect the volume change is delayed by one second Those drivers should not use 2 periods as graunulaity is one period which is 170ms ~1 second if you are running video conference (e.g. Google hangout) when video is 15~30 frames per second The safeguard can only be decreased by reduce the period size Is it feasible for pulseaudio to use more periods with suitable period size/time for the requested latency when there is one and only one client when the sound card cannot provide precise DMA position instead of maximum period size/time ? > > For the record, disabling timer-based scheduling is IMHO a matter of further discussion. As long as there is enough safeguard, I think that timer-based scheduling can still be used, and is useful. A living proof is the whole story with the snd-usb-audio driver where (justified) addition of the BATCH flag was perceived as a performance regression and not as a fix to some real and obvious problem. The point is some drivers use .periods_min = 1 Pulseaudio select minimum number of period interrupt driven mode should not use one period per buffer since granularity is one period one period per buffer work only when sound card can report granularity which is less than one period aplay won't use one period per buffer , default is four but fallback to two when driver use .periods_max = 2 http://0pointer.net/blog/projects/pulse-glitch-free.html NFRAGS must >= 2 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-23 8:29 ` Raymond Yau @ 2014-09-23 10:22 ` Alexander E. Patrakov 0 siblings, 0 replies; 52+ messages in thread From: Alexander E. Patrakov @ 2014-09-23 10:22 UTC (permalink / raw) To: Raymond Yau Cc: ALSA Development Mailing List, Lars-Peter Clausen, Takashi Iwai, Clemens Ladisch, Takashi Sakamoto, David Henningsson 23.09.2014 14:29, Raymond Yau wrote: > > >>> > >>> > >>> Does this mean the those sound card can report > >>> DMA_RESIDUE_GRANULARITY_BURST and driver use readl in pcm pointer > >>> callback ? > >>> > >>> A few PCI sound cards use SG buffer including hda > >>> > >>> It seem that pulseaudio expect the driver support > >>> DMA_RESIDUE_GRANULARITY_BURST for rewind/ timer scheduling > >> > >> > >> Yes. This is why we set the BATCH flag if the granularity is not > >> DMA_RESIDUE_GRANULARITY_BURST so for example pulse audio can disable > >> timer scheduling. > > > > The resolution of pulseaudio volume is higher than the number of steps > of the hardware volume control, this mean any volume change by user > force pulseaudio to rewind because of the change in software volume > > As user won't expect the volume change is delayed by one second Absolutely correct, and a similar thing was already discussed. The interesting part of the discussion starts here: http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-April/020462.html Please disregard my "factor of 1000" statement - it is no longer true. > Those drivers should not use 2 periods as graunulaity is one period > which is 170ms ~1 second if you are running video conference (e.g. > Google hangout) when video is 15~30 frames per second > > The safeguard can only be decreased by reduce the period size Also correct for the BATCH cards. However, please note that for the BATCH cards PulseAudio looks at the default-fragment-size-msec setting from daemon.conf by default. > Is it feasible for pulseaudio to use more periods with suitable period > size/time for the requested latency when there is one and only one > client when the sound card cannot provide precise DMA position instead > of maximum period size/time ? Probably not, because the rewinds are exposed in the public PulseAudio APIs (in particular, via the last two parameters of pa_stream_write()). So it definitely should not use the maximum period time, but should also not derive one from the client-requested latency. A hard-coded default or a default from the config (i.e. the current situation) is therefore as good as one can get on BATCH cards regarding the period size. > > > > > For the record, disabling timer-based scheduling is IMHO a matter of > further discussion. As long as there is enough safeguard, I think that > timer-based scheduling can still be used, and is useful. A living proof > is the whole story with the snd-usb-audio driver where (justified) > addition of the BATCH flag was perceived as a performance regression and > not as a fix to some real and obvious problem. > > The point is some drivers use .periods_min = 1 > > Pulseaudio select minimum number of period It does not do that on BATCH cards. Or if it does, it is a bug. As for the rest of your arguments, you are just stating obvious and correct things, so I see no point in quoting them. Indeed, most of the work on PulseAudio side would mean choosing the correct period size, number of periods, wakeup threshold and rewind granularity for each possible situation. I should just do it when the needed API appears on the ALSA side :) -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-09 8:55 ` Alexander E. Patrakov 2014-09-09 9:08 ` David Henningsson @ 2014-09-09 13:45 ` Clemens Ladisch 2014-09-09 15:55 ` Alexander E. Patrakov 1 sibling, 1 reply; 52+ messages in thread From: Clemens Ladisch @ 2014-09-09 13:45 UTC (permalink / raw) To: Alexander E. Patrakov, ALSA Development Mailing List, Takashi Iwai, David Henningsson, Takashi Sakamoto Alexander E. Patrakov wrote: > can the proposed heuristic (minimum period size for a given sample > rate, number of channels and sample format) be useful as an upper- > bound approximation of the pointer update granularity for cards that > are "rewindable even further than the nearest period"? No; USB precsion depends on the URB size, which is roughly proportional to (but smaller than) the period size. Regards, Clemens ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-09 13:45 ` Clemens Ladisch @ 2014-09-09 15:55 ` Alexander E. Patrakov 2014-09-09 16:09 ` Takashi Iwai 0 siblings, 1 reply; 52+ messages in thread From: Alexander E. Patrakov @ 2014-09-09 15:55 UTC (permalink / raw) To: Clemens Ladisch, ALSA Development Mailing List, Takashi Iwai, David Henningsson, Takashi Sakamoto 09.09.2014 19:45, Clemens Ladisch wrote: > Alexander E. Patrakov wrote: >> can the proposed heuristic (minimum period size for a given sample >> rate, number of channels and sample format) be useful as an upper- >> bound approximation of the pointer update granularity for cards that >> are "rewindable even further than the nearest period"? > > No; USB precsion depends on the URB size, which is roughly proportional > to (but smaller than) the period size. Thanks for the explanation. It was very useful. At this point, I am tempted to not express this "less than the period size but depends on it" rule, and classify USB audio devices as "Rewindable down to the period size", even though it is a pessimization. Also (sorry for the off-topic) this explanation completely crystallizes my opinion about possible misuse of the SNDRV_PCM_INFO_BATCH flag in the snd-usb-audio driver or PulseAudio. My opinion now is: there is no misuse on either side. -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-09 15:55 ` Alexander E. Patrakov @ 2014-09-09 16:09 ` Takashi Iwai 0 siblings, 0 replies; 52+ messages in thread From: Takashi Iwai @ 2014-09-09 16:09 UTC (permalink / raw) To: Alexander E. Patrakov Cc: ALSA Development Mailing List, Clemens Ladisch, David Henningsson, Takashi Sakamoto At Tue, 09 Sep 2014 21:55:05 +0600, Alexander E. Patrakov wrote: > > 09.09.2014 19:45, Clemens Ladisch wrote: > > Alexander E. Patrakov wrote: > >> can the proposed heuristic (minimum period size for a given sample > >> rate, number of channels and sample format) be useful as an upper- > >> bound approximation of the pointer update granularity for cards that > >> are "rewindable even further than the nearest period"? > > > > No; USB precsion depends on the URB size, which is roughly proportional > > to (but smaller than) the period size. > > Thanks for the explanation. It was very useful. > > At this point, I am tempted to not express this "less than the period > size but depends on it" rule, and classify USB audio devices as > "Rewindable down to the period size", even though it is a pessimization. > > Also (sorry for the off-topic) this explanation completely crystallizes > my opinion about possible misuse of the SNDRV_PCM_INFO_BATCH flag in the > snd-usb-audio driver or PulseAudio. My opinion now is: there is no > misuse on either side. Well, it's not entirely a "misuse" in either side. The flag is merely a hint, and the current attitude of PA is in a safer side of the behavior this flag may indicate. Whether it's the best choice is another question, of course. After all, we certainly need some API to expose the granularity. This has been asked since long time ago, but it wasn't done simply because the demands (and specifications) haven't been clarified. Also, for rewinding, we may need to consider about the FIFO or other things on top of signal processing path. If the granularity defines the granularity of the hwptr *update*, it wouldn't be enough for defining a safe guard range. Currently, most of hardware have a small amount of FIFO that can be mostly ignored, fortunately, though. Takashi ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-07 15:16 Master Plan on rewinding Alexander E. Patrakov 2014-09-07 18:38 ` Tanu Kaskinen 2014-09-07 20:51 ` Clemens Ladisch @ 2014-09-07 23:12 ` David Henningsson 2014-09-09 19:56 ` Pierre-Louis Bossart 2014-09-08 7:34 ` Lars-Peter Clausen ` (3 subsequent siblings) 6 siblings, 1 reply; 52+ messages in thread From: David Henningsson @ 2014-09-07 23:12 UTC (permalink / raw) To: Alexander E. Patrakov, ALSA Development Mailing List, Takashi Iwai, Takashi Sakamoto Cc: Pierre-Louis Bossart On 2014-09-07 17:16, Alexander E. Patrakov wrote: > Hello. > > (TL;DR: nothing really new except the strawman proposal about threads > and the note about interaction of variable sample rate with rewindability) > > As Takashi Iwai told me that the audio miniconference is for discussion > only, and not for presentation of anything, I guess that I need to > present the plans and options now. That's why this e-mail. The goal > here, besides merely presenting the plan, is to identify points that > everyone agrees upon, so that they are not discussed pointlessly at the > miniconference. Also, this e-mail serves as a justification for the > pending seemingly-destructive work. > > First, the status quo. If anyone disagrees with the facts below, please > complain loudly, before I make any conclusions! > > 1. PulseAudio does not call snd_pcm_rewindable(), because for some ALSA > plugins it crashed. This crash is completely fixed in alsa-lib 1.0.28, > but in some cases snd_pcm_rewindable() still returns wrong results. I don't know if we ever tried snd_pcm_rewindable() in PulseAudio. > 2. PulseAudio blindly assumes that it can rewind up to hwbuf_frames - > (snd_pcm_avail() + rewind_safeguard) frames. The rewind safeguard is > needed due to reasons that I don't completely understand, but one of > them is imprecise reporting of the hardware pointer, and another one is > that the hardware transfers several bytes at a time, and the bytes we > need to overwrite may be already cached by the hardware. Pierre added the rewind safeguard due to DMA controller problems. IIRC, some DMA controllers go nuts (such as breaking the stream, causing interrupt storms, or something else seriously buggy) when trying to write to data that the DMA controller is just about to transfer. Pierre (now cc:ed) would know more about this than I do, though. In my world, since this is a very hardware near problem, ALSA rather than PulseAudio should take these kinds of problems into account when reporting back snd_pcm_rewindable() so PulseAudio does not have to. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-07 23:12 ` David Henningsson @ 2014-09-09 19:56 ` Pierre-Louis Bossart 2014-09-10 5:38 ` Alexander E. Patrakov 0 siblings, 1 reply; 52+ messages in thread From: Pierre-Louis Bossart @ 2014-09-09 19:56 UTC (permalink / raw) To: David Henningsson, Alexander E. Patrakov, ALSA Development Mailing List, Takashi Iwai, Takashi Sakamoto >> 2. PulseAudio blindly assumes that it can rewind up to hwbuf_frames - >> (snd_pcm_avail() + rewind_safeguard) frames. The rewind safeguard is >> needed due to reasons that I don't completely understand, but one of >> them is imprecise reporting of the hardware pointer, and another one is >> that the hardware transfers several bytes at a time, and the bytes we >> need to overwrite may be already cached by the hardware. > > Pierre added the rewind safeguard due to DMA controller problems. IIRC, > some DMA controllers go nuts (such as breaking the stream, causing > interrupt storms, or something else seriously buggy) when trying to > write to data that the DMA controller is just about to transfer. Pierre > (now cc:ed) would know more about this than I do, though. > > In my world, since this is a very hardware near problem, ALSA rather > than PulseAudio should take these kinds of problems into account when > reporting back snd_pcm_rewindable() so PulseAudio does not have to. Sorry to chime-in late on this, my real job keeps me busy. I would like to highlight that there is a fundamental conflict between requirements here. - for power consumption optimization, you want to let the hardware prefetch audio samples opportunistically and buffer as much as possible as close as possible to the serial link. Given the pressure on power optimizations these days, no one should expect the hardware buffering to reduce - and this buffering could vary depending on the platform power modes with the position of the DMA read pointer becoming less predictable. - for low-latency and user interaction, you want to rewind the write pointer as much as possible. The question is 'how much'. The reason why i introduced this 'rewind_safeguard' was to factor in a good-enough latency that no one would ever complain about and yet large enough to avoid using stale data. We could ask drivers to provide a conservative estimate of this safeguard, but asking for a dynamic query of a safe position or an empirical determination based on the min period size is really asking for trouble. At a given point, if you really need very low-latency, i.e. sub ms, you will need a dedicated configuration that probably doesn't rely on rewinds and you probably don't use PulseAudio in the first place. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-09 19:56 ` Pierre-Louis Bossart @ 2014-09-10 5:38 ` Alexander E. Patrakov 0 siblings, 0 replies; 52+ messages in thread From: Alexander E. Patrakov @ 2014-09-10 5:38 UTC (permalink / raw) To: Pierre-Louis Bossart, David Henningsson, ALSA Development Mailing List, Takashi Iwai, Takashi Sakamoto 10.09.2014 01:56, Pierre-Louis Bossart wrote: > >>> 2. PulseAudio blindly assumes that it can rewind up to hwbuf_frames - >>> (snd_pcm_avail() + rewind_safeguard) frames. The rewind safeguard is >>> needed due to reasons that I don't completely understand, but one of >>> them is imprecise reporting of the hardware pointer, and another one is >>> that the hardware transfers several bytes at a time, and the bytes we >>> need to overwrite may be already cached by the hardware. >> >> Pierre added the rewind safeguard due to DMA controller problems. IIRC, >> some DMA controllers go nuts (such as breaking the stream, causing >> interrupt storms, or something else seriously buggy) when trying to >> write to data that the DMA controller is just about to transfer. Pierre >> (now cc:ed) would know more about this than I do, though. >> >> In my world, since this is a very hardware near problem, ALSA rather >> than PulseAudio should take these kinds of problems into account when >> reporting back snd_pcm_rewindable() so PulseAudio does not have to. > > > Sorry to chime-in late on this, my real job keeps me busy. Better late than never. > I would like to highlight that there is a fundamental conflict between > requirements here. > - for power consumption optimization, you want to let the hardware > prefetch audio samples opportunistically and buffer as much as possible > as close as possible to the serial link. Given the pressure on power > optimizations these days, no one should expect the hardware buffering to > reduce - and this buffering could vary depending on the platform power > modes with the position of the DMA read pointer becoming less predictable. > - for low-latency and user interaction, you want to rewind the write > pointer as much as possible. Spot-on. > The question is 'how much'. The reason why i introduced this > 'rewind_safeguard' was to factor in a good-enough latency that no one > would ever complain about and yet large enough to avoid using stale data. > We could ask drivers to provide a conservative estimate of this > safeguard, but asking for a dynamic query of a safe position or an > empirical determination based on the min period size is really asking > for trouble. At a given point, if you really need very low-latency, i.e. > sub ms, you will need a dedicated configuration that probably doesn't > rely on rewinds and you probably don't use PulseAudio in the first place. Well, now there are two people criticizing the heuristic. I would like to retract it, but I currently can't, because there are no other constructive proposals. The best solution would indeed be if a driver provides a conservative estimate of the rewind safeguard, but the problem is that nobody will add this to old drivers for no-longer-manufactured hardware. So we either need some other heuristic here, or we have to allow rewinding further than the nearest period only on cards where drivers explicitly say OK by providing a safeguard value. But the later proposal kills power-efficient PulseAudio on old kernels that simply don't know how to provide this information. Surely you won't like it. -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-07 15:16 Master Plan on rewinding Alexander E. Patrakov ` (2 preceding siblings ...) 2014-09-07 23:12 ` David Henningsson @ 2014-09-08 7:34 ` Lars-Peter Clausen 2014-09-08 7:59 ` David Henningsson ` (2 subsequent siblings) 6 siblings, 0 replies; 52+ messages in thread From: Lars-Peter Clausen @ 2014-09-08 7:34 UTC (permalink / raw) To: Alexander E. Patrakov, ALSA Development Mailing List, Takashi Iwai, David Henningsson, Takashi Sakamoto On 09/07/2014 05:16 PM, Alexander E. Patrakov wrote: [...] > 2. PulseAudio blindly assumes that it can rewind up to hwbuf_frames - > (snd_pcm_avail() + rewind_safeguard) frames. The rewind safeguard is needed > due to reasons that I don't completely understand, but one of them is > imprecise reporting of the hardware pointer, and another one is that the > hardware transfers several bytes at a time, and the bytes we need to > overwrite may be already cached by the hardware. > Also at the time you will process the result form snd_pcm_avail() will be more than what was reported as the audio DMA keeps going in the background. [...] > For the allegedly existing cards where the pointer granularity is always the > same as the period size, Raymond's method will not work. However, I don't > know any concrete example of such card (I didn't look at snd-firewire in > detail, though). And in any case, my opinion is that this "pointer > granularity = period size" limitation on such cards can be treated as a > driver bug that needs to be fixed (by someone who knows the driver, not by > me). On cards where pointer updates happen only on interrupts, the driver > should not configure the card in such a way that one period visible to the > userspace corresponds to one interrupt. Instead, it should always configure > the card for the minimum possible period size, and report only part of the > period interrupts to period_elapsed(). I.e.: userspace asked for 2 periods > 64 ms each, but let's configure the card for, say, 64 periods 2 ms each, and > use the "extra" interrupts only for updating the pointer. > There are quite a few ASoC drivers that do have this restriction. For some of the drivers the restriction comes from the hardware itself for others it is while the hardware in theory supports it nobody bothered so far to implement this. I do not agree that this should be treated as a driver bug and that those drivers should increase the interrupt rate. Mainly because this is policy and the interrupt rate is configured by the application by setting the period size and the driver should not have to guess what kind of latency requirements the application has. If the application has lower latency requirements it needs to set a smaller period size. Unnecessarily increasing the interrupt rate has for example has a impact on power consumption which is something you'd like to keep low on battery powered devices. We should though expose the granularity with which the pointer is updated to userspace so it can make educated decisions on how to configure the period size. - Lars ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-07 15:16 Master Plan on rewinding Alexander E. Patrakov ` (3 preceding siblings ...) 2014-09-08 7:34 ` Lars-Peter Clausen @ 2014-09-08 7:59 ` David Henningsson 2014-09-08 8:46 ` Alexander E. Patrakov 2014-09-11 3:49 ` Raymond Yau 2014-09-13 18:35 ` Alexander E. Patrakov 6 siblings, 1 reply; 52+ messages in thread From: David Henningsson @ 2014-09-08 7:59 UTC (permalink / raw) To: Alexander E. Patrakov, ALSA Development Mailing List, Takashi Iwai, Takashi Sakamoto On 2014-09-07 17:16, Alexander E. Patrakov wrote: > Hello. > > (TL;DR: nothing really new except the strawman proposal about threads > and the note about interaction of variable sample rate with rewindability) So, having looked this through another time, it looks like we have three categories of ALSA devices, from rewindability point of view: 1) Not rewindable at all. 2) Rewindable down to the period size. 3) Rewindable even further than the nearest period, down to DMA transfer sizes or something else. This also requires the .pointer to have better granularity than the period size. So I think any is_seekable() call or flag should indicate whether the device is case 1), 2) or 3). And for case 3) perhaps also some indicator of the actual rewind granularity and/or safeguard. This should be enough for PA to be able to pick a suitable default latency. Case 1) is simple. Just let snd_pcm_rewindable return 0 and snd_pcm_rewind fail. If it doesn't, just fix it. (The extplug problem could be solved by PA having ifdefs depending on alsa-lib version, rather than making snd_pcm_rewind and snd_pcm_rewindable behave inconsistent.) For case 2) you seem to suggest to emulate case 3) by using either a low-latency thread, or by increasing the number of interrupts from the hardware. Either method will inevitably increase power consumption, and the former might also increase the risk of glitches. Therefore I think this is replacing something bad with something worse, because I would value low power consumption higher than better rewinding. Could we enable this functionality by explicit request by the application? Probably. E g, if the application sets a low period size but also sets the "disable period interrupts" flag, that could be an indicator that it wants lots of interrupts just to update the pointer, but nothing else. Maybe that's even the behaviour today (haven't checked). The low-latency thread approach could be implemented by a separate ioplug layer, so that people who want it could open "flexiblerewind:plug:hw:0" instead of "plug:hw:0". However, with my PA hat on, I would still say no to having PA use either of those by default, for power consumption reasons. With that in mind I suggest, just as you, that we add .rewind/.rewindable callbacks to the ioplug layer. Any ioplug using .transfer needs to implement that if it wants to support rewinding, otherwise that ioplug would fall into category 1). Does that make sense? It was a long email, so I might have missed something. :-) -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-08 7:59 ` David Henningsson @ 2014-09-08 8:46 ` Alexander E. Patrakov 2014-09-08 9:26 ` David Henningsson 0 siblings, 1 reply; 52+ messages in thread From: Alexander E. Patrakov @ 2014-09-08 8:46 UTC (permalink / raw) To: David Henningsson, ALSA Development Mailing List, Takashi Iwai, Takashi Sakamoto 08.09.2014 13:59, David Henningsson wrote: (First of all, a big thanks for being the first to talk constructively about the important problem of rewindability classes!) > On 2014-09-07 17:16, Alexander E. Patrakov wrote: >> Hello. >> >> (TL;DR: nothing really new except the strawman proposal about threads >> and the note about interaction of variable sample rate with >> rewindability) > > So, having looked this through another time, it looks like we have three > categories of ALSA devices, from rewindability point of view: > > 1) Not rewindable at all. > > 2) Rewindable down to the period size. > > 3) Rewindable even further than the nearest period, down to DMA > transfer sizes or something else. This also requires the .pointer to > have better granularity than the period size. > > So I think any is_seekable() call or flag should indicate whether the > device is case 1), 2) or 3). And for case 3) perhaps also some indicator > of the actual rewind granularity and/or safeguard. This should be enough > for PA to be able to pick a suitable default latency. So far, I agree. The big question now is: do we have enough correct data from the kernel to decide between cases 2 and 3? I am definitely not qualified enough to answer this or to add such interface, though. > Case 1) is simple. Just let snd_pcm_rewindable return 0 and > snd_pcm_rewind fail. If it doesn't, just fix it. (The extplug problem > could be solved by PA having ifdefs depending on alsa-lib version, > rather than making snd_pcm_rewind and snd_pcm_rewindable behave > inconsistent.) OK. But I don't think that the ifdef proposal is sufficient. If I understand correctly, it only covers the "new PA on old alsa-lib" problem, because we can't add these ifdefs to old PA. That's still progress! But the "keep the old implementation of rewind" was for the opposite problem - old PA on new alsa-lib which rightfully refuses to rewind. > For case 2) you seem to suggest to emulate case 3) by using either a > low-latency thread, or by increasing the number of interrupts from the > hardware. Either method will inevitably increase power consumption, and > the former might also increase the risk of glitches. Therefore I think > this is replacing something bad with something worse, because I would > value low power consumption higher than better rewinding. There is a slight misunderstanding above. I indeed proposed (and retracted the proposal when I knew that it happens on mobile devices) to emulate case 3 in case 2 by increasing the number of interrupts from the hardware. The proposal of a low-latency background thread was about emulating case 3 on case 1, and, so far, I have not retracted it, but I may do so in the future. As for power consumption increase, the argument is essentially a duplicate of the phrase "the downside is that all programs (not only those intending to do rewinds) now pay the cost of the background low-latency thread" from my original mail. In other words, I partially agree. This, if enabled unconditionally, indeed would lead to unnecessary power consumption increase for those applications that don't use rewinds. But for applications that want low latency or dynamic latency, there is no other way to get it, so it is wrong to talk about power consumption increase for such applications. > Could we enable this functionality by explicit request by the > application? Probably. E g, if the application sets a low period size > but also sets the "disable period interrupts" flag, that could be an > indicator that it wants lots of interrupts just to update the pointer, > but nothing else. Maybe that's even the behaviour today (haven't checked). A very good idea. > > The low-latency thread approach could be implemented by a separate > ioplug layer, so that people who want it could open > "flexiblerewind:plug:hw:0" instead of "plug:hw:0". Also a good idea. > However, with my PA hat on, I would still say no to having PA use either > of those by default, for power consumption reasons. I would also say no, but for a different reason (because, as I wrote above, the power-consumption reason is valid only for software that never wants to rewind and does not need low/dynamic latency, and PA does not fall into this category). My argument is that, in the case of PulseAudio, these emulations would just create an unnecessary layer of complexity. PulseAudio actively wants to know the device type (via the is_seekable() call), so it is reasonable for it to also deal with consequences, without the need for additional processing in the driver or for an extra thread. > With that in mind I suggest, just as you, that we add > .rewind/.rewindable callbacks to the ioplug layer. Any ioplug using > .transfer needs to implement that if it wants to support rewinding, > otherwise that ioplug would fall into category 1). > > Does that make sense? It was a long email, so I might have missed > something. :-) In fact, _I_ missed something when writing the original e-mail. I forgot to address your phrase from http://permalink.gmane.org/gmane.linux.alsa.devel/122191: > I understand that you have a mathematically perfect approach to this, as > well as other algorithms. This would indeed be the best goal, but given > an imperfect world, where we're forced to choose between > 1) no rewinding at all > 2) imperfect rewinding in the sense that it sometimes can produce > hearable artifacts > > ...I'm not sure 1) is always the right choice... Should we have a snd_pcm_open (or whatever else) flag for accepting imperfect rewind results? [anyway, I would say "no" to using it in PulseAudio] -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-08 8:46 ` Alexander E. Patrakov @ 2014-09-08 9:26 ` David Henningsson 2014-09-08 10:21 ` Alexander E. Patrakov 0 siblings, 1 reply; 52+ messages in thread From: David Henningsson @ 2014-09-08 9:26 UTC (permalink / raw) To: Alexander E. Patrakov, ALSA Development Mailing List, Takashi Iwai, Takashi Sakamoto On 2014-09-08 10:46, Alexander E. Patrakov wrote: > 08.09.2014 13:59, David Henningsson wrote: > > (First of all, a big thanks for being the first to talk constructively > about the important problem of rewindability classes!) > >> On 2014-09-07 17:16, Alexander E. Patrakov wrote: >>> Hello. >>> >>> (TL;DR: nothing really new except the strawman proposal about threads >>> and the note about interaction of variable sample rate with >>> rewindability) >> >> So, having looked this through another time, it looks like we have three >> categories of ALSA devices, from rewindability point of view: >> >> 1) Not rewindable at all. >> >> 2) Rewindable down to the period size. >> >> 3) Rewindable even further than the nearest period, down to DMA >> transfer sizes or something else. This also requires the .pointer to >> have better granularity than the period size. >> >> So I think any is_seekable() call or flag should indicate whether the >> device is case 1), 2) or 3). And for case 3) perhaps also some indicator >> of the actual rewind granularity and/or safeguard. This should be enough >> for PA to be able to pick a suitable default latency. > > So far, I agree. The big question now is: do we have enough correct data > from the kernel to decide between cases 2 and 3? I am definitely not > qualified enough to answer this or to add such interface, though. I'm quite certain that we don't have enough information coming through from the kernel. It's something we need to add if we end up deciding to implement hw_params_is_seekable. >> Case 1) is simple. Just let snd_pcm_rewindable return 0 and >> snd_pcm_rewind fail. If it doesn't, just fix it. (The extplug problem >> could be solved by PA having ifdefs depending on alsa-lib version, >> rather than making snd_pcm_rewind and snd_pcm_rewindable behave >> inconsistent.) > > OK. But I don't think that the ifdef proposal is sufficient. If I > understand correctly, it only covers the "new PA on old alsa-lib" > problem, because we can't add these ifdefs to old PA. That's still > progress! But the "keep the old implementation of rewind" was for the > opposite problem - old PA on new alsa-lib which rightfully refuses to > rewind. > >> For case 2) you seem to suggest to emulate case 3) by using either a >> low-latency thread, or by increasing the number of interrupts from the >> hardware. Either method will inevitably increase power consumption, and >> the former might also increase the risk of glitches. Therefore I think >> this is replacing something bad with something worse, because I would >> value low power consumption higher than better rewinding. > > There is a slight misunderstanding above. I indeed proposed (and > retracted the proposal when I knew that it happens on mobile devices) to > emulate case 3 in case 2 by increasing the number of interrupts from the > hardware. The proposal of a low-latency background thread was about > emulating case 3 on case 1, and, so far, I have not retracted it, but I > may do so in the future. Right. I guess the low-latency background thread can be used to emulate 3) on top of both 1) and 2). > This, if enabled unconditionally, indeed would lead to > unnecessary power consumption increase for those applications that don't > use rewinds. But for applications that want low latency or dynamic > latency, there is no other way to get it, so it is wrong to talk about > power consumption increase for such applications. Uhm, is the set of applications that want "low or dynamic latency" necessarily the same as the set that want rewinds? But that might be more of an academic question, I guess PA is the only one that does rewinds currently. Or are there more apps out there that do rewinds? I'm not sure I buy this point completely, but I can't come up with a good counterexample either, so maybe you're right. > My argument is that, in the case of > PulseAudio, these emulations would just create an unnecessary layer of > complexity. PulseAudio actively wants to know the device type (via the > is_seekable() call), so it is reasonable for it to also deal with > consequences, without the need for additional processing in the driver > or for an extra thread. Agreed. >> I understand that you have a mathematically perfect approach to this, as >> well as other algorithms. This would indeed be the best goal, but given >> an imperfect world, where we're forced to choose between >> 1) no rewinding at all >> 2) imperfect rewinding in the sense that it sometimes can produce >> hearable artifacts >> >> ...I'm not sure 1) is always the right choice... > > Should we have a snd_pcm_open (or whatever else) flag for accepting > imperfect rewind results? [anyway, I would say "no" to using it in > PulseAudio] Well, if we had one, and it defaulted to the old behaviour, I suppose that would solve the new alsa-lib on old PA problem? But I'm not sure it's worth the added complexity. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-08 9:26 ` David Henningsson @ 2014-09-08 10:21 ` Alexander E. Patrakov 2014-09-09 8:43 ` Clemens Ladisch 0 siblings, 1 reply; 52+ messages in thread From: Alexander E. Patrakov @ 2014-09-08 10:21 UTC (permalink / raw) To: David Henningsson, ALSA Development Mailing List, Takashi Iwai, Takashi Sakamoto 08.09.2014 15:26, David Henningsson wrote: > On 2014-09-08 10:46, Alexander E. Patrakov wrote: >> 08.09.2014 13:59, David Henningsson wrote: >> >> (First of all, a big thanks for being the first to talk constructively >> about the important problem of rewindability classes!) >> >>> On 2014-09-07 17:16, Alexander E. Patrakov wrote: >>>> Hello. >>>> >>>> (TL;DR: nothing really new except the strawman proposal about threads >>>> and the note about interaction of variable sample rate with >>>> rewindability) >>> >>> So, having looked this through another time, it looks like we have three >>> categories of ALSA devices, from rewindability point of view: >>> >>> 1) Not rewindable at all. >>> >>> 2) Rewindable down to the period size. >>> >>> 3) Rewindable even further than the nearest period, down to DMA >>> transfer sizes or something else. This also requires the .pointer to >>> have better granularity than the period size. >>> >>> So I think any is_seekable() call or flag should indicate whether the >>> device is case 1), 2) or 3). And for case 3) perhaps also some indicator >>> of the actual rewind granularity and/or safeguard. This should be enough >>> for PA to be able to pick a suitable default latency. >> >> So far, I agree. The big question now is: do we have enough correct data >> from the kernel to decide between cases 2 and 3? I am definitely not >> qualified enough to answer this or to add such interface, though. > > I'm quite certain that we don't have enough information coming through > from the kernel. It's something we need to add if we end up deciding to > implement hw_params_is_seekable. OK, but, given that we need this interface in order to avoid seeking on the DTS encoder (and to avoid creating a big buffer on it), I'd rather have this sooner than later. As a compromise, let's design the API with case 2 in mind, but only return cases 1 and 3 until we have enough information from the kernel to detect case 2 reliably. And, unless someone sends out a constructive proposal, let's defer the discussion of case 2 detection to the miniconference. (And users do complain about rewinding on dcaenc, because this rewind creates one or two invalid DTS frames in the middle of every volume change, and some receivers are slow to resynchronize). >> This, if enabled unconditionally, indeed would lead to >> unnecessary power consumption increase for those applications that don't >> use rewinds. But for applications that want low latency or dynamic >> latency, there is no other way to get it, so it is wrong to talk about >> power consumption increase for such applications. > > Uhm, is the set of applications that want "low or dynamic latency" > necessarily the same as the set that want rewinds? It is a superset. Applications that want low latency don't necessarily want rewinds, but they want high interrupt rate => high power consumption anyway. Applications that want dynamic latency will do rewinds, because this is the only way to get it, except always defaulting to sometimes-unnecessary low latency. > > But that might be more of an academic question, I guess PA is the only > one that does rewinds currently. Or are there more apps out there that > do rewinds? Right now it is indeed an academic question. However, earlier in this year I was contacted by Andrew Eikum who was trying to use rewinds in Wine and insisted that it is an ALSA bug when I told him that they cannot work on the default device. I am not sure whether I convinced him, because I did not use the "unsend bluetooth packets" wording back then. I cannot quote him now, because this was via IM, so quoting would be impolite. And, the log is on the other PC anyway. > I'm not sure I buy this point completely, but I can't come up with a > good counterexample either, so maybe you're right. > >> My argument is that, in the case of >> PulseAudio, these emulations would just create an unnecessary layer of >> complexity. PulseAudio actively wants to know the device type (via the >> is_seekable() call), so it is reasonable for it to also deal with >> consequences, without the need for additional processing in the driver >> or for an extra thread. > > Agreed. > >>> I understand that you have a mathematically perfect approach to this, as >>> well as other algorithms. This would indeed be the best goal, but given >>> an imperfect world, where we're forced to choose between >>> 1) no rewinding at all >>> 2) imperfect rewinding in the sense that it sometimes can produce >>> hearable artifacts >>> >>> ...I'm not sure 1) is always the right choice... >> >> Should we have a snd_pcm_open (or whatever else) flag for accepting >> imperfect rewind results? [anyway, I would say "no" to using it in >> PulseAudio] > > Well, if we had one, and it defaulted to the old behaviour, I suppose > that would solve the new alsa-lib on old PA problem? But I'm not sure > it's worth the added complexity. Understood. Yes, it would solve the problem, and I have no opinion so far whether it is worth the cost of complexity and of the bad default. This phrase from the documentation of snd_pcm_rewindable is also something to think about: """ Note: The snd_pcm_rewind() can accept bigger value than returned by this function. But it is not guaranteed that output stream will be consistent with bigger value. """ -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-08 10:21 ` Alexander E. Patrakov @ 2014-09-09 8:43 ` Clemens Ladisch 0 siblings, 0 replies; 52+ messages in thread From: Clemens Ladisch @ 2014-09-09 8:43 UTC (permalink / raw) To: Alexander E. Patrakov, David Henningsson, ALSA Development Mailing List, Takashi Iwai, Takashi Sakamoto Alexander E. Patrakov wrote: > This phrase from the documentation of snd_pcm_rewindable is also > something to think about: > > """ > Note: The snd_pcm_rewind() can accept bigger value than returned by > this function. But it is not guaranteed that output stream will be > consistent with bigger value. This phrase again assumes a ring buffer, i.e., it says that 1) there is a buffer, and applications can write _anywhere_ in it, but 2) if a plugin reduces the allowed range (with snd_pcm_rewindable()), it is likely that the plugin will not notice that some part of the buffer has changed. (The first part is not true for most unrewindable plugins.) Regards, Clemens ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-07 15:16 Master Plan on rewinding Alexander E. Patrakov ` (4 preceding siblings ...) 2014-09-08 7:59 ` David Henningsson @ 2014-09-11 3:49 ` Raymond Yau 2014-09-11 4:19 ` A. C. Censi 2014-09-11 5:28 ` Alexander E. Patrakov 2014-09-13 18:35 ` Alexander E. Patrakov 6 siblings, 2 replies; 52+ messages in thread From: Raymond Yau @ 2014-09-11 3:49 UTC (permalink / raw) To: Alexander E. Patrakov Cc: Takashi Iwai, ALSA Development Mailing List, David Henningsson, Takashi Sakamoto > > On my desktop PC, on snd-hda-intel with analog outputs for S16LE stereo, the granularity is 32 bytes (= 8 samples), and I get the pointer granularity of 64 bytes (=16 samples) over HDMI. The minimum period size is 32 samples in both cases. Do you mean hda-Intel does not support arbritray period size when you say the granularity is 32 bytes ? However the granularity of the emulated hda sound card inside any VM depend on the vm and the backend audio system and sound card ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-11 3:49 ` Raymond Yau @ 2014-09-11 4:19 ` A. C. Censi 2014-09-13 9:15 ` Raymond Yau 2014-09-11 5:28 ` Alexander E. Patrakov 1 sibling, 1 reply; 52+ messages in thread From: A. C. Censi @ 2014-09-11 4:19 UTC (permalink / raw) To: Raymond Yau Cc: Takashi Iwai, ALSA Development Mailing List, Alexander E. Patrakov, David Henningsson, Takashi Sakamoto > However the granularity of the emulated hda sound card inside any VM depend on the vm and the backend audio system and sound card Obviously it is a "virtual granularity". ACC On Sep 11, 2014 12:49 AM, "Raymond Yau" <superquad.vortex2@gmail.com> wrote: > > > > On my desktop PC, on snd-hda-intel with analog outputs for S16LE stereo, > the granularity is 32 bytes (= 8 samples), and I get the pointer > granularity of 64 bytes (=16 samples) over HDMI. The minimum period size is > 32 samples in both cases. > > Do you mean hda-Intel does not support arbritray period size when you say > the granularity is 32 bytes ? > > However the granularity of the emulated hda sound card inside any VM depend > on the vm and the backend audio system and sound card > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-11 4:19 ` A. C. Censi @ 2014-09-13 9:15 ` Raymond Yau 0 siblings, 0 replies; 52+ messages in thread From: Raymond Yau @ 2014-09-13 9:15 UTC (permalink / raw) To: A. C. Censi Cc: Takashi Iwai, ALSA Development Mailing List, Alexander E. Patrakov, David Henningsson, Takashi Sakamoto > > > However the granularity of the emulated hda sound card inside any VM depend on the vm and the backend audio system and sound card > > Obviously it is a "virtual granularity". > Seem emulate dma transfer http://git.kernel.org/cgit/virt/kvm/qemu-kvm.git/plain/hw/intel-hda.c But not all backend can provide same granularity http://git.kernel.org/cgit/virt/kvm/qemu-kvm.git/tree/audio ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-11 3:49 ` Raymond Yau 2014-09-11 4:19 ` A. C. Censi @ 2014-09-11 5:28 ` Alexander E. Patrakov 2014-09-11 6:21 ` Raymond Yau 2014-09-13 8:57 ` Raymond Yau 1 sibling, 2 replies; 52+ messages in thread From: Alexander E. Patrakov @ 2014-09-11 5:28 UTC (permalink / raw) To: Raymond Yau Cc: Takashi Iwai, ALSA Development Mailing List, David Henningsson, Takashi Sakamoto 11.09.2014 09:49, Raymond Yau wrote: > > > > > On my desktop PC, on snd-hda-intel with analog outputs for S16LE > stereo, the granularity is 32 bytes (= 8 samples), and I get the pointer > granularity of 64 bytes (=16 samples) over HDMI. The minimum period size > is 32 samples in both cases. > > Do you mean hda-Intel does not support arbritray period size when you > say the granularity is 32 bytes ? > > However the granularity of the emulated hda sound card inside any VM > depend on the vm and the backend audio system and sound card The precise meaning is defined here: http://mailman.alsa-project.org/pipermail/alsa-devel/2014-May/076475.html Of course the VM result would be different. -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-11 5:28 ` Alexander E. Patrakov @ 2014-09-11 6:21 ` Raymond Yau 2014-09-13 8:57 ` Raymond Yau 1 sibling, 0 replies; 52+ messages in thread From: Raymond Yau @ 2014-09-11 6:21 UTC (permalink / raw) To: Alexander E. Patrakov Cc: Takashi Iwai, ALSA Development Mailing List, David Henningsson, Takashi Sakamoto 2014-9-11 下午1:28 於 "Alexander E. Patrakov" <patrakov@gmail.com> 寫道: > > 11.09.2014 09:49, Raymond Yau wrote: >> >> >> > >> > On my desktop PC, on snd-hda-intel with analog outputs for S16LE >> stereo, the granularity is 32 bytes (= 8 samples), and I get the pointer >> granularity of 64 bytes (=16 samples) over HDMI. The minimum period size >> is 32 samples in both cases. >> >> Do you mean hda-Intel does not support arbritray period size when you >> say the granularity is 32 bytes ? >> >> However the granularity of the emulated hda sound card inside any VM >> depend on the vm and the backend audio system and sound card > > > The precise meaning is defined here: > > http://mailman.alsa-project.org/pipermail/alsa-devel/2014-May/076475.html > > Of course the VM result would be different. > > - http://git.kernel.org/cgit/virt/kvm/qemu-kvm.git/plain/hw/hda-audio.c /* audio in/out widget */ case AC_VERB_SET_CHANNEL_STREAMID: st = a->st + node->stindex; if (st->node == NULL) { goto fail; } hda_audio_set_running(st, false); st->stream = (payload >> 4) & 0x0f; st->channel = payload & 0x0f; dprint(a, 2, "%s: stream %d, channel %d\n", st->node->name, st->stream, st->channel); hda_audio_set_running(st, a->running_real[st->output * 16 + st->stream]); hda_codec_response(hda, true, 0); break; It seem some vm just emulate start/stop of playback/capture , it does not update any hda controller registers, this mean that it won't support rewind _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-11 5:28 ` Alexander E. Patrakov 2014-09-11 6:21 ` Raymond Yau @ 2014-09-13 8:57 ` Raymond Yau 2014-09-13 10:43 ` Alexander E. Patrakov 1 sibling, 1 reply; 52+ messages in thread From: Raymond Yau @ 2014-09-13 8:57 UTC (permalink / raw) To: Alexander E. Patrakov Cc: Takashi Iwai, ALSA Development Mailing List, David Henningsson, Takashi Sakamoto >> >> > >> > On my desktop PC, on snd-hda-intel with analog outputs for S16LE >> stereo, the granularity is 32 bytes (= 8 samples), and I get the pointer >> granularity of 64 bytes (=16 samples) over HDMI. The minimum period size >> is 32 samples in both cases. >> >> Do you mean hda-Intel does not support arbritray period size when you >> say the granularity is 32 bytes ? >> >> However the granularity of the emulated hda sound card inside any VM >> depend on the vm and the backend audio system and sound card > > > The precise meaning is defined here: > > http://mailman.alsa-project.org/pipermail/alsa-devel/2014-May/076475.html Do you mean the different hda controllers may have different granularity ? Do your two hda controllers have different Fifo size ? ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-13 8:57 ` Raymond Yau @ 2014-09-13 10:43 ` Alexander E. Patrakov 2014-09-13 11:33 ` Raymond Yau 0 siblings, 1 reply; 52+ messages in thread From: Alexander E. Patrakov @ 2014-09-13 10:43 UTC (permalink / raw) To: Raymond Yau Cc: Takashi Iwai, ALSA Development Mailing List, David Henningsson, Takashi Sakamoto 13.09.2014 14:57, Raymond Yau wrote: > > >> > >> > > >> > On my desktop PC, on snd-hda-intel with analog outputs for S16LE > >> stereo, the granularity is 32 bytes (= 8 samples), and I get the pointer > >> granularity of 64 bytes (=16 samples) over HDMI. The minimum period size > >> is 32 samples in both cases. > >> > >> Do you mean hda-Intel does not support arbritray period size when you > >> say the granularity is 32 bytes ? > >> > >> However the granularity of the emulated hda sound card inside any VM > >> depend on the vm and the backend audio system and sound card > > > > > > The precise meaning is defined here: > > > > http://mailman.alsa-project.org/pipermail/alsa-devel/2014-May/076475.html > > Do you mean the different hda controllers may have different granularity ? Yes. My two hda controllers have different granularity. > Do your two hda controllers have different Fifo size ? If you mean the result of snd_pcm_hw_params_get_fifo_size(), then both cards return 0. I call this function after snd_pcm_hw_params(), as recommended by the documentation. -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-13 10:43 ` Alexander E. Patrakov @ 2014-09-13 11:33 ` Raymond Yau 2014-09-13 11:36 ` Alexander E. Patrakov 0 siblings, 1 reply; 52+ messages in thread From: Raymond Yau @ 2014-09-13 11:33 UTC (permalink / raw) To: Alexander E. Patrakov Cc: Takashi Iwai, ALSA Development Mailing List, David Henningsson, Takashi Sakamoto 2014-9-13 下午6:43 於 "Alexander E. Patrakov" <patrakov@gmail.com> 寫道: > > 13.09.2014 14:57, Raymond Yau wrote: >> >> >> >> >> >> > >> >> > On my desktop PC, on snd-hda-intel with analog outputs for S16LE >> >> stereo, the granularity is 32 bytes (= 8 samples), and I get the pointer >> >> granularity of 64 bytes (=16 samples) over HDMI. The minimum period size >> >> is 32 samples in both cases. >> >> >> >> Do you mean hda-Intel does not support arbritray period size when you >> >> say the granularity is 32 bytes ? >> >> >> >> However the granularity of the emulated hda sound card inside any VM >> >> depend on the vm and the backend audio system and sound card >> > >> > >> > The precise meaning is defined here: >> > >> > http://mailman.alsa-project.org/pipermail/alsa-devel/2014-May/076475.html >> >> Do you mean the different hda controllers may have different granularity ? > > > Yes. My two hda controllers have different granularity. > > >> Do your two hda controllers have different Fifo size ? > > > If you mean the result of snd_pcm_hw_params_get_fifo_size(), then both cards return 0. I call this function after snd_pcm_hw_params(), as recommended by the documentation. Do your hda controllers OSDnFIFOS register match the granularity ? 3.3.40 Offset 90: {IOB}SDnFIFOS – Input/Output/Bidirectional Stream Descriptor n FIFO Size Length: 2 bytes Table 39. Stream Descriptor n FIFO Size Bit Type Reset Description 15:0 RO Imp.Dep FIFO Size (FIFOS): Indicates the maximum number of bytes that could be fetched by the controller at one time. This is the maximum number of bytes that may have been DMA‟d into memory but not yet transmitted on the link, and is also the maximum possible value that the LPIB count will increase by at one time. This number may be static to indicate a static buffer size, or may change after the data format has been programmed if the controller is able to vary its FIFO size based on the stream format. If it is able to change value after the data format has been programmed, the value update must happen immediately before the next read of the FIFOS register, and remain static until the next programming of data format. _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-13 11:33 ` Raymond Yau @ 2014-09-13 11:36 ` Alexander E. Patrakov 0 siblings, 0 replies; 52+ messages in thread From: Alexander E. Patrakov @ 2014-09-13 11:36 UTC (permalink / raw) To: Raymond Yau Cc: Takashi Iwai, ALSA Development Mailing List, David Henningsson, Takashi Sakamoto 13.09.2014 17:33, Raymond Yau wrote: > > 2014-9-13 下午6:43 於 "Alexander E. Patrakov" <patrakov@gmail.com > <mailto:patrakov@gmail.com>> 寫道: > > > > 13.09.2014 14:57, Raymond Yau wrote: > >> > >> > >> >> > >> >> > > >> >> > On my desktop PC, on snd-hda-intel with analog outputs for S16LE > >> >> stereo, the granularity is 32 bytes (= 8 samples), and I get the > pointer > >> >> granularity of 64 bytes (=16 samples) over HDMI. The minimum > period size > >> >> is 32 samples in both cases. > >> >> > >> >> Do you mean hda-Intel does not support arbritray period size > when you > >> >> say the granularity is 32 bytes ? > >> >> > >> >> However the granularity of the emulated hda sound card inside any VM > >> >> depend on the vm and the backend audio system and sound card > >> > > >> > > >> > The precise meaning is defined here: > >> > > >> > > http://mailman.alsa-project.org/pipermail/alsa-devel/2014-May/076475.html > >> > >> Do you mean the different hda controllers may have different > granularity ? > > > > > > Yes. My two hda controllers have different granularity. > > > > > >> Do your two hda controllers have different Fifo size ? > > > > > > If you mean the result of snd_pcm_hw_params_get_fifo_size(), then > both cards return 0. I call this function after snd_pcm_hw_params(), as > recommended by the documentation. > > Do your hda controllers OSDnFIFOS register match the granularity ? I don't know. Please send a program or a kernel patch that prints this value (including units - samples or bytes), otherwise I won't be able to answer. -- Alexander E. Patrakov _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-07 15:16 Master Plan on rewinding Alexander E. Patrakov ` (5 preceding siblings ...) 2014-09-11 3:49 ` Raymond Yau @ 2014-09-13 18:35 ` Alexander E. Patrakov 2014-09-14 11:37 ` Raymond Yau 6 siblings, 1 reply; 52+ messages in thread From: Alexander E. Patrakov @ 2014-09-13 18:35 UTC (permalink / raw) To: ALSA Development Mailing List, Takashi Iwai, David Henningsson, Takashi Sakamoto, Clemens Ladisch 07.09.2014 21:16, Alexander E. Patrakov wrote: > 1. PulseAudio does not call snd_pcm_rewindable(), because for some ALSA > plugins it crashed. This crash is completely fixed in alsa-lib 1.0.28, > but in some cases snd_pcm_rewindable() still returns wrong results. Bad news: even in 1.0.28, snd_pcm_rewindable() crashes for the file plugin due to recursion. So I was wrong when saying "fixed completely" :( > 3. On the hw plugin, I could demonstrate two other bugs regarding > snd_pcm_rewindable(): stale data and bogus negative return values. For all of the above issues, I have sent patches. > === On the rewind safeguard === Result 1: it has been decided that the return value of snd_pcm_rewindable() is not changed, and the safeguard is returned by a separate function. This would require documentation changes for snd_pcm_rewindable(), though, as it officially no longer returns "safe count of frames which can be rewinded". I have difficulty designing a better wording what the function actually means now. Result 2: the proposed heuristic has been rightfully and convincingly busted, but no alternatives were proposed. It is the top priority to get some constructive proposal here where to get the data, or a fallback plan for alsa-lib. A fallback plan is also needed for old kernels if the constructive proposal involves kernel changes. > === On non-rewindability of the rate plugin === Nothing more to discuss. > === On possibly-incomplete rewindability of the file plugin === Nothing more to discuss. > === On bogus rewindability of ladspa and extplug plugins === No conclusion. The proposed hack to leave the .rewind implementation in place for use by old PulseAudio has met some opposition, but not such definite and convincing opposition as to the rewind-safeguard and low-latency-thread proposals. The proposed alternative (to make a "disallow imperfect rewinds" flag, off by default) means more work for no gain, and David also doubts whether such flag is worth the complexity. It's also notable that nobody explicitly said "let's regress old pulseaudio on new alsa-lib on the obscure dca plugin in the name of clean code" - which would have also closed the question :) In fact, I am not really sure that everyone understands the problem. > === On bogus rewindability of some ioplug-based plugins === The "low-latency-thread in ioplug" idea has been rightfully busted, and transformed into the "flexiblerewind" plugin idea. However, that plugin found no users (as PulseAudio won't use it), and thus there is no incentive for me or anyone else to implement it. Nothing left to discuss. > === On the pulse plugin === We have reached an agreement that .rewindable and .rewind should be added to ioplug and used by the pulse plugin. Nothing more to discuss. > === On communication of non-rewindability to the program === We have very good progress here: recognition of three rewindability classes that seemingly nobody objects to. The wanted behavior of PulseAudio for each rewindability class is not something we currently fully agree upon, though, but I think that it will be more appropriate to discuss further when someone sends a PulseAudio patch making use of these classes. I.e. not now. It is very good that there is at least one more person (Pierre Bossart) who understands the inherent conflict of requirements. Transition plan remains to be discussed, but that's the same discussion as the one called for in the "rewind safeguard" part of the post. > === On the programmer expectations === > > (social issue) Resolved (was misinterpretation on my side). I have to submit the documentation patch. -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-13 18:35 ` Alexander E. Patrakov @ 2014-09-14 11:37 ` Raymond Yau 2014-09-14 12:07 ` Alexander E. Patrakov 0 siblings, 1 reply; 52+ messages in thread From: Raymond Yau @ 2014-09-14 11:37 UTC (permalink / raw) To: Alexander E. Patrakov Cc: Takashi Iwai, ALSA Development Mailing List, Clemens Ladisch, David Henningsson, Takashi Sakamoto > > >> === On the rewind safeguard === > > > Result 1: it has been decided that the return value of snd_pcm_rewindable() is not changed, and the safeguard is returned by a separate function. It is unlikely to return any value which is safe, it is the responsiability of the application to decide how much can be rewind If pulseaudio assume 20ms process time is require to process two seconds of audio and sleep for 1980ms, it should not assume cpu have infinite power what is the purpose of the timestamp ? Can the timestamp use to predict when will next period update occur if the timestamp is obtained at previous period update ? Why snd_pcm_rewind cannot return error when application just set stop threshold to buffer size and rewind more than the stop threshold ? :This would require documentation changes for snd_pcm_rewindable(), though, as it officially no longer returns "safe count of frames which can be rewinded". I have difficulty designing a better wording what the function actually means now. The word "safe" should be removed ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-14 11:37 ` Raymond Yau @ 2014-09-14 12:07 ` Alexander E. Patrakov 2014-09-15 2:43 ` Raymond Yau 2014-09-15 9:19 ` Takashi Iwai 0 siblings, 2 replies; 52+ messages in thread From: Alexander E. Patrakov @ 2014-09-14 12:07 UTC (permalink / raw) To: Raymond Yau Cc: Takashi Iwai, ALSA Development Mailing List, Clemens Ladisch, David Henningsson, Takashi Sakamoto 14.09.2014 17:37, Raymond Yau wrote: > > > > > > >> === On the rewind safeguard === > > > > > > Result 1: it has been decided that the return value of > snd_pcm_rewindable() is not changed, and the safeguard is returned by a > separate function. > > It is unlikely to return any value which is safe, it is the > responsiability of the application to decide how much can be rewind You are placing a responsibility on an application without giving it any means to make an informed decision. E.g. 4 ms is OK on snd-hda-intel, but definitely not OK on ymfpci even on infinitely fast CPU (because of the fixed 5 ms interrupt interval). The whole question here is: how is an application supposed to know that? > > If pulseaudio assume 20ms process time is require to process two seconds > of audio and sleep for 1980ms, it should not assume cpu have infinite power You are right. The safeguard interval is a sum of the CPU-independent but card-specific part (which is what is being talked about) and a CPU-specific part (which the application indeed should know). > > what is the purpose of the timestamp ? > > Can the timestamp use to predict when will next period update occur if > the timestamp is obtained at previous period update ? See http://0pointer.de/blog/projects/pulse-glitch-free.html > > Why snd_pcm_rewind cannot return error when application just set stop > threshold to buffer size and rewind more than the stop threshold ? I think it does. The problem (due to which we need a safeguard) is that the card-specific minimum number of not-really-rewindable samples exists. E.g., for ymfpci, that would be 5 ms. > > :This would require documentation changes for snd_pcm_rewindable(), > though, as it officially no longer returns "safe count of frames which > can be rewinded". I have difficulty designing a better wording what the > function actually means now. > > The word "safe" should be removed That's insufficient. The returned value is valid only in the ring-buffer model for a card that fetches samples absolutely uniformly one at a time, i.e. without any batching, updates the pointer at every played-back sample, and doesn't have any "don't overwrite what I am DMA-ing or I will kill you with IRQs" quirk. I.e., even with the infinitely fast CPU, an attempt to rewind as much as that function returns (and then overwrite) will yield a glitch (that may or may not be detected as xrun even if xrun detection is enabled). -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-14 12:07 ` Alexander E. Patrakov @ 2014-09-15 2:43 ` Raymond Yau 2014-09-15 9:19 ` Takashi Iwai 1 sibling, 0 replies; 52+ messages in thread From: Raymond Yau @ 2014-09-15 2:43 UTC (permalink / raw) To: Alexander E. Patrakov Cc: Takashi Iwai, ALSA Development Mailing List, Clemens Ladisch, David Henningsson, Takashi Sakamoto >> > >> >> === On the rewind safeguard === >> > >> > >> > Result 1: it has been decided that the return value of >> snd_pcm_rewindable() is not changed, and the safeguard is returned by a >> separate function. >> >> It is unlikely to return any value which is safe, it is the >> responsiability of the application to decide how much can be rewind > > > You are placing a responsibility on an application without giving it any means to make an informed decision. E.g. 4 ms is OK on snd-hda-intel, but definitely not OK on ymfpci even on infinitely fast CPU (because of the fixed 5 ms interrupt interval). The whole question here is: how is an application supposed to know that? > Take a look at patent US 20100131783 System and Method of Dynamically Switching Queue Threshold HDA may have different fifo threshold in different power states, the granularity is not fixed Twice the minimum period size/time is not any over estimate Glitching still occurs at switch sink / change in power state when you allow sound card run with lowest latency ? I don't think your proposal of having three different class of granularity is good idea ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-14 12:07 ` Alexander E. Patrakov 2014-09-15 2:43 ` Raymond Yau @ 2014-09-15 9:19 ` Takashi Iwai 2014-09-15 9:58 ` Alexander E. Patrakov 1 sibling, 1 reply; 52+ messages in thread From: Takashi Iwai @ 2014-09-15 9:19 UTC (permalink / raw) To: Alexander E. Patrakov Cc: Raymond Yau, ALSA Development Mailing List, Clemens Ladisch, David Henningsson, Takashi Sakamoto At Sun, 14 Sep 2014 18:07:23 +0600, Alexander E. Patrakov wrote: > > 14.09.2014 17:37, Raymond Yau wrote: > > > > > > > > > > >> === On the rewind safeguard === > > > > > > > > > Result 1: it has been decided that the return value of > > snd_pcm_rewindable() is not changed, and the safeguard is returned by a > > separate function. > > > > It is unlikely to return any value which is safe, it is the > > responsiability of the application to decide how much can be rewind > > You are placing a responsibility on an application without giving it any > means to make an informed decision. E.g. 4 ms is OK on snd-hda-intel, > but definitely not OK on ymfpci even on infinitely fast CPU (because of > the fixed 5 ms interrupt interval). The whole question here is: how is > an application supposed to know that? Well, maybe the word "safeguard" is somewhat confusing to be used as a driver API. There is no "safety" at all there. There is only "theoretically minimal" (and it often lies even if the hardware chip says so). How much value to be taken as "safeguard" is rather a choice by each application or sound backend. Right now, the only information we give from the sound driver is INFO_BATCH flag. And I agree with a bit more detailed information to be exposed from the driver -- but only if possible. This must be an optional information and not mandatory. Takashi ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-15 9:19 ` Takashi Iwai @ 2014-09-15 9:58 ` Alexander E. Patrakov 2014-09-15 10:08 ` Takashi Iwai 0 siblings, 1 reply; 52+ messages in thread From: Alexander E. Patrakov @ 2014-09-15 9:58 UTC (permalink / raw) To: Takashi Iwai Cc: Raymond Yau, ALSA Development Mailing List, Clemens Ladisch, David Henningsson, Takashi Sakamoto 15.09.2014 15:19, Takashi Iwai wrote: > At Sun, 14 Sep 2014 18:07:23 +0600, > Alexander E. Patrakov wrote: >> >> 14.09.2014 17:37, Raymond Yau wrote: >>> >>> > >>> > >>> >> === On the rewind safeguard === >>> > >>> > >>> > Result 1: it has been decided that the return value of >>> snd_pcm_rewindable() is not changed, and the safeguard is returned by a >>> separate function. >>> >>> It is unlikely to return any value which is safe, it is the >>> responsiability of the application to decide how much can be rewind >> >> You are placing a responsibility on an application without giving it any >> means to make an informed decision. E.g. 4 ms is OK on snd-hda-intel, >> but definitely not OK on ymfpci even on infinitely fast CPU (because of >> the fixed 5 ms interrupt interval). The whole question here is: how is >> an application supposed to know that? > > Well, maybe the word "safeguard" is somewhat confusing to be used as > a driver API. There is no "safety" at all there. There is only > "theoretically minimal" (and it often lies even if the hardware chip > says so). How much value to be taken as "safeguard" is rather a > choice by each application or sound backend. I agree with this "bad wording" remark. Let's talk about the "theoretically minimal non-rewindable amount of samples" from now on. > Right now, the only information we give from the sound driver is > INFO_BATCH flag. And I agree with a bit more detailed information to > be exposed from the driver -- but only if possible. This must be an > optional information and not mandatory. Here I mostly agree. Indeed, this INFO_BATCH flag exists. However, its documentation is so vague that IMHO a documentation patch is needed to legitimize its use as a "you must not leave less than one period when rewinding" indicator. Also, the documentation says about snd_pcm_hw_params_is_batch(): "This function should only be called when the configuration space contains a single configuration" - I believe that it is an error (and PulseAudio calls it without obeying this restriction), because this function is helpful exactly for choosing hardware parameters such as period size. May I write "if the configuration space contains more than one configuration, the result indicates whether a configuration exists where such double-buffering is done"? Also the documentation talks about "hardware", should I extend it to the whole plugin chain? As for the desire to export other information if available, it is certainly good. What remains not fully understood for me is the claim that the information already exposed by every driver (in the form of the minimal period size) is not useful. I understand that two people are against this idea, so it must be bad. But I must understand why. Is it because the minimum period size reported by some drivers (which ones are suspected, if any?) may be a lie? Clemens Ladisch mentioned USB as a counterexample, but it is a batch device for which the current period size is more relevant than the minimal one. Pierre-Louis Bossart just said that it is "really asking for trouble" without much explanation. Can anyone name a sound controller that is not of a batch variety, where the theoretically minimal non-rewindable amount of samples is, at some settings, higher than the reported minimum period size at the same number of channels, sample rate and sample format? [and yes, I understand that I can always cheat and say: let's change the definition of INFO_BATCH so that it includes such cases] -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-15 9:58 ` Alexander E. Patrakov @ 2014-09-15 10:08 ` Takashi Iwai 2014-09-15 17:01 ` Pierre-Louis Bossart 0 siblings, 1 reply; 52+ messages in thread From: Takashi Iwai @ 2014-09-15 10:08 UTC (permalink / raw) To: Alexander E. Patrakov Cc: Raymond Yau, ALSA Development Mailing List, Clemens Ladisch, David Henningsson, Takashi Sakamoto At Mon, 15 Sep 2014 15:58:42 +0600, Alexander E. Patrakov wrote: > > 15.09.2014 15:19, Takashi Iwai wrote: > > At Sun, 14 Sep 2014 18:07:23 +0600, > > Alexander E. Patrakov wrote: > >> > >> 14.09.2014 17:37, Raymond Yau wrote: > >>> > >>> > > >>> > > >>> >> === On the rewind safeguard === > >>> > > >>> > > >>> > Result 1: it has been decided that the return value of > >>> snd_pcm_rewindable() is not changed, and the safeguard is returned by a > >>> separate function. > >>> > >>> It is unlikely to return any value which is safe, it is the > >>> responsiability of the application to decide how much can be rewind > >> > >> You are placing a responsibility on an application without giving it any > >> means to make an informed decision. E.g. 4 ms is OK on snd-hda-intel, > >> but definitely not OK on ymfpci even on infinitely fast CPU (because of > >> the fixed 5 ms interrupt interval). The whole question here is: how is > >> an application supposed to know that? > > > > Well, maybe the word "safeguard" is somewhat confusing to be used as > > a driver API. There is no "safety" at all there. There is only > > "theoretically minimal" (and it often lies even if the hardware chip > > says so). How much value to be taken as "safeguard" is rather a > > choice by each application or sound backend. > > I agree with this "bad wording" remark. Let's talk about the > "theoretically minimal non-rewindable amount of samples" from now on. > > > Right now, the only information we give from the sound driver is > > INFO_BATCH flag. And I agree with a bit more detailed information to > > be exposed from the driver -- but only if possible. This must be an > > optional information and not mandatory. > > Here I mostly agree. > > Indeed, this INFO_BATCH flag exists. However, its documentation is so > vague that IMHO a documentation patch is needed to legitimize its use as > a "you must not leave less than one period when rewinding" indicator. > Also, the documentation says about snd_pcm_hw_params_is_batch(): "This > function should only be called when the configuration space contains a > single configuration" - I believe that it is an error (and PulseAudio > calls it without obeying this restriction), because this function is > helpful exactly for choosing hardware parameters such as period size. > May I write "if the configuration space contains more than one > configuration, the result indicates whether a configuration exists where > such double-buffering is done"? Also the documentation talks about > "hardware", should I extend it to the whole plugin chain? The whole hw_params_*() descriptions are something like bot-style tweets, we need a bit better texts there :) The batch parameter was (and partly is) indeed very ambiguous. Its usage has been materialized a few years ago. > As for the desire to export other information if available, it is > certainly good. > > What remains not fully understood for me is the claim that the > information already exposed by every driver (in the form of the minimal > period size) is not useful. I understand that two people are against > this idea, so it must be bad. But I must understand why. Is it because > the minimum period size reported by some drivers (which ones are > suspected, if any?) may be a lie? A kind of yes. Many drivers, especially the old ones, set the minimal period size without actually knowing the real limit. It tends to be smaller than the hardware really supports. This is, in most cases, just because no hardware spec defines that. So, it can't be blindly taken as the bottom line, unfortunately. That's why I suggested the new field would be optional; we simply don't know the value. Takashi > Clemens Ladisch mentioned USB as a counterexample, but it is a batch > device for which the current period size is more relevant than the > minimal one. Pierre-Louis Bossart just said that it is "really asking > for trouble" without much explanation. > > Can anyone name a sound controller that is not of a batch variety, where > the theoretically minimal non-rewindable amount of samples is, at some > settings, higher than the reported minimum period size at the same > number of channels, sample rate and sample format? > > [and yes, I understand that I can always cheat and say: let's change the > definition of INFO_BATCH so that it includes such cases] > > -- > Alexander E. Patrakov > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-15 10:08 ` Takashi Iwai @ 2014-09-15 17:01 ` Pierre-Louis Bossart 2014-09-15 17:14 ` Alexander E. Patrakov 0 siblings, 1 reply; 52+ messages in thread From: Pierre-Louis Bossart @ 2014-09-15 17:01 UTC (permalink / raw) To: Takashi Iwai, Alexander E. Patrakov Cc: Raymond Yau, ALSA Development Mailing List, Clemens Ladisch, David Henningsson, Takashi Sakamoto >> What remains not fully understood for me is the claim that the >> information already exposed by every driver (in the form of the minimal >> period size) is not useful. I understand that two people are against >> this idea, so it must be bad. But I must understand why. Is it because >> the minimum period size reported by some drivers (which ones are >> suspected, if any?) may be a lie? > > A kind of yes. Many drivers, especially the old ones, set the minimal > period size without actually knowing the real limit. It tends to be > smaller than the hardware really supports. This is, in most cases, > just because no hardware spec defines that. So, it can't be blindly > taken as the bottom line, unfortunately. That's why I suggested the > new field would be optional; we simply don't know the value. Agree with Takashi, even recent audio IP tend to be reused in various ways (buses, system agents, arbiters, DMA controllers, DDR controllers) and no one really knows what the rewind granularity is, it's not a metric that's tracked. I actually liked the heuristic that's present in PulseAudio: constrain the safeguard to 256 bytes or 1ms (the last part would actually be fixed, it's currently not dependent on the sink actual rate and number of channels). we could introduce an optional query drivers for this but I wonder if it's worth the effort. -Pierre ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-15 17:01 ` Pierre-Louis Bossart @ 2014-09-15 17:14 ` Alexander E. Patrakov 2014-09-15 18:08 ` Takashi Iwai 0 siblings, 1 reply; 52+ messages in thread From: Alexander E. Patrakov @ 2014-09-15 17:14 UTC (permalink / raw) To: Pierre-Louis Bossart, Takashi Iwai Cc: Raymond Yau, ALSA Development Mailing List, Clemens Ladisch, David Henningsson, Takashi Sakamoto 15.09.2014 23:01, Pierre-Louis Bossart wrote: > >>> What remains not fully understood for me is the claim that the >>> information already exposed by every driver (in the form of the minimal >>> period size) is not useful. I understand that two people are against >>> this idea, so it must be bad. But I must understand why. Is it because >>> the minimum period size reported by some drivers (which ones are >>> suspected, if any?) may be a lie? >> >> A kind of yes. Many drivers, especially the old ones, set the minimal >> period size without actually knowing the real limit. It tends to be >> smaller than the hardware really supports. This is, in most cases, >> just because no hardware spec defines that. So, it can't be blindly >> taken as the bottom line, unfortunately. That's why I suggested the >> new field would be optional; we simply don't know the value. > > Agree with Takashi, even recent audio IP tend to be reused in various > ways (buses, system agents, arbiters, DMA controllers, DDR controllers) > and no one really knows what the rewind granularity is, it's not a > metric that's tracked. > > I actually liked the heuristic that's present in PulseAudio: constrain > the safeguard to 256 bytes or 1ms (the last part would actually be > fixed, it's currently not dependent on the sink actual rate and number > of channels). we could introduce an optional query drivers for this but > I wonder if it's worth the effort. OK, a direct question then. The "256 bytes or 1 ms" heuristic is known not to work on ymfpci. Should we bump it to "5.3 ms or 256 samples", or make configurable, or ask the ymfpci maintainer to add the INFO_BATCH flag to that driver? -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-15 17:14 ` Alexander E. Patrakov @ 2014-09-15 18:08 ` Takashi Iwai 2014-09-18 1:15 ` Raymond Yau 0 siblings, 1 reply; 52+ messages in thread From: Takashi Iwai @ 2014-09-15 18:08 UTC (permalink / raw) To: Alexander E. Patrakov Cc: ALSA Development Mailing List, Clemens Ladisch, Pierre-Louis Bossart, Takashi Sakamoto, Raymond Yau, David Henningsson At Mon, 15 Sep 2014 23:14:41 +0600, Alexander E. Patrakov wrote: > > 15.09.2014 23:01, Pierre-Louis Bossart wrote: > > > >>> What remains not fully understood for me is the claim that the > >>> information already exposed by every driver (in the form of the minimal > >>> period size) is not useful. I understand that two people are against > >>> this idea, so it must be bad. But I must understand why. Is it because > >>> the minimum period size reported by some drivers (which ones are > >>> suspected, if any?) may be a lie? > >> > >> A kind of yes. Many drivers, especially the old ones, set the minimal > >> period size without actually knowing the real limit. It tends to be > >> smaller than the hardware really supports. This is, in most cases, > >> just because no hardware spec defines that. So, it can't be blindly > >> taken as the bottom line, unfortunately. That's why I suggested the > >> new field would be optional; we simply don't know the value. > > > > Agree with Takashi, even recent audio IP tend to be reused in various > > ways (buses, system agents, arbiters, DMA controllers, DDR controllers) > > and no one really knows what the rewind granularity is, it's not a > > metric that's tracked. > > > > I actually liked the heuristic that's present in PulseAudio: constrain > > the safeguard to 256 bytes or 1ms (the last part would actually be > > fixed, it's currently not dependent on the sink actual rate and number > > of channels). we could introduce an optional query drivers for this but > > I wonder if it's worth the effort. > > OK, a direct question then. > > The "256 bytes or 1 ms" heuristic is known not to work on ymfpci. Should > we bump it to "5.3 ms or 256 samples", or make configurable, or ask the > ymfpci maintainer to add the INFO_BATCH flag to that driver? Adding INFO_BATCH would be a quick solution, indeed, although this isn't 100% right. Takashi ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-15 18:08 ` Takashi Iwai @ 2014-09-18 1:15 ` Raymond Yau 2014-09-21 9:22 ` Alexander E. Patrakov 2014-09-21 9:53 ` Clemens Ladisch 0 siblings, 2 replies; 52+ messages in thread From: Raymond Yau @ 2014-09-18 1:15 UTC (permalink / raw) To: Takashi Iwai Cc: ALSA Development Mailing List, Clemens Ladisch, Pierre-Louis Bossart, Takashi Sakamoto, Alexander E. Patrakov, David Henningsson > > > > > >>> What remains not fully understood for me is the claim that the > > >>> information already exposed by every driver (in the form of the minimal > > >>> period size) is not useful. I understand that two people are against > > >>> this idea, so it must be bad. But I must understand why. Is it because > > >>> the minimum period size reported by some drivers (which ones are > > >>> suspected, if any?) may be a lie? Does this mean the granularity of most drivers are only one period since most of them cannot reporte the dma position in realtime ? (e.g. pointer callback of Intel8x0 use a timeout loop to read the last valid index) The safeguard will be two periods If some HDA have FIFO size of 192 bytes which is more than the minimum period bytes Should we limit the start threshold to FIFO threshold or FIFO size ? Does it need Brust length = 1 for those hda controller to support arbitrary period size ? Seem only some hda controller can trigger DMA transfer at 1/3 or 2/3 FIFO buffer at different power states and report the dma position in pointer callback Does snd-oxygen provide this position with granularity which is less than the minimum period size ? ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-18 1:15 ` Raymond Yau @ 2014-09-21 9:22 ` Alexander E. Patrakov 2014-09-21 9:53 ` Clemens Ladisch 1 sibling, 0 replies; 52+ messages in thread From: Alexander E. Patrakov @ 2014-09-21 9:22 UTC (permalink / raw) To: Raymond Yau, Takashi Iwai Cc: ALSA Development Mailing List, Clemens Ladisch, Pierre-Louis Bossart, David Henningsson, Takashi Sakamoto 18.09.2014 07:15, Raymond Yau wrote: > > > > > > > > >>> What remains not fully understood for me is the claim that the > > > >>> information already exposed by every driver (in the form of the > minimal > > > >>> period size) is not useful. I understand that two people are > against > > > >>> this idea, so it must be bad. But I must understand why. Is it > because > > > >>> the minimum period size reported by some drivers (which ones are > > > >>> suspected, if any?) may be a lie? > > Does this mean the granularity of most drivers are only one period since > most of them cannot reporte the dma position in realtime ? I guess you are right. > > (e.g. pointer callback of Intel8x0 use a timeout loop to read the last > valid index) > > The safeguard will be two periods Here I don't see how that can be right. Even if the position is updated at each period interrupt, we always know which period is currently playing. So the theoretical minimum safeguard is exactly one period. Add 1 ms on top if you want to account for scheduler glitches. > > If some HDA have FIFO size of 192 bytes which is more than the minimum > period bytes > > Should we limit the start threshold to FIFO threshold or FIFO size ? I think that in this case it is a bug to report such small minimum period size. > Does it need Brust length = 1 for those hda controller to support > arbitrary period size ? > > Seem only some hda controller can trigger DMA transfer at 1/3 or 2/3 > FIFO buffer at different power states and report the dma position in > pointer callback I am not a specialist in HDA hardware. > Does snd-oxygen provide this position with granularity which is less > than the minimum period size ? I have a friend with a Xonar card, will ask him to perform a test for you when he appears online. -- Alexander E. Patrakov ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-18 1:15 ` Raymond Yau 2014-09-21 9:22 ` Alexander E. Patrakov @ 2014-09-21 9:53 ` Clemens Ladisch 2014-09-21 10:56 ` Alexander E. Patrakov 2014-09-22 3:27 ` Raymond Yau 1 sibling, 2 replies; 52+ messages in thread From: Clemens Ladisch @ 2014-09-21 9:53 UTC (permalink / raw) To: Raymond Yau Cc: ALSA Development Mailing List, Takashi Iwai, Pierre-Louis Bossart, Takashi Sakamoto, Alexander E. Patrakov, David Henningsson Raymond Yau wrote: > Does snd-oxygen provide this position with granularity which is less than > the minimum period size ? Yes. Its DMA controller uses a burst size of 32 bytes. The pointer registers are documented as reporting the position with 4-byte accuracy, but there were problems when the period/buffer sizes were not aligned to 32 bytes. I've set the minimum period size to 64 bytes, just to be safe. Regards, Clemens ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-21 9:53 ` Clemens Ladisch @ 2014-09-21 10:56 ` Alexander E. Patrakov 2014-09-22 3:27 ` Raymond Yau 1 sibling, 0 replies; 52+ messages in thread From: Alexander E. Patrakov @ 2014-09-21 10:56 UTC (permalink / raw) To: Clemens Ladisch, Raymond Yau Cc: Takashi Iwai, ALSA Development Mailing List, Pierre-Louis Bossart, David Henningsson, Takashi Sakamoto [-- Attachment #1: Type: text/plain, Size: 1025 bytes --] 21.09.2014 15:53, Clemens Ladisch wrote: > Raymond Yau wrote: >> Does snd-oxygen provide this position with granularity which is less than >> the minimum period size ? > > Yes. Its DMA controller uses a burst size of 32 bytes. The pointer registers > are documented as reporting the position with 4-byte accuracy, but there were > problems when the period/buffer sizes were not aligned to 32 bytes. I've set > the minimum period size to 64 bytes, just to be safe. Well, my friend has tested the card anyway, and I am afraid that the situation is in fact more complex than documented. Look how fast (8 samples per ioctl in a busy loop!) the card eats the first 256 samples. This is very suspicious, and I am not really sure whether we can actually perform a rewind over these 256 samples. The "usual" step of the pointer updates (via snd_pcm_avail) is indeed 8 samples = 32 bytes with some fine-grained updates sometimes showing up in the middle, which matches the documented burst size. -- Alexander E. Patrakov [-- Attachment #2: pcm_avail.c --] [-- Type: text/x-csrc, Size: 3669 bytes --] /* * This extra small demo sends silence to your speakers and tests the precision of the reported position. */ #include <asoundlib.h> #include <stdio.h> #include <stdlib.h> const char* device = "hw:0"; const int channels = 2; const snd_pcm_sframes_t period_size = 1024; const int periods = 4; const int rate = 48000; int main(int argc, char* argv[]) { int err; int failed = 0; unsigned int j; short *silence; snd_pcm_sframes_t avail = -1; snd_pcm_uframes_t min_period_size; snd_pcm_uframes_t boundary; int dir; snd_pcm_t *handle; snd_output_t *out = NULL; snd_pcm_hw_params_t *params; snd_pcm_sw_params_t *swparams; snd_pcm_hw_params_alloca(¶ms); snd_pcm_sw_params_alloca(&swparams); snd_output_stdio_attach(&out, stderr, 0); silence = calloc(period_size * periods, sizeof(short) * channels); if ((err = snd_pcm_open(&handle, device, SND_PCM_STREAM_PLAYBACK, 0)) < 0) { fprintf(stderr, "Playback open error: %s\n", snd_strerror(err)); exit(EXIT_FAILURE); } failed = (err = snd_pcm_hw_params_any(handle, params)) < 0; failed = failed || (err = snd_pcm_hw_params_set_rate_resample(handle, params, 1)) < 0; failed = failed || (err = snd_pcm_hw_params_set_access(handle, params, SND_PCM_ACCESS_RW_INTERLEAVED)) < 0; failed = failed || (err = snd_pcm_hw_params_set_format(handle, params, SND_PCM_FORMAT_S16)) < 0; failed = failed || (err = snd_pcm_hw_params_set_channels(handle, params, channels)) < 0; failed = failed || (err = snd_pcm_hw_params_set_rate(handle, params, rate, 0)) < 0; if (failed) { fprintf(stderr, "Playback hwparams (access & format) error: %s\n", snd_strerror(err)); exit(EXIT_FAILURE); } err = snd_pcm_hw_params_get_period_size_min(params, &min_period_size, &dir); if (err < 0) { fprintf(stderr, "Cannot get minimum period size: %s\n", snd_strerror(err)); } fprintf(stderr, "min_period_size: %d frames, dir: %d\n", (int)min_period_size, dir); failed = (err = snd_pcm_hw_params_set_period_size(handle, params, period_size, 0)) < 0; failed = failed || (err = snd_pcm_hw_params_set_periods(handle, params, periods, 0)) < 0; failed = failed || (err = snd_pcm_hw_params(handle, params)) < 0; if (failed) { fprintf(stderr, "Playback hwparams (period size & periods) error: %s\n", snd_strerror(err)); exit(EXIT_FAILURE); } err = snd_pcm_hw_params_get_fifo_size(params); if (err < 0) { fprintf(stderr, "Playback hwparams: can't get FIFO size, error: %s\n", snd_strerror(err)); } else { fprintf(stderr, "Playback hwparams: FIFO size is %d\n", err); } failed = (err = snd_pcm_sw_params_current(handle, swparams)) < 0; failed = failed || (err = snd_pcm_sw_params_set_start_threshold(handle, swparams, period_size)) < 0; failed = failed || (err = snd_pcm_sw_params_set_avail_min(handle, swparams, period_size)) < 0; failed = failed || (err = snd_pcm_sw_params(handle, swparams)) < 0; if (failed) { fprintf(stderr, "Playback swparams error: %s\n", snd_strerror(err)); exit(EXIT_FAILURE); } snd_pcm_dump(handle, out); fprintf(stderr, "Playing silence\n"); fflush(stderr); memset(silence, 0, period_size * periods * sizeof(short) * channels); err = snd_pcm_writei(handle, silence, period_size * periods); if (err < 0) { fprintf(stderr, "Playback error: %s\n", snd_strerror(err)); exit(EXIT_FAILURE); } j = 0; while (1) { snd_pcm_sframes_t avail1 = snd_pcm_avail(handle); if (avail1 < 0) break; if (avail != avail1) { fprintf(stderr, "Available: %d, loop iteration: %d\n", (int)avail1, j); } avail = avail1; j++; } snd_pcm_drop(handle); snd_pcm_close(handle); free(silence); return 0; } [-- Attachment #3: report.txt --] [-- Type: text/plain, Size: 22544 bytes --] min_period_size: 16 frames, dir: 0 Playback hwparams: FIFO size is 0 Hardware PCM card 0 'Xonar DX' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 4096 period_size : 1024 period_time : 21333 tstamp_mode : NONE period_step : 1 avail_min : 1024 period_event : 0 start_threshold : 1024 stop_threshold : 4096 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Playing silence Available: 16, loop iteration: 0 Available: 32, loop iteration: 1 Available: 40, loop iteration: 2 Available: 49, loop iteration: 3 Available: 56, loop iteration: 4 Available: 64, loop iteration: 5 Available: 72, loop iteration: 6 Available: 88, loop iteration: 7 Available: 96, loop iteration: 8 Available: 112, loop iteration: 9 Available: 120, loop iteration: 10 Available: 128, loop iteration: 11 Available: 144, loop iteration: 12 Available: 152, loop iteration: 13 Available: 164, loop iteration: 14 Available: 168, loop iteration: 15 Available: 176, loop iteration: 16 Available: 192, loop iteration: 17 Available: 200, loop iteration: 18 Available: 213, loop iteration: 19 Available: 216, loop iteration: 20 Available: 224, loop iteration: 21 Available: 240, loop iteration: 22 Available: 248, loop iteration: 23 Available: 256, loop iteration: 24 Available: 264, loop iteration: 66 Available: 272, loop iteration: 142 Available: 280, loop iteration: 219 Available: 286, loop iteration: 295 Available: 288, loop iteration: 296 Available: 296, loop iteration: 371 Available: 304, loop iteration: 447 Available: 312, loop iteration: 524 Available: 315, loop iteration: 600 Available: 320, loop iteration: 601 Available: 328, loop iteration: 676 Available: 336, loop iteration: 753 Available: 337, loop iteration: 829 Available: 344, loop iteration: 830 Available: 352, loop iteration: 905 Available: 360, loop iteration: 982 Available: 368, loop iteration: 1054 Available: 376, loop iteration: 1130 Available: 384, loop iteration: 1207 Available: 392, loop iteration: 1283 Available: 400, loop iteration: 1360 Available: 403, loop iteration: 1436 Available: 408, loop iteration: 1437 Available: 414, loop iteration: 1512 Available: 416, loop iteration: 1513 Available: 424, loop iteration: 1588 Available: 432, loop iteration: 1665 Available: 440, loop iteration: 1741 Available: 448, loop iteration: 1818 Available: 456, loop iteration: 1894 Available: 464, loop iteration: 1971 Available: 472, loop iteration: 2047 Available: 480, loop iteration: 2124 Available: 488, loop iteration: 2200 Available: 496, loop iteration: 2277 Available: 498, loop iteration: 2353 Available: 504, loop iteration: 2354 Available: 510, loop iteration: 2429 Available: 512, loop iteration: 2430 Available: 520, loop iteration: 2505 Available: 528, loop iteration: 2582 Available: 536, loop iteration: 2658 Available: 544, loop iteration: 2735 Available: 552, loop iteration: 2811 Available: 560, loop iteration: 2881 Available: 561, loop iteration: 2960 Available: 568, loop iteration: 2961 Available: 570, loop iteration: 3046 Available: 576, loop iteration: 3047 Available: 584, loop iteration: 3133 Available: 592, loop iteration: 3220 Available: 600, loop iteration: 3303 Available: 608, loop iteration: 3389 Available: 616, loop iteration: 3476 Available: 624, loop iteration: 3563 Available: 625, loop iteration: 3650 Available: 630, loop iteration: 3651 Available: 632, loop iteration: 3652 Available: 640, loop iteration: 3733 Available: 648, loop iteration: 3818 Available: 656, loop iteration: 3901 Available: 664, loop iteration: 3940 Available: 672, loop iteration: 4009 Available: 680, loop iteration: 4091 Available: 688, loop iteration: 4170 Available: 696, loop iteration: 4211 Available: 700, loop iteration: 4278 Available: 704, loop iteration: 4279 Available: 712, loop iteration: 4363 Available: 720, loop iteration: 4447 Available: 725, loop iteration: 4527 Available: 728, loop iteration: 4528 Available: 736, loop iteration: 4613 Available: 744, loop iteration: 4696 Available: 752, loop iteration: 4774 Available: 760, loop iteration: 4856 Available: 768, loop iteration: 4940 Available: 776, loop iteration: 5024 Available: 779, loop iteration: 5108 Available: 784, loop iteration: 5109 Available: 792, loop iteration: 5194 Available: 800, loop iteration: 5274 Available: 808, loop iteration: 5359 Available: 816, loop iteration: 5445 Available: 820, loop iteration: 5532 Available: 824, loop iteration: 5533 Available: 832, loop iteration: 5619 Available: 835, loop iteration: 5706 Available: 840, loop iteration: 5707 Available: 848, loop iteration: 5793 Available: 856, loop iteration: 5881 Available: 864, loop iteration: 5968 Available: 872, loop iteration: 6056 Available: 880, loop iteration: 6143 Available: 888, loop iteration: 6228 Available: 891, loop iteration: 6270 Available: 893, loop iteration: 6271 Available: 896, loop iteration: 6272 Available: 904, loop iteration: 6357 Available: 912, loop iteration: 6444 Available: 920, loop iteration: 6532 Available: 928, loop iteration: 6619 Available: 936, loop iteration: 6706 Available: 944, loop iteration: 6786 Available: 952, loop iteration: 6873 Available: 960, loop iteration: 6960 Available: 961, loop iteration: 7046 Available: 968, loop iteration: 7047 Available: 976, loop iteration: 7133 Available: 984, loop iteration: 7220 Available: 992, loop iteration: 7307 Available: 1000, loop iteration: 7394 Available: 1008, loop iteration: 7481 Available: 1016, loop iteration: 7568 Available: 1024, loop iteration: 7655 Available: 1032, loop iteration: 7738 Available: 1040, loop iteration: 7825 Available: 1048, loop iteration: 7912 Available: 1056, loop iteration: 7999 Available: 1064, loop iteration: 8086 Available: 1072, loop iteration: 8173 Available: 1080, loop iteration: 8260 Available: 1088, loop iteration: 8347 Available: 1096, loop iteration: 8434 Available: 1104, loop iteration: 8521 Available: 1112, loop iteration: 8608 Available: 1120, loop iteration: 8695 Available: 1128, loop iteration: 8782 Available: 1136, loop iteration: 8863 Available: 1144, loop iteration: 8949 Available: 1152, loop iteration: 9034 Available: 1160, loop iteration: 9119 Available: 1168, loop iteration: 9206 Available: 1170, loop iteration: 9293 Available: 1174, loop iteration: 9294 Available: 1176, loop iteration: 9295 Available: 1184, loop iteration: 9380 Available: 1192, loop iteration: 9466 Available: 1200, loop iteration: 9554 Available: 1208, loop iteration: 9641 Available: 1216, loop iteration: 9729 Available: 1220, loop iteration: 9816 Available: 1224, loop iteration: 9817 Available: 1232, loop iteration: 9903 Available: 1240, loop iteration: 9991 Available: 1248, loop iteration: 10078 Available: 1256, loop iteration: 10166 Available: 1264, loop iteration: 10253 Available: 1272, loop iteration: 10340 Available: 1280, loop iteration: 10427 Available: 1288, loop iteration: 10515 Available: 1296, loop iteration: 10602 Available: 1299, loop iteration: 10689 Available: 1304, loop iteration: 10690 Available: 1312, loop iteration: 10776 Available: 1313, loop iteration: 10863 Available: 1320, loop iteration: 10864 Available: 1328, loop iteration: 10948 Available: 1336, loop iteration: 11033 Available: 1344, loop iteration: 11120 Available: 1352, loop iteration: 11207 Available: 1360, loop iteration: 11295 Available: 1368, loop iteration: 11382 Available: 1376, loop iteration: 11468 Available: 1377, loop iteration: 11553 Available: 1384, loop iteration: 11554 Available: 1392, loop iteration: 11637 Available: 1400, loop iteration: 11722 Available: 1405, loop iteration: 11806 Available: 1408, loop iteration: 11807 Available: 1409, loop iteration: 11891 Available: 1416, loop iteration: 11892 Available: 1424, loop iteration: 11976 Available: 1432, loop iteration: 12056 Available: 1440, loop iteration: 12142 Available: 1448, loop iteration: 12229 Available: 1456, loop iteration: 12317 Available: 1464, loop iteration: 12404 Available: 1472, loop iteration: 12491 Available: 1480, loop iteration: 12578 Available: 1488, loop iteration: 12665 Available: 1496, loop iteration: 12753 Available: 1504, loop iteration: 12840 Available: 1512, loop iteration: 12927 Available: 1520, loop iteration: 12947 Available: 1528, loop iteration: 13026 Available: 1536, loop iteration: 13107 Available: 1544, loop iteration: 13180 Available: 1552, loop iteration: 13257 Available: 1553, loop iteration: 13331 Available: 1560, loop iteration: 13332 Available: 1568, loop iteration: 13400 Available: 1576, loop iteration: 13478 Available: 1584, loop iteration: 13560 Available: 1592, loop iteration: 13642 Available: 1600, loop iteration: 13724 Available: 1608, loop iteration: 13806 Available: 1616, loop iteration: 13888 Available: 1624, loop iteration: 13965 Available: 1626, loop iteration: 14043 Available: 1632, loop iteration: 14044 Available: 1640, loop iteration: 14117 Available: 1648, loop iteration: 14196 Available: 1656, loop iteration: 14275 Available: 1664, loop iteration: 14355 Available: 1672, loop iteration: 14435 Available: 1680, loop iteration: 14515 Available: 1688, loop iteration: 14595 Available: 1696, loop iteration: 14640 Available: 1704, loop iteration: 14717 Available: 1712, loop iteration: 14791 Available: 1720, loop iteration: 14871 Available: 1728, loop iteration: 14951 Available: 1736, loop iteration: 15031 Available: 1744, loop iteration: 15111 Available: 1752, loop iteration: 15192 Available: 1756, loop iteration: 15271 Available: 1760, loop iteration: 15272 Available: 1768, loop iteration: 15342 Available: 1776, loop iteration: 15423 Available: 1784, loop iteration: 15509 Available: 1792, loop iteration: 15596 Available: 1800, loop iteration: 15683 Available: 1808, loop iteration: 15770 Available: 1816, loop iteration: 15854 Available: 1824, loop iteration: 15934 Available: 1832, loop iteration: 16021 Available: 1840, loop iteration: 16108 Available: 1848, loop iteration: 16195 Available: 1856, loop iteration: 16282 Available: 1864, loop iteration: 16369 Available: 1872, loop iteration: 16456 Available: 1880, loop iteration: 16543 Available: 1888, loop iteration: 16630 Available: 1896, loop iteration: 16718 Available: 1904, loop iteration: 16803 Available: 1906, loop iteration: 16889 Available: 1912, loop iteration: 16890 Available: 1920, loop iteration: 16976 Available: 1928, loop iteration: 17063 Available: 1936, loop iteration: 17150 Available: 1944, loop iteration: 17237 Available: 1952, loop iteration: 17324 Available: 1960, loop iteration: 17411 Available: 1968, loop iteration: 17498 Available: 1976, loop iteration: 17585 Available: 1981, loop iteration: 17671 Available: 1984, loop iteration: 17672 Available: 1992, loop iteration: 17758 Available: 2000, loop iteration: 17845 Available: 2008, loop iteration: 17931 Available: 2016, loop iteration: 18018 Available: 2024, loop iteration: 18105 Available: 2032, loop iteration: 18192 Available: 2040, loop iteration: 18279 Available: 2048, loop iteration: 18366 Available: 2056, loop iteration: 18449 Available: 2064, loop iteration: 18536 Available: 2072, loop iteration: 18623 Available: 2080, loop iteration: 18710 Available: 2088, loop iteration: 18797 Available: 2096, loop iteration: 18882 Available: 2104, loop iteration: 18969 Available: 2112, loop iteration: 19056 Available: 2120, loop iteration: 19143 Available: 2128, loop iteration: 19230 Available: 2136, loop iteration: 19317 Available: 2144, loop iteration: 19404 Available: 2146, loop iteration: 19490 Available: 2152, loop iteration: 19491 Available: 2160, loop iteration: 19577 Available: 2168, loop iteration: 19664 Available: 2176, loop iteration: 19751 Available: 2184, loop iteration: 19838 Available: 2192, loop iteration: 19925 Available: 2200, loop iteration: 20012 Available: 2208, loop iteration: 20099 Available: 2216, loop iteration: 20186 Available: 2224, loop iteration: 20273 Available: 2229, loop iteration: 20359 Available: 2232, loop iteration: 20360 Available: 2240, loop iteration: 20446 Available: 2248, loop iteration: 20533 Available: 2256, loop iteration: 20618 Available: 2264, loop iteration: 20705 Available: 2272, loop iteration: 20792 Available: 2280, loop iteration: 20879 Available: 2288, loop iteration: 20963 Available: 2296, loop iteration: 21049 Available: 2297, loop iteration: 21135 Available: 2304, loop iteration: 21136 Available: 2312, loop iteration: 21222 Available: 2320, loop iteration: 21309 Available: 2326, loop iteration: 21395 Available: 2328, loop iteration: 21396 Available: 2336, loop iteration: 21482 Available: 2337, loop iteration: 21568 Available: 2344, loop iteration: 21569 Available: 2352, loop iteration: 21655 Available: 2360, loop iteration: 21742 Available: 2368, loop iteration: 21829 Available: 2376, loop iteration: 21916 Available: 2384, loop iteration: 22003 Available: 2392, loop iteration: 22090 Available: 2400, loop iteration: 22177 Available: 2408, loop iteration: 22264 Available: 2416, loop iteration: 22351 Available: 2424, loop iteration: 22438 Available: 2432, loop iteration: 22525 Available: 2440, loop iteration: 22612 Available: 2448, loop iteration: 22698 Available: 2456, loop iteration: 22785 Available: 2464, loop iteration: 22872 Available: 2472, loop iteration: 22959 Available: 2480, loop iteration: 23045 Available: 2488, loop iteration: 23132 Available: 2496, loop iteration: 23181 Available: 2497, loop iteration: 23259 Available: 2504, loop iteration: 23260 Available: 2512, loop iteration: 23345 Available: 2520, loop iteration: 23432 Available: 2528, loop iteration: 23519 Available: 2536, loop iteration: 23606 Available: 2544, loop iteration: 23693 Available: 2552, loop iteration: 23780 Available: 2560, loop iteration: 23867 Available: 2568, loop iteration: 23954 Available: 2576, loop iteration: 24041 Available: 2584, loop iteration: 24128 Available: 2590, loop iteration: 24214 Available: 2592, loop iteration: 24215 Available: 2600, loop iteration: 24301 Available: 2608, loop iteration: 24388 Available: 2616, loop iteration: 24475 Available: 2624, loop iteration: 24562 Available: 2632, loop iteration: 24649 Available: 2640, loop iteration: 24736 Available: 2644, loop iteration: 24822 Available: 2648, loop iteration: 24823 Available: 2656, loop iteration: 24909 Available: 2664, loop iteration: 24996 Available: 2672, loop iteration: 25081 Available: 2680, loop iteration: 25168 Available: 2688, loop iteration: 25255 Available: 2696, loop iteration: 25342 Available: 2704, loop iteration: 25429 Available: 2712, loop iteration: 25516 Available: 2715, loop iteration: 25602 Available: 2720, loop iteration: 25603 Available: 2728, loop iteration: 25689 Available: 2736, loop iteration: 25776 Available: 2744, loop iteration: 25863 Available: 2752, loop iteration: 25950 Available: 2760, loop iteration: 26037 Available: 2768, loop iteration: 26124 Available: 2771, loop iteration: 26210 Available: 2776, loop iteration: 26211 Available: 2784, loop iteration: 26297 Available: 2792, loop iteration: 26383 Available: 2800, loop iteration: 26464 Available: 2805, loop iteration: 26550 Available: 2808, loop iteration: 26551 Available: 2816, loop iteration: 26637 Available: 2824, loop iteration: 26724 Available: 2832, loop iteration: 26811 Available: 2840, loop iteration: 26898 Available: 2846, loop iteration: 26984 Available: 2848, loop iteration: 26985 Available: 2856, loop iteration: 27071 Available: 2864, loop iteration: 27155 Available: 2868, loop iteration: 27241 Available: 2872, loop iteration: 27242 Available: 2880, loop iteration: 27328 Available: 2888, loop iteration: 27415 Available: 2896, loop iteration: 27502 Available: 2898, loop iteration: 27588 Available: 2904, loop iteration: 27589 Available: 2912, loop iteration: 27675 Available: 2920, loop iteration: 27762 Available: 2928, loop iteration: 27846 Available: 2933, loop iteration: 27932 Available: 2936, loop iteration: 27933 Available: 2944, loop iteration: 28019 Available: 2952, loop iteration: 28106 Available: 2960, loop iteration: 28193 Available: 2962, loop iteration: 28279 Available: 2968, loop iteration: 28280 Available: 2976, loop iteration: 28366 Available: 2984, loop iteration: 28453 Available: 2992, loop iteration: 28539 Available: 3000, loop iteration: 28626 Available: 3008, loop iteration: 28713 Available: 3016, loop iteration: 28800 Available: 3024, loop iteration: 28887 Available: 3032, loop iteration: 28974 Available: 3040, loop iteration: 29061 Available: 3048, loop iteration: 29148 Available: 3056, loop iteration: 29233 Available: 3064, loop iteration: 29320 Available: 3072, loop iteration: 29407 Available: 3080, loop iteration: 29488 Available: 3088, loop iteration: 29575 Available: 3096, loop iteration: 29662 Available: 3104, loop iteration: 29749 Available: 3112, loop iteration: 29836 Available: 3120, loop iteration: 29923 Available: 3128, loop iteration: 30010 Available: 3136, loop iteration: 30097 Available: 3144, loop iteration: 30184 Available: 3152, loop iteration: 30271 Available: 3160, loop iteration: 30358 Available: 3165, loop iteration: 30444 Available: 3168, loop iteration: 30445 Available: 3176, loop iteration: 30531 Available: 3184, loop iteration: 30618 Available: 3192, loop iteration: 30705 Available: 3200, loop iteration: 30792 Available: 3208, loop iteration: 30879 Available: 3212, loop iteration: 30965 Available: 3216, loop iteration: 30966 Available: 3224, loop iteration: 31052 Available: 3232, loop iteration: 31139 Available: 3233, loop iteration: 31225 Available: 3240, loop iteration: 31226 Available: 3248, loop iteration: 31310 Available: 3256, loop iteration: 31390 Available: 3258, loop iteration: 31471 Available: 3264, loop iteration: 31472 Available: 3265, loop iteration: 31547 Available: 3272, loop iteration: 31548 Available: 3280, loop iteration: 31623 Available: 3288, loop iteration: 31701 Available: 3289, loop iteration: 31762 Available: 3296, loop iteration: 31763 Available: 3304, loop iteration: 31838 Available: 3312, loop iteration: 31919 Available: 3320, loop iteration: 32001 Available: 3328, loop iteration: 32083 Available: 3336, loop iteration: 32164 Available: 3344, loop iteration: 32243 Available: 3349, loop iteration: 32322 Available: 3352, loop iteration: 32323 Available: 3360, loop iteration: 32396 Available: 3368, loop iteration: 32476 Available: 3376, loop iteration: 32555 Available: 3384, loop iteration: 32631 Available: 3392, loop iteration: 32706 Available: 3400, loop iteration: 32780 Available: 3408, loop iteration: 32853 Available: 3416, loop iteration: 32927 Available: 3424, loop iteration: 33001 Available: 3432, loop iteration: 33074 Available: 3440, loop iteration: 33143 Available: 3442, loop iteration: 33215 Available: 3448, loop iteration: 33216 Available: 3452, loop iteration: 33282 Available: 3456, loop iteration: 33283 Available: 3464, loop iteration: 33351 Available: 3472, loop iteration: 33426 Available: 3480, loop iteration: 33502 Available: 3488, loop iteration: 33579 Available: 3496, loop iteration: 33655 Available: 3504, loop iteration: 33736 Available: 3512, loop iteration: 33817 Available: 3520, loop iteration: 33899 Available: 3528, loop iteration: 33981 Available: 3536, loop iteration: 34063 Available: 3544, loop iteration: 34144 Available: 3552, loop iteration: 34222 Available: 3553, loop iteration: 34300 Available: 3560, loop iteration: 34301 Available: 3568, loop iteration: 34374 Available: 3576, loop iteration: 34453 Available: 3578, loop iteration: 34533 Available: 3584, loop iteration: 34534 Available: 3592, loop iteration: 34608 Available: 3600, loop iteration: 34688 Available: 3608, loop iteration: 34768 Available: 3616, loop iteration: 34848 Available: 3624, loop iteration: 34928 Available: 3632, loop iteration: 35004 Available: 3640, loop iteration: 35083 Available: 3648, loop iteration: 35163 Available: 3656, loop iteration: 35244 Available: 3664, loop iteration: 35324 Available: 3666, loop iteration: 35403 Available: 3672, loop iteration: 35404 Available: 3680, loop iteration: 35478 Available: 3688, loop iteration: 35557 Available: 3696, loop iteration: 35635 Available: 3697, loop iteration: 35716 Available: 3704, loop iteration: 35717 Available: 3706, loop iteration: 35801 Available: 3712, loop iteration: 35802 Available: 3720, loop iteration: 35887 Available: 3728, loop iteration: 35974 Available: 3736, loop iteration: 36061 Available: 3744, loop iteration: 36148 Available: 3752, loop iteration: 36235 Available: 3760, loop iteration: 36322 Available: 3761, loop iteration: 36407 Available: 3768, loop iteration: 36408 Available: 3776, loop iteration: 36482 Available: 3784, loop iteration: 36568 Available: 3792, loop iteration: 36655 Available: 3800, loop iteration: 36742 Available: 3808, loop iteration: 36829 Available: 3809, loop iteration: 36915 Available: 3816, loop iteration: 36916 Available: 3824, loop iteration: 37000 Available: 3832, loop iteration: 37087 Available: 3840, loop iteration: 37174 Available: 3848, loop iteration: 37261 Available: 3856, loop iteration: 37348 Available: 3864, loop iteration: 37435 Available: 3872, loop iteration: 37522 Available: 3880, loop iteration: 37609 Available: 3888, loop iteration: 37696 Available: 3896, loop iteration: 37783 Available: 3899, loop iteration: 37869 Available: 3904, loop iteration: 37870 Available: 3912, loop iteration: 37956 Available: 3920, loop iteration: 38043 Available: 3928, loop iteration: 38130 Available: 3936, loop iteration: 38217 Available: 3937, loop iteration: 38303 Available: 3944, loop iteration: 38304 Available: 3952, loop iteration: 38390 Available: 3960, loop iteration: 38477 Available: 3968, loop iteration: 38564 Available: 3976, loop iteration: 38651 Available: 3984, loop iteration: 38737 Available: 3992, loop iteration: 38824 Available: 4000, loop iteration: 38911 Available: 4008, loop iteration: 38998 Available: 4016, loop iteration: 39081 Available: 4024, loop iteration: 39168 Available: 4032, loop iteration: 39255 Available: 4040, loop iteration: 39342 Available: 4048, loop iteration: 39429 Available: 4056, loop iteration: 39516 Available: 4058, loop iteration: 39602 Available: 4064, loop iteration: 39603 Available: 4072, loop iteration: 39689 Available: 4080, loop iteration: 39776 Available: 4088, loop iteration: 39863 [-- Attachment #4: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Master Plan on rewinding 2014-09-21 9:53 ` Clemens Ladisch 2014-09-21 10:56 ` Alexander E. Patrakov @ 2014-09-22 3:27 ` Raymond Yau 1 sibling, 0 replies; 52+ messages in thread From: Raymond Yau @ 2014-09-22 3:27 UTC (permalink / raw) To: Clemens Ladisch Cc: ALSA Development Mailing List, Takashi Iwai, Pierre-Louis Bossart, Takashi Sakamoto, Alexander E. Patrakov, David Henningsson > > Does snd-oxygen provide this position with granularity which is less than > > the minimum period size ? > > Yes. Its DMA controller uses a burst size of 32 bytes. The pointer registers > are documented as reporting the position with 4-byte accuracy, but there were > problems when the period/buffer sizes were not aligned to 32 bytes. I've set > the minimum period size to 64 bytes, just to be safe. > > The brust size is usually added to the constriants but the application cannot deduce this value err = snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 32); For those audio controllers have FIFO buffer, the application must keep the FIFO buffer full at any time for glitch free. Someone may argue that keeping at least one frame above FIFO threshold is just enough http://mailman.alsa-project.org/pipermail/alsa-devel/2014-September/081509.html I don't understand why the minimum buffer size can be less than FIFO size ^ permalink raw reply [flat|nested] 52+ messages in thread
end of thread, other threads:[~2014-09-23 10:21 UTC | newest] Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-09-07 15:16 Master Plan on rewinding Alexander E. Patrakov 2014-09-07 18:38 ` Tanu Kaskinen 2014-09-07 19:05 ` Alexander E. Patrakov 2014-09-07 20:51 ` Clemens Ladisch 2014-09-08 3:06 ` Raymond Yau 2014-09-08 7:31 ` Alexander E. Patrakov 2014-09-09 8:43 ` Clemens Ladisch 2014-09-09 8:55 ` Alexander E. Patrakov 2014-09-09 9:08 ` David Henningsson 2014-09-09 9:31 ` Alexander E. Patrakov 2014-09-21 2:02 ` Raymond Yau 2014-09-22 13:20 ` Lars-Peter Clausen 2014-09-22 13:36 ` Alexander E. Patrakov 2014-09-22 13:44 ` Lars-Peter Clausen 2014-09-23 8:29 ` Raymond Yau 2014-09-23 10:22 ` Alexander E. Patrakov 2014-09-09 13:45 ` Clemens Ladisch 2014-09-09 15:55 ` Alexander E. Patrakov 2014-09-09 16:09 ` Takashi Iwai 2014-09-07 23:12 ` David Henningsson 2014-09-09 19:56 ` Pierre-Louis Bossart 2014-09-10 5:38 ` Alexander E. Patrakov 2014-09-08 7:34 ` Lars-Peter Clausen 2014-09-08 7:59 ` David Henningsson 2014-09-08 8:46 ` Alexander E. Patrakov 2014-09-08 9:26 ` David Henningsson 2014-09-08 10:21 ` Alexander E. Patrakov 2014-09-09 8:43 ` Clemens Ladisch 2014-09-11 3:49 ` Raymond Yau 2014-09-11 4:19 ` A. C. Censi 2014-09-13 9:15 ` Raymond Yau 2014-09-11 5:28 ` Alexander E. Patrakov 2014-09-11 6:21 ` Raymond Yau 2014-09-13 8:57 ` Raymond Yau 2014-09-13 10:43 ` Alexander E. Patrakov 2014-09-13 11:33 ` Raymond Yau 2014-09-13 11:36 ` Alexander E. Patrakov 2014-09-13 18:35 ` Alexander E. Patrakov 2014-09-14 11:37 ` Raymond Yau 2014-09-14 12:07 ` Alexander E. Patrakov 2014-09-15 2:43 ` Raymond Yau 2014-09-15 9:19 ` Takashi Iwai 2014-09-15 9:58 ` Alexander E. Patrakov 2014-09-15 10:08 ` Takashi Iwai 2014-09-15 17:01 ` Pierre-Louis Bossart 2014-09-15 17:14 ` Alexander E. Patrakov 2014-09-15 18:08 ` Takashi Iwai 2014-09-18 1:15 ` Raymond Yau 2014-09-21 9:22 ` Alexander E. Patrakov 2014-09-21 9:53 ` Clemens Ladisch 2014-09-21 10:56 ` Alexander E. Patrakov 2014-09-22 3:27 ` Raymond Yau
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.