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: Roger D. <rb...@cs...> - 2017-08-15 16:52:17
|
On 8/15/17 12:00 PM, Paul Licameli wrote: > > > On Tue, Aug 15, 2017 at 11:14 AM, Paul Licameli > <pau...@gm... <mailto:pau...@gm...>> wrote: > > > > On Tue, Aug 15, 2017 at 8:42 AM, Steve the Fiddle > <ste...@gm... <mailto:ste...@gm...>> wrote: > > On 14 August 2017 at 20:00, Paul Licameli > <pau...@gm... <mailto:pau...@gm...>> wrote: > > > > > > On Mon, Aug 14, 2017 at 2:46 PM, Pokechu22 > > <pok...@gm... > <mailto:pokechu022%2Bs...@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 > <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 > <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 > <https://github.com/Paul-Licameli/audacity/commit/5b4531bd09a998beb5bec30025d6b56e95ee94f9> > Have I just wasted 4 hours? > > In brief, > https://github.com/Paul-Licameli/audacity/commit/5b4531bd09a998beb5bec30025d6b56e95ee94f9 > <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? > > 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 > > > I discovered this today: maybe Roger can say more about it. > > First, read the function midi_synchronize in pmmacosxcm.c and see how > it guarantees 0.5 ms accuracy. > > Then see the function winmm_synchronize doing an analogous thing. > > These two functions really correspond, because you can see how the > common parts of portmidi use a table of function pointers to > platform-specific procedures, and they fill the same slot of that table. > > Then see the corresponding function alsa_synchronize and comments in > it. It suggests we are encountering an inherent defect either of alsa > or of portmidi. > > static PmTimestamp alsa_synchronize(PmInternal *midi) > { > return 0; /* linux implementation does not use this synchronize > function */ > /* Apparently, Alsa data is relative to the time you send it, and > there > is no reference. If this is true, this is a serious shortcoming of > Alsa. If not true, then PortMidi has a serious shortcoming -- it > should be scheduling relative to Alsa's time reference. */ > } Hi, I'm back from a 3-day visit to see my parents. I've been trying to follow recent developments, tests, speculation, etc., but it's pretty confusing. What I'd really like to see is an end-to-end argument about how we synchronize MIDI to Audio. There are a lot of steps and translations from audio driver timing to MIDI driver timing, and probably many hacks and patches that would give roughly OK observable behavior without actually being correct. I talked to Steve about the best way to compile Audacity and recreate the sources and tests he's using, and I'll get started, but no promises on what I can do since classes are starting soon. Anyway, everything above sounds correct, and I pointed this comment out last week (I think). I had forgotten until I saw this again, but it really does look like the ALSA design missed the boat on accurate timing because if timestamps are relative, timing accuracy is limited to the real-time scheduling accuracy of the sending process, which is probably competing with other processes in hard-to-predict ways, whereas with absolute timestamps, timing accuracy is limited to the real-time scheduling of the device driver, which is normally tied to hardware interrupts, preempts all user processes, and has very low latency. Nevertheless, we can and should still carefully compute timestamps to synchronize to audio (which is delayed in output buffers and subject to quite a lot of jitter, sometimes falling behind while waiting for disk and CPU, and sometimes catching up and blocking on a full output buffer), especially since audio is buffered so far ahead of output time, making proper delays important for MIDI timing. > > > > > > > > > > > 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... <mailto:pau...@gm...>> > >> wrote: > >>> > >>> > >>> > >>> On Mon, Aug 14, 2017 at 1:17 PM, Steve the Fiddle > >>> <ste...@gm... > <mailto:ste...@gm...>> wrote: > >>>> > >>>> On 14 August 2017 at 12:30, Steve the Fiddle > <ste...@gm... <mailto:ste...@gm...>> > >>>> wrote: > >>>> > On 14 August 2017 at 12:12, Paul Licameli > <pau...@gm... <mailto:pau...@gm...>> > >>>> > wrote: > >>>> >> > >>>> >> > >>>> >> On Mon, Aug 14, 2017 at 6:59 AM, Steve the Fiddle > >>>> >> <ste...@gm... > <mailto:ste...@gm...>> > >>>> >> wrote: > >>>> >>> > >>>> >>> On 14 August 2017 at 11:27, Paul Licameli > <pau...@gm... <mailto:pau...@gm...>> > >>>> >>> wrote: > >>>> >>> > > >>>> >>> > > >>>> >>> > On Mon, Aug 14, 2017 at 4:50 AM, Steve the Fiddle > >>>> >>> > <ste...@gm... > <mailto:ste...@gm...>> > >>>> >>> > wrote: > >>>> >>> >> > >>>> >>> >> On 14 August 2017 at 03:42, Paul Licameli > >>>> >>> >> <pau...@gm... > <mailto:pau...@gm...>> > >>>> >>> >> wrote: > >>>> >>> >> > > >>>> >>> >> > > >>>> >>> >> > On Sun, Aug 13, 2017 at 3:01 PM, Steve the Fiddle > >>>> >>> >> > <ste...@gm... > <mailto:ste...@gm...>> > >>>> >>> >> > wrote: > >>>> >>> >> >> > >>>> >>> >> >> On 11 August 2017 at 00:52, Paul Licameli > >>>> >>> >> >> <pau...@gm... > <mailto: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 > <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 > <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 > <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... > <mailto: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... > <mailto: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 > <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 > <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... > <mailto:pau...@gm...>> > >>>> >>> >> >> >>> wrote: > >>>> >>> >> >> >>>> > >>>> >>> >> >> >>>> > >>>> >>> >> >> >>>> > >>>> >>> >> >> >>>> On Thu, Aug 10, 2017 at 5:37 PM, Paul Licameli > >>>> >>> >> >> >>>> <pau...@gm... > <mailto:pau...@gm...>> > >>>> >>> >> >> >>>> wrote: > >>>> >>> >> >> >>>>> > >>>> >>> >> >> >>>>> Taking this to the -devel list: > >>>> >>> >> >> >>>>> > >>>> >>> >> >> >>>>>> > On Thu, Aug 10, 2017 at 9:43 AM, Steve > the Fiddle > >>>> >>> >> >> >>>>>> > <ste...@gm... > <mailto:ste...@gm...>> > >>>> >>> >> >> >>>>>> > wrote: > >>>> >>> >> >> >>>>>> >> > >>>> >>> >> >> >>>>>> >> Paul, you appear to have missed > several post, > >>>> >>> >> >> >>>>>> >> including > >>>> >>> >> >> >>>>>> >> this > >>>> >>> >> >> >>>>>> >> one: > >>>> >>> >> >> >>>>>> >> > >>>> >>> >> >> >>>>>> >> > >>>> >>> >> >> >>>>>> >> > https://sourceforge.net/p/audacity/mailman/message/35988944/ > <https://sourceforge.net/p/audacity/mailman/message/35988944/> > >>>> >>> >> >> >>>>>> > > >>>> >>> >> >> >>>>>> > But Steve, take a look at this one: > >>>> >>> >> >> >>>>>> > > >>>> >>> >> >> >>>>>> > > >>>> >>> >> >> >>>>>> > > https://sourceforge.net/p/audacity/mailman/message/35989011/ > <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 > >>>> >>> >> >> >>>>> > >>>> >>> >> >> >>>>> > >>>> >>> >> >> >>>> > >>>> >>> >> >> >>>> > >>>> >>> >> >> >>> > >>>> >>> >> >> >> > >>>> >>> >> >> > > >>>> >>> >> >> > > >>>> >>> >> >> > > >>>> >>> >> >> > > >>>> >>> >> >> > > >>>> > >>>> > >>>> > ------------------------------------------------------------------------------ > >>>> Check out the vibrant tech community on one of the > world's most > >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >>>> _______________________________________________ > >>>> audacity-devel mailing list > >>>> aud...@li... > <mailto:aud...@li...> > >>>> > https://lists.sourceforge.net/lists/listinfo/audacity-devel > <https://lists.sourceforge.net/lists/listinfo/audacity-devel> > >>> > >>> > >>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> Check out the vibrant tech community on one of the world's > most > >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >>> _______________________________________________ > >>> audacity-devel mailing list > >>> aud...@li... > <mailto:aud...@li...> > >>> > https://lists.sourceforge.net/lists/listinfo/audacity-devel > <https://lists.sourceforge.net/lists/listinfo/audacity-devel> > >>> > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> Check out the vibrant tech community on one of the world's most > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >> _______________________________________________ > >> audacity-devel mailing list > >> aud...@li... > <mailto:aud...@li...> > >> https://lists.sourceforge.net/lists/listinfo/audacity-devel > <https://lists.sourceforge.net/lists/listinfo/audacity-devel> > >> > > > > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > audacity-devel mailing list > > aud...@li... > <mailto:aud...@li...> > > https://lists.sourceforge.net/lists/listinfo/audacity-devel > <https://lists.sourceforge.net/lists/listinfo/audacity-devel> > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > audacity-devel mailing list > aud...@li... > <mailto:aud...@li...> > https://lists.sourceforge.net/lists/listinfo/audacity-devel > <https://lists.sourceforge.net/lists/listinfo/audacity-devel> > > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |