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-18 21:17:35
|
On 18 August 2017 at 21:55, Roger Dannenberg <rb...@cs...> wrote: > > > On 8/18/17 9:55 AM, Paul Licameli wrote: > > > > On Fri, Aug 18, 2017 at 9:04 AM, Roger Dannenberg <rb...@cs...> wrote: >> >> I got Audacity to compile on Linux. Instructions worked great. In trying >> to prepare some test files with Nyquist, I discovered Nyquist's midi file >> write code does not work on this 64-bit Linux build, and also a family >> wedding and the solar eclipse have me pretty booked up, but I'm making >> progress and want to look closely at the timing issues. I think it's complex >> enough that just observing behavior is not a good substitute for digging in >> and seeing what's going on in more detail. -Roger > > > Best wishes to bride and groom. > > This digging might take some time. As Release Manager for 2.2.0, though, I > want to declare Midi playback on Linux good enough for a beta release, and > hope that any further timing fixes will be ready within two or three weeks. > If not then, then next version. Has anyone tested timing precision on Windows / Mac yet? So long as nothing unexpected and bad happens, I agree that MIDI playback on Linux is good enough for a beta, but unless improved by the time we get to 2.2.0 release I think we would need to release note the poor timing. Audacity users should expect high quality from Audacity. Steve > > OK -- I'll see what I can do! > > > PRL > >> >> >> On 8/17/17 11:32 PM, Paul Licameli wrote: >> >> At commit 1f043247a75997494f4750ef2b06f11fb300b2ea in my fork, I try >> elevation of the priority of the Midi thread, on Linux only. >> >> Does this do anything to improve synchronization of Midi play on Linux? >> >> PRL >> >> >> On Thu, Aug 17, 2017 at 11:28 PM, Paul Licameli <pau...@gm...> >> wrote: >>> >>> Because Stever reported the change at >>> 5b4531bd09a998beb5bec30025d6b56e95ee94f9 as "encouraging," I have rebased it >>> and pushed it to master, as commit 47eaf526a66f55c223184a1b301049e973a7a25c. >>> >>> PRL >>> >>> >>> >>> On Tue, Aug 15, 2017 at 1:46 PM, Roger Dannenberg <rb...@cs...> wrote: >>>> >>>> >>>> >>>> On 8/15/17 1:04 PM, Paul Licameli wrote: >>>> >>>> >>>> >>>> On Tue, Aug 15, 2017 at 12:52 PM, Roger Dannenberg <rb...@cs...> >>>> wrote: >>>>> >>>>> >>>>> On 8/15/17 12:00 PM, Paul Licameli wrote: >>>>> >>>>> >>>>> >>>>> On Tue, Aug 15, 2017 at 11:14 AM, 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? >>>>>> >>>>>> 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. >>>> >>>> >>>> Is there any chance Alsa did it right but the PortMidi developers didn't >>>> find the right things to call, as the comment would suggest? >>>> >>>> Possible, although most of the ALSA code in PortMidi was developed in >>>> consultation with an ALSA developer. I can try to check with "ALSA people" >>>> to confirm there's no better way. >>>> >>>> >>>> Suppose we elevate the priority of our thread that sends the Midi >>>> messages. Could that reduce the variability in synchronizing to audio >>>> output? Would that only invite other bad consequences if that thread blocks >>>> on a filled queue? >>>> >>>> I'm not sure. Priority should help, but if there are locks, I'd be very >>>> worried about priority inversion issues, and in any case I think audio is >>>> going to get very high priority from PortAudio and might have some pretty >>>> long run times if you are mixing and resampling a bunch of tracks, so that >>>> could still be the limiting factor. >>>> >>>> >>>> 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 >>>>>>> >>>> >>> >> >> >>>>> >>>>>>> >>>> >>> >> >> >>>>> >>>>>>> >>>> >>> >> >> >>>> >>>>>>> >>>> >>> >> >> >>>> >>>>>>> >>>> >>> >> >> >>> >>>>>>> >>>> >>> >> >> >> >>>>>>> >>>> >>> >> >> > >>>>>>> >>>> >>> >> >> > >>>>>>> >>>> >>> >> >> > >>>>>>> >>>> >>> >> >> > >>>>>>> >>>> >>> >> >> > >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> ------------------------------------------------------------------------------ >>>>>>> >>>> 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 >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> ------------------------------------------------------------------------------ >>>>>>> >>> 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 >>>>>>> >>> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> ------------------------------------------------------------------------------ >>>>>>> >> 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 >>>>>>> >> >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > ------------------------------------------------------------------------------ >>>>>>> > 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 >>>>>>> > >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> 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 >>>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> 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 >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> 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 >>>> >>> >> >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> > > > > ------------------------------------------------------------------------------ > 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 > > > > ------------------------------------------------------------------------------ > 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 > |