Re: [Audacity-devel] [Audacity-Team] Problems of Midi playback wtih ALSA
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Steve t. F. <ste...@gm...> - 2017-08-15 16:54:05
|
On 15 August 2017 at 16:14, Paul Licameli <pau...@gm...> wrote: > > > On Tue, Aug 15, 2017 at 8:42 AM, Steve the Fiddle <ste...@gm...> > wrote: >> >> On 14 August 2017 at 20:00, Paul Licameli <pau...@gm...> wrote: >> > >> > >> > On Mon, Aug 14, 2017 at 2:46 PM, Pokechu22 >> > <pok...@gm...> wrote: >> >> >> >> Would it be possible to replace PaUtil_GetTime with Pa_GetStreamTime? >> >> I >> >> checked some of the implementations (usually named GetStreamTime, which >> >> is >> >> then passed to PaUtil_InitializeStreamInterface) and some of them use >> >> PaUtil_GetTime while others use OS-specific methods. I haven't tested >> >> it, >> >> but I think it would also work fine for synchronizing. >> >> >> >> --Poke >> > >> > >> > Give it a try. See if you can base something on: >> > >> > >> > >> > https://github.com/Paul-Licameli/audacity/commit/a1f2a1598c5b1a4e2b19ef5ffd9f6199458f5581 >> >> Is this because you know what's wrong with >> >> https://github.com/Paul-Licameli/audacity/commit/5b4531bd09a998beb5bec30025d6b56e95ee94f9 >> or is it a stab in the dark? > > > No, you did not waste time, I mentioned the wrong commit. The one you > mentioned should be the base. > > I expect this rewrite without PaUtil_GetTime would be equivalent but avoid > the need for a change in lib-src. There has been a question whether the > build of Audacity on Linux should require the use of our own lib-src tree or > permit use of local libraries. So long as we rely on lib-src changes, we > should restrict the user's choice. Better then to avoid reliance on such > changes. > > But maybe I am wrong and indeed this change would also make the playback yet > better. > >> >> I've spent all morning testing >> >> https://github.com/Paul-Licameli/audacity/commit/5b4531bd09a998beb5bec30025d6b56e95ee94f9 >> Have I just wasted 4 hours? >> >> In brief, >> https://github.com/Paul-Licameli/audacity/commit/5b4531bd09a998beb5bec30025d6b56e95ee94f9 >> appears to be trying to synchronise MIDI to "something", but it is >> impossible to achieve consistent results. For example, setting the >> MIDI latency preference to 10 ms, on one run the notes play either 17 >> or 20 ms early (but not 18 to 19 ms early). On another run the notes >> play 15 or 17 ms early. With latency set to -5 ms, on one run the >> notes played 1, 3 or 4 ms late, and on another run they played 1, 3 or >> 4 ms early. >> >> Steve > > > So is it fair to state things positively: > > The freezing problem is now gone, or at least, not worsened above the > long-standing but 276. > The problem of stopping Midi playback too late after reaching the end of > selection -- you no longer mention. Is it gone too? > There is still some error in synchronization, but it is less than without > this change. > The synchronization errors are detectable with precise measurement but not > evident to the listener. > > In summary I think we can consider P1 level imperfections to be addressed > and Midi playback is good enough for a beta release now. > > Do you agree? My testing was aimed at providing useful diagnostics. In order to obtain accurate measurements and rule out several possible buffering issue from outside of Audacity, I was testing using Jack Audio System, with a low latency Linux kernel, high precision system clock, all carefully configured to give accurate and predictable performance. My reading of the diagnostic data is that we are handling synchronisation correctly, though we certainly don't have the critical problem that we started with (very positive progress). Out of the box with Audacity defaults, MIDI notes play about 0.45 seconds late (about 450 ms Latency), which can fluctuate by more than 50 ms, which at times is sufficient to produce noticeable rhythm changes in the music. Under the same conditions, MuseScore achieves +/- 10 ms precision in note timing, and latency is low enough to be barely noticeable (certainly *much* less than 450 ms). *** When using MuseScore with Jack, MIDI note playback time is sample accurate. *** On the positive side, we're not getting the freeze from MIDI playback (just the 'usual' PortAudio freeze), and playback has been stopping reliably at the end of the track. I think the progress made does bring it down from P1 but bear in mind that it has only been tested of a very few systems, and for a "flagship feature" the performance is currently not good. Steve > > About the remaining problems of synchronization -- maybe the rewrite withou > PaUtil_GetTIme will give even more precision (I doubt it), or maybe, the > inherent problem is that there are different threads emitting MIDI and > sample data, running with different priorities and time slices, and these > synchronization problems are just inherent in that. I can't think of an > easy way to improve it. > > PRL > > > >> >> >> > >> > This might be preferable if it works. Again, it would allow reversion >> > of >> > changes we made in lib-src (the extern "C" thing), which is nice. >> > >> > I think it could work, because GetStreamTime really is guaranteed to >> > have >> > the same origin as the times in PaStreamCallbackTimeInfo. >> > >> > PRL >> > >> >> >> >> On Mon, Aug 14, 2017 at 10:47 AM, Paul Licameli >> >> <pau...@gm...> >> >> wrote: >> >>> >> >>> >> >>> >> >>> On Mon, Aug 14, 2017 at 1:17 PM, Steve the Fiddle >> >>> <ste...@gm...> wrote: >> >>>> >> >>>> On 14 August 2017 at 12:30, Steve the Fiddle >> >>>> <ste...@gm...> >> >>>> wrote: >> >>>> > On 14 August 2017 at 12:12, Paul Licameli <pau...@gm...> >> >>>> > wrote: >> >>>> >> >> >>>> >> >> >>>> >> On Mon, Aug 14, 2017 at 6:59 AM, Steve the Fiddle >> >>>> >> <ste...@gm...> >> >>>> >> wrote: >> >>>> >>> >> >>>> >>> On 14 August 2017 at 11:27, Paul Licameli >> >>>> >>> <pau...@gm...> >> >>>> >>> wrote: >> >>>> >>> > >> >>>> >>> > >> >>>> >>> > On Mon, Aug 14, 2017 at 4:50 AM, Steve the Fiddle >> >>>> >>> > <ste...@gm...> >> >>>> >>> > wrote: >> >>>> >>> >> >> >>>> >>> >> On 14 August 2017 at 03:42, Paul Licameli >> >>>> >>> >> <pau...@gm...> >> >>>> >>> >> wrote: >> >>>> >>> >> > >> >>>> >>> >> > >> >>>> >>> >> > On Sun, Aug 13, 2017 at 3:01 PM, Steve the Fiddle >> >>>> >>> >> > <ste...@gm...> >> >>>> >>> >> > wrote: >> >>>> >>> >> >> >> >>>> >>> >> >> On 11 August 2017 at 00:52, Paul Licameli >> >>>> >>> >> >> <pau...@gm...> >> >>>> >>> >> >> wrote: >> >>>> >>> >> >> > So here is my alternative fix, which does not change >> >>>> >>> >> >> > lib-src. It >> >>>> >>> >> >> > changes >> >>>> >>> >> >> > code executed on any platform, but I verified at least on >> >>>> >>> >> >> > Mac that >> >>>> >>> >> >> > the >> >>>> >>> >> >> > numerical values don't change in AudioIO::MidiTime and >> >>>> >>> >> >> > the >> >>>> >>> >> >> > Midi >> >>>> >>> >> >> > play >> >>>> >>> >> >> > still >> >>>> >>> >> >> > works fine. >> >>>> >>> >> >> > >> >>>> >>> >> >> > >> >>>> >>> >> >> > >> >>>> >>> >> >> > >> >>>> >>> >> >> > >> >>>> >>> >> >> > >> >>>> >>> >> >> > https://github.com/Paul-Licameli/audacity/commit/a1f2a1598c5b1a4e2b19ef5ffd9f6199458f5581 >> >>>> >>> >> >> >> >>>> >>> >> >> This one allows MIDI to play, but I've had a couple of >> >>>> >>> >> >> freezes >> >>>> >>> >> >> with >> >>>> >>> >> >> it. On one occasion I was running in gdb when it froze so I >> >>>> >>> >> >> was able >> >>>> >>> >> >> to obtain the attached backtrace. >> >>>> >>> >> >> >> >>>> >>> >> >> When Audacity is playing and reaches the end of a note >> >>>> >>> >> >> track, >> >>>> >>> >> >> the >> >>>> >>> >> >> actual stop time is erratic. Sometimes play stops exactly >> >>>> >>> >> >> at >> >>>> >>> >> >> the end >> >>>> >>> >> >> of the track, but other times play may continue for several >> >>>> >>> >> >> seconds >> >>>> >>> >> >> beyond the end of the track. >> >>>> >>> >> >> >> >>>> >>> >> >> Also, I'm not sure how much accuracy to expect on this >> >>>> >>> >> >> laptop >> >>>> >>> >> >> (which >> >>>> >>> >> >> has not been optimised for audio), but the timing precision >> >>>> >>> >> >> seems >> >>>> >>> >> >> rather poor at around +/- 35ms (far enough out to be >> >>>> >>> >> >> noticeable, at >> >>>> >>> >> >> least for a musician). >> >>>> >>> >> >> >> >>>> >>> >> >> As I wrote previously, MIDI will play provided that the >> >>>> >>> >> >> time >> >>>> >>> >> >> returned >> >>>> >>> >> >> by AudioIO::MidiTime() is 'reasonable'. With this patch I >> >>>> >>> >> >> am >> >>>> >>> >> >> seeing >> >>>> >>> >> >> 'reasonable' times, but the issues noted above suggest that >> >>>> >>> >> >> we >> >>>> >>> >> >> may >> >>>> >>> >> >> still not be getting "the right" time. Any ideas how to >> >>>> >>> >> >> prove >> >>>> >>> >> >> that >> >>>> >>> >> >> one >> >>>> >>> >> >> way or the other? >> >>>> >>> >> >> >> >>>> >>> >> >> Steve >> >>>> >>> >> >> >> >>>> >>> >> > >> >>>> >>> >> > It seems, from thread 1, that you got this strack trace when >> >>>> >>> >> > you >> >>>> >>> >> > stopped >> >>>> >>> >> > play. I thought freezes happened spontaneously during play? >> >>>> >>> >> > But >> >>>> >>> >> > this >> >>>> >>> >> > is >> >>>> >>> >> > not an example of that. >> >>>> >>> >> > >> >>>> >>> >> > Examining the stack traces, I see >> >>>> >>> >> > >> >>>> >>> >> > In thread 95, PortAudio's CallbackThreadFunc calls OnExit >> >>>> >>> >> > which >> >>>> >>> >> > calls >> >>>> >>> >> > some >> >>>> >>> >> > Alsa which calls some PulseAudio which waits on a condition >> >>>> >>> >> > variable. >> >>>> >>> >> > In thread 94, PulseAudio is waiting to lock a mutex. >> >>>> >>> >> > Thread 93 is also involved in PulseAudio, but apparently in >> >>>> >>> >> > a >> >>>> >>> >> > polling >> >>>> >>> >> > loop, >> >>>> >>> >> > not blocking. >> >>>> >>> >> > Thread 8 is Audacity's AudioThread, which plays samples of >> >>>> >>> >> > wave >> >>>> >>> >> > tracks. >> >>>> >>> >> > Thread 7 is Audaicty's Midi Thread, sleeping as it does each >> >>>> >>> >> > time in >> >>>> >>> >> > the >> >>>> >>> >> > loop. >> >>>> >>> >> > Thread 1 is Audacity's main thread. >> >>>> >>> >> > >> >>>> >>> >> > Could it be that threads 94 and 95 are in a deadlock? That >> >>>> >>> >> > 95 >> >>>> >>> >> > holds >> >>>> >>> >> > a >> >>>> >>> >> > mutex >> >>>> >>> >> > that 94 wants, but 94 must make progress to signal the >> >>>> >>> >> > condition >> >>>> >>> >> > variable >> >>>> >>> >> > that 95 is waiting on? >> >>>> >>> >> > >> >>>> >>> >> > Could the deadlocking bug be in PulseAudio? There would be >> >>>> >>> >> > little >> >>>> >>> >> > hope >> >>>> >>> >> > of >> >>>> >>> >> > debugging that? >> >>>> >>> >> >> >>>> >>> >> This may be unrelated to MIDI. It could be bug 276. >> >>>> >>> >> http://bugzilla.audacityteam.org/show_bug.cgi?id=276 >> >>>> >>> > >> >>>> >>> > >> >>>> >>> > I thought the freezes you saw before happened during playback >> >>>> >>> > of >> >>>> >>> > Midi. >> >>>> >>> > >> >>>> >>> > This stack trace happened during stop of Midi playback with the >> >>>> >>> > Stop >> >>>> >>> > button >> >>>> >>> > or key, so it's not the same problem. Correct? >> >>>> >>> >> >>>> >>> The problem that I was getting in the original code was: >> >>>> >>> >> >>>> >>> 1) No MIDI playback >> >>>> >>> 2) MIDI events would be produced for a while, but not sent by >> >>>> >>> ALSA >> >>>> >>> 3) After a few hundred events, ALSA would block and Audacity >> >>>> >>> would >> >>>> >>> become stuck in a sleep loop as described in my original posts. >> >>>> >>> 4) On pressing Stop, or reaching the end of the selection, the >> >>>> >>> play >> >>>> >>> head would stop and Audacity would be frozen. >> >>>> >>> 5) On clicking the [X] close window button, nothing would happen >> >>>> >>> for >> >>>> >>> about 30 seconds, then an error message would pop up to say that >> >>>> >>> (words to the effect of) "Audacity is not responding, do you want >> >>>> >>> to >> >>>> >>> close this window?" >> >>>> >> >> >>>> >> >> >>>> >> I don't understand how 4 can follow 3. Once Audacity is stuck in >> >>>> >> the >> >>>> >> sleep >> >>>> >> loop, how could it respond at all to the Stop key? Did not the >> >>>> >> play >> >>>> >> head >> >>>> >> stop moving already once you are in the sleep loop? >> >>>> > >> >>>> > My intention was to describe accurately and clearly what happened >> >>>> > at >> >>>> > the time. >> >>>> > To give precise details of something that happened last week I will >> >>>> > have to rebuild that version of Audacity and retest, which I don't >> >>>> > have time to do right now. If it's important I'll do that when I >> >>>> > have >> >>>> > time, or you could dig out my old post to see whether I provided >> >>>> > the >> >>>> > information that you are asking for. >> >>>> > >> >>>> > The point is, I don't think that the most recent freeze is due to >> >>>> > MIDI >> >>>> > playback. I think it was probably bug 276. >> >>>> > >> >>>> >> >> >>>> >> Or is 4 alternative to 3, when you try to stop before the freeze >> >>>> >> in 3 >> >>>> >> can >> >>>> >> happen? >> >>>> >> >> >>>> >>> >> >>>> >>> >> >>>> >>> In the original code, it could be observed that Audacity had got >> >>>> >>> stuck >> >>>> >>> in AudioIO before playback was stopped. >> >>>> >>> >> >>>> >>> In this (new) case, MIDI playback was working until stop was >> >>>> >>> pressed, >> >>>> >>> so I think this is a different bug, and quite possibly bug 276. >> >>>> >> >> >>>> >> >> >>>> >> So the freeze peculiar to step 3 appears fixed which is good. >> >>>> >> >> >>>> >>> >> >>>> >>> >> >>>> >>> Generally I avoid bug 276 by not using PulseAudio, but to use >> >>>> >>> Audacity >> >>>> >>> with a software synth, PulseAudio must be used (unless the sound >> >>>> >>> card >> >>>> >>> itself supports multiple clients, which consumer level sound >> >>>> >>> cards >> >>>> >>> invariably don't these days). >> >>>> >>> >> >>>> >>> Steve >> >>>> >> >> >>>> >> >> >>>> >> Oh no, so does 1704 depend on 276 now? >> >>>> > >> >>>> > I'd say no, they are separate bugs. >> >>>> > >> >>>> >> >> >>>> >> Does this freeze during stop happen very often? Gale's >> >>>> >> description >> >>>> >> in bug >> >>>> >> 276 suggests it only happened if you start and stop many times >> >>>> >> rapidly. >> >>>> > >> >>>> > It's more common on some systems than others. >> >>>> > On both my current and previous laptops the problem has been >> >>>> > frequent >> >>>> > enough to make PulseAudio unusable with Audacity for real >> >>>> > production >> >>>> > work. If there wasn't a reasonable workaround it would b P1. >> >>>> > >> >>>> > >> >>>> >> >> >>>> >> Meanwhile I have proposed another change, but this might only fix >> >>>> >> that >> >>>> >> apparent negative latency that you reported. >> >>>> > >> >>>> > Are you referring to this one: >> >>>> > >> >>>> > >> >>>> > https://github.com/Paul-Licameli/audacity/commit/5b4531bd09a998beb5bec30025d6b56e95ee94f9 >> >>>> >> >>>> This one is quite encouraging. >> >>>> >> >>>> There are still some strange timing issues, but so far the "errors" >> >>>> appear to be consistent - that is, the time from one note to the next >> >>>> and the duration of each note now appears to be much more accurate, >> >>>> but I'm still seeing an offset from "track time" that I can't account >> >>>> for. I need to do more testing tomorrow, >> >>>> >> >>>> Steve >> >>> >> >>> >> >>> Good. >> >>> >> >>> Notice that usage of PaUtil_GetTime is back, and now in two places, >> >>> not >> >>> one. >> >>> >> >>> So, you are making precision measurements by the method you described? >> >>> And you think there is now less variability in note duration, rather >> >>> just >> >>> some consistent bias in all the start and stop times? How big a bias? >> >>> >> >>> What effect on the freezings? (Maybe none, maybe we agree it's >> >>> independent, bug 276) >> >>> >> >>> What effect on the other thing -- that sometimes Midi play did not >> >>> stop >> >>> promptly when playback time reaches the end of selection? >> >>> >> >>> PRL >> >>> >> >>> >> >>>> >> >>>> >> >>>> >> >>>> > >> >>>> > I'm testing that now. >> >>>> > >> >>>> > Steve >> >>>> > >> >>>> >> >> >>>> >> PRL >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >>> >> >>>> >>> >> >>>> >>> > >> >>>> >>> > But does the freeze during play also happen, still? >> >>>> >>> > >> >>>> >>> > PRL >> >>>> >>> > >> >>>> >>> > >> >>>> >>> >> >> >>>> >>> >> >> >>>> >>> >> >> >>>> >>> >> Steve >> >>>> >>> >> >> >>>> >>> >> > >> >>>> >>> >> > PRL >> >>>> >>> >> > >> >>>> >>> >> > >> >>>> >>> >> >> >> >>>> >>> >> >> >> >>>> >>> >> >> > >> >>>> >>> >> >> > PRL >> >>>> >>> >> >> > >> >>>> >>> >> >> > >> >>>> >>> >> >> > On Thu, Aug 10, 2017 at 7:31 PM, Paul Licameli >> >>>> >>> >> >> > <pau...@gm...> >> >>>> >>> >> >> > wrote: >> >>>> >>> >> >> >> >> >>>> >>> >> >> >> Here's another thought: The fix I wrote might "work" >> >>>> >>> >> >> >> but >> >>>> >>> >> >> >> we >> >>>> >>> >> >> >> might >> >>>> >>> >> >> >> fix >> >>>> >>> >> >> >> otherwise without changing lib_src. >> >>>> >>> >> >> >> >> >>>> >>> >> >> >> I think AudioIO::MidiTime() makes unjustified >> >>>> >>> >> >> >> assumptions >> >>>> >>> >> >> >> about >> >>>> >>> >> >> >> the >> >>>> >>> >> >> >> origin >> >>>> >>> >> >> >> of mAudioCallbackOutputTime, which is copied from >> >>>> >>> >> >> >> PaStreamCallbackTimeInfo::outputBufferDacTime. The >> >>>> >>> >> >> >> origin >> >>>> >>> >> >> >> happens >> >>>> >>> >> >> >> to >> >>>> >>> >> >> >> be >> >>>> >>> >> >> >> current time on Mac and Windows. But on Linux, maybe >> >>>> >>> >> >> >> not, >> >>>> >>> >> >> >> and >> >>>> >>> >> >> >> portaudio.h >> >>>> >>> >> >> >> tells you not to assume that: >> >>>> >>> >> >> >> >> >>>> >>> >> >> >> >> >>>> >>> >> >> >> /** >> >>>> >>> >> >> >> Timing information for the buffers passed to the stream >> >>>> >>> >> >> >> callback. >> >>>> >>> >> >> >> >> >>>> >>> >> >> >> Time values are expressed in seconds and are >> >>>> >>> >> >> >> synchronised >> >>>> >>> >> >> >> with >> >>>> >>> >> >> >> the >> >>>> >>> >> >> >> time >> >>>> >>> >> >> >> base used by Pa_GetStreamTime() for the associated >> >>>> >>> >> >> >> stream. >> >>>> >>> >> >> >> >> >>>> >>> >> >> >> @see PaStreamCallback, Pa_GetStreamTime >> >>>> >>> >> >> >> */ >> >>>> >>> >> >> >> typedef struct PaStreamCallbackTimeInfo{ >> >>>> >>> >> >> >> PaTime inputBufferAdcTime; /**< The time when the >> >>>> >>> >> >> >> first >> >>>> >>> >> >> >> sample >> >>>> >>> >> >> >> of >> >>>> >>> >> >> >> the >> >>>> >>> >> >> >> input buffer was captured at the ADC input */ >> >>>> >>> >> >> >> PaTime currentTime; /**< The time when the >> >>>> >>> >> >> >> stream >> >>>> >>> >> >> >> callback >> >>>> >>> >> >> >> was >> >>>> >>> >> >> >> invoked */ >> >>>> >>> >> >> >> PaTime outputBufferDacTime; /**< The time when the >> >>>> >>> >> >> >> first >> >>>> >>> >> >> >> sample >> >>>> >>> >> >> >> of >> >>>> >>> >> >> >> the >> >>>> >>> >> >> >> output buffer will output the DAC */ >> >>>> >>> >> >> >> } PaStreamCallbackTimeInfo; >> >>>> >>> >> >> >> >> >>>> >>> >> >> >> ... >> >>>> >>> >> >> >> >> >>>> >>> >> >> >> /** Returns the current time in seconds for a stream >> >>>> >>> >> >> >> according to >> >>>> >>> >> >> >> the >> >>>> >>> >> >> >> same >> >>>> >>> >> >> >> clock used >> >>>> >>> >> >> >> to generate callback PaStreamCallbackTimeInfo >> >>>> >>> >> >> >> timestamps. >> >>>> >>> >> >> >> The >> >>>> >>> >> >> >> time >> >>>> >>> >> >> >> values >> >>>> >>> >> >> >> are >> >>>> >>> >> >> >> monotonically increasing and have unspecified origin. >> >>>> >>> >> >> >> >> >>>> >>> >> >> >> Pa_GetStreamTime returns valid time values for the >> >>>> >>> >> >> >> entire >> >>>> >>> >> >> >> life >> >>>> >>> >> >> >> of >> >>>> >>> >> >> >> the >> >>>> >>> >> >> >> stream, >> >>>> >>> >> >> >> from when the stream is opened until it is closed. >> >>>> >>> >> >> >> Starting and >> >>>> >>> >> >> >> stopping >> >>>> >>> >> >> >> the stream >> >>>> >>> >> >> >> does not affect the passage of time returned by >> >>>> >>> >> >> >> Pa_GetStreamTime. >> >>>> >>> >> >> >> >> >>>> >>> >> >> >> This time may be used for synchronizing other events to >> >>>> >>> >> >> >> the >> >>>> >>> >> >> >> audio >> >>>> >>> >> >> >> stream, >> >>>> >>> >> >> >> for >> >>>> >>> >> >> >> example synchronizing audio to MIDI. >> >>>> >>> >> >> >> >> >>>> >>> >> >> >> @return The stream's current time in seconds, or 0 if >> >>>> >>> >> >> >> an >> >>>> >>> >> >> >> error >> >>>> >>> >> >> >> occurred. >> >>>> >>> >> >> >> >> >>>> >>> >> >> >> @see PaTime, PaStreamCallback, PaStreamCallbackTimeInfo >> >>>> >>> >> >> >> */ >> >>>> >>> >> >> >> PaTime Pa_GetStreamTime( PaStream *stream ); >> >>>> >>> >> >> >> >> >>>> >>> >> >> >> PRL >> >>>> >>> >> >> >> >> >>>> >>> >> >> >> >> >>>> >>> >> >> >> On Thu, Aug 10, 2017 at 7:02 PM, Paul Licameli >> >>>> >>> >> >> >> <pau...@gm...> >> >>>> >>> >> >> >> wrote: >> >>>> >>> >> >> >>> >> >>>> >>> >> >> >>> I dug in the ALSA documentation for something that >> >>>> >>> >> >> >>> looks >> >>>> >>> >> >> >>> like it >> >>>> >>> >> >> >>> sets >> >>>> >>> >> >> >>> the >> >>>> >>> >> >> >>> origin for timestamps. >> >>>> >>> >> >> >>> >> >>>> >>> >> >> >>> Look at the two functions here, only one of which we >> >>>> >>> >> >> >>> were >> >>>> >>> >> >> >>> calling: >> >>>> >>> >> >> >>> >> >>>> >>> >> >> >>> >> >>>> >>> >> >> >>> >> >>>> >>> >> >> >>> >> >>>> >>> >> >> >>> >> >>>> >>> >> >> >>> http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___s_w___params.html#gac2fba23ba6ac1636785e27f0f5381a15 >> >>>> >>> >> >> >>> >> >>>> >>> >> >> >>> So this may be the magic needed to call the other one: >> >>>> >>> >> >> >>> >> >>>> >>> >> >> >>> >> >>>> >>> >> >> >>> >> >>>> >>> >> >> >>> >> >>>> >>> >> >> >>> >> >>>> >>> >> >> >>> >> >>>> >>> >> >> >>> >> >>>> >>> >> >> >>> https://github.com/Paul-Licameli/audacity/commit/297d9557e9316dde57822a210e38bb569e18860c >> >>>> >>> >> >> >>> >> >>>> >>> >> >> >>> If this is the fix, then we must encourage Linux users >> >>>> >>> >> >> >>> to >> >>>> >>> >> >> >>> build >> >>>> >>> >> >> >>> with >> >>>> >>> >> >> >>> our >> >>>> >>> >> >> >>> modified lib-src, at least for the portaudio library. >> >>>> >>> >> >> >>> >> >>>> >>> >> >> >>> PRL >> >>>> >>> >> >> >>> >> >>>> >>> >> >> >>> >> >>>> >>> >> >> >>> On Thu, Aug 10, 2017 at 5:50 PM, Paul Licameli >> >>>> >>> >> >> >>> <pau...@gm...> >> >>>> >>> >> >> >>> wrote: >> >>>> >>> >> >> >>>> >> >>>> >>> >> >> >>>> >> >>>> >>> >> >> >>>> >> >>>> >>> >> >> >>>> On Thu, Aug 10, 2017 at 5:37 PM, Paul Licameli >> >>>> >>> >> >> >>>> <pau...@gm...> >> >>>> >>> >> >> >>>> wrote: >> >>>> >>> >> >> >>>>> >> >>>> >>> >> >> >>>>> Taking this to the -devel list: >> >>>> >>> >> >> >>>>> >> >>>> >>> >> >> >>>>>> > On Thu, Aug 10, 2017 at 9:43 AM, Steve the Fiddle >> >>>> >>> >> >> >>>>>> > <ste...@gm...> >> >>>> >>> >> >> >>>>>> > wrote: >> >>>> >>> >> >> >>>>>> >> >> >>>> >>> >> >> >>>>>> >> Paul, you appear to have missed several post, >> >>>> >>> >> >> >>>>>> >> including >> >>>> >>> >> >> >>>>>> >> this >> >>>> >>> >> >> >>>>>> >> one: >> >>>> >>> >> >> >>>>>> >> >> >>>> >>> >> >> >>>>>> >> >> >>>> >>> >> >> >>>>>> >> >> >>>> >>> >> >> >>>>>> >> https://sourceforge.net/p/audacity/mailman/message/35988944/ >> >>>> >>> >> >> >>>>>> > >> >>>> >>> >> >> >>>>>> > But Steve, take a look at this one: >> >>>> >>> >> >> >>>>>> > >> >>>> >>> >> >> >>>>>> > >> >>>> >>> >> >> >>>>>> > >> >>>> >>> >> >> >>>>>> > https://sourceforge.net/p/audacity/mailman/message/35989011/ >> >>>> >>> >> >> >>>>>> > I think there's reason to believe AudioTime() is >> >>>> >>> >> >> >>>>>> > returning >> >>>> >>> >> >> >>>>>> > big >> >>>> >>> >> >> >>>>>> > numbers, but >> >>>> >>> >> >> >>>>>> > as explained in 35989011, that should never >> >>>> >>> >> >> >>>>>> > happen. >> >>>> >>> >> >> >>>>>> > So the >> >>>> >>> >> >> >>>>>> > next >> >>>> >>> >> >> >>>>>> > step >> >>>> >>> >> >> >>>>>> > could >> >>>> >>> >> >> >>>>>> > be (temporarily) test to see if AudioTime() is >> >>>> >>> >> >> >>>>>> > ever >> >>>> >>> >> >> >>>>>> > large. >> >>>> >>> >> >> >>>>>> > If >> >>>> >>> >> >> >>>>>> > so, >> >>>> >>> >> >> >>>>>> > I've >> >>>> >>> >> >> >>>>>> > explained why it should not be large, so maybe you >> >>>> >>> >> >> >>>>>> > could >> >>>> >>> >> >> >>>>>> > work >> >>>> >>> >> >> >>>>>> > backwards and >> >>>> >>> >> >> >>>>>> > see what's going wrong. -Roger >> >>>> >>> >> >> >>>>>> >> >>>> >>> >> >> >>>>>> The really big number that I'm seeing is from >> >>>> >>> >> >> >>>>>> PaUtil_GetTime() >> >>>> >>> >> >> >>>>>> >> >>>> >>> >> >> >>>>>> MIDI time is calculated as: >> >>>> >>> >> >> >>>>>> >> >>>> >>> >> >> >>>>>> (1000 * >> >>>> >>> >> >> >>>>>> (AudioTime() + 1.0005 - >> >>>> >>> >> >> >>>>>> mAudioFramesPerBuffer / mRate + >> >>>> >>> >> >> >>>>>> PaUtil_GetTime() - >> >>>> >>> >> >> >>>>>> mAudioCallbackOutputTime)) >> >>>> >>> >> >> >>>>>> >> >>>> >>> >> >> >>>>>> Here's some typical times: >> >>>> >>> >> >> >>>>>> >> >>>> >>> >> >> >>>>>> 21:43:46: Debug: >> >>>> >>> >> >> >>>>>> AudioTime() = 1.27442 >> >>>> >>> >> >> >>>>>> mAudioFramesPerBuffer = 1102 >> >>>> >>> >> >> >>>>>> mRate = 44100.00000 >> >>>> >>> >> >> >>>>>> PaUtil_GetTime() = 1502397826.18170 >> >>>> >>> >> >> >>>>>> mAudioCallbackOutputTime = 42439.61742 >> >>>> >>> >> >> >>>>>> >> >>>> >>> >> >> >>>>>> which according to my calculation is about >> >>>> >>> >> >> >>>>>> 1502355388814 >> >>>> >>> >> >> >>>>> >> >>>> >>> >> >> >>>>> >> >>>> >>> >> >> >>>>> So as I was saying: PaUtil_GetTime is not the >> >>>> >>> >> >> >>>>> suspicious >> >>>> >>> >> >> >>>>> thing >> >>>> >>> >> >> >>>>> to >> >>>> >>> >> >> >>>>> me >> >>>> >>> >> >> >>>>> now. >> >>>> >>> >> >> >>>>> >> >>>> >>> >> >> >>>>> The suspicious thing is that mAudioCallbackOutputTime >> >>>> >>> >> >> >>>>> is >> >>>> >>> >> >> >>>>> not >> >>>> >>> >> >> >>>>> similarly >> >>>> >>> >> >> >>>>> , so that the difference is small. >> >>>> >>> >> >> >>>> >> >>>> >>> >> >> >>>> >> >>>> >>> >> >> >>>> >> >>>> >>> >> >> >>>> mAudioCallbackOutputTime is copied from >> >>>> >>> >> >> >>>> outputBufferDacTime >> >>>> >>> >> >> >>>> >> >>>> >>> >> >> >>>> outputBufferDacTime is updated in just one place in >> >>>> >>> >> >> >>>> pa_linux_alsa.c >> >>>> >>> >> >> >>>> in >> >>>> >>> >> >> >>>> function CalculateTimeInfo: >> >>>> >>> >> >> >>>> >> >>>> >>> >> >> >>>> timeInfo->outputBufferDacTime = >> >>>> >>> >> >> >>>> timeInfo->currentTime + >> >>>> >>> >> >> >>>> (PaTime)playback_delay / >> >>>> >>> >> >> >>>> stream->streamRepresentation.streamInfo.sampleRate; >> >>>> >>> >> >> >>>> >> >>>> >>> >> >> >>>> That looks like a reasonable expression, so is there >> >>>> >>> >> >> >>>> an >> >>>> >>> >> >> >>>> error >> >>>> >>> >> >> >>>> in >> >>>> >>> >> >> >>>> PortAudio's timeInfo->currentTime? I look a little >> >>>> >>> >> >> >>>> bit >> >>>> >>> >> >> >>>> above >> >>>> >>> >> >> >>>> and >> >>>> >>> >> >> >>>> see >> >>>> >>> >> >> >>>> >> >>>> >>> >> >> >>>> alsa_snd_pcm_status( stream->playback.pcm, >> >>>> >>> >> >> >>>> playback_status >> >>>> >>> >> >> >>>> ); >> >>>> >>> >> >> >>>> alsa_snd_pcm_status_get_tstamp( >> >>>> >>> >> >> >>>> playback_status, >> >>>> >>> >> >> >>>> &playback_timestamp ); >> >>>> >>> >> >> >>>> >> >>>> >>> >> >> >>>> playback_time = playback_timestamp.tv_sec + >> >>>> >>> >> >> >>>> ((PaTime)playback_timestamp.tv_usec / >> >>>> >>> >> >> >>>> 1000000.0); >> >>>> >>> >> >> >>>> >> >>>> >>> >> >> >>>> PRL >> >>>> >>> >> >> >>>> >> >>>> >>> >> >> >>>>> >> >>>> >>> >> >> >>>>> PRL >> >>>> >>> >> >> >>>>> >> >>>> >>> >> >> >>>>> >> >>>> >>> >> >> >>>> >> >>>> >>> >> >> >>>> >> >>>> >>> >> >> >>> >> >>>> >>> >> >> >> >> >>>> >>> >> >> > >> >>>> >>> >> >> > >> >>>> >>> >> >> > >> >>>> >>> >> >> > >> >>>> >>> >> >> > >> >>>> >> >>>> >> >>>> >> >>>> ------------------------------------------------------------------------------ |