Re: [Audacity-devel] [Audacity-Team] Problems of Midi playback wtih ALSA

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

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?

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
>

Re: [Audacity-devel] [Audacity-Team] Problems of Midi playback wtih ALSA

A free multi-track audio editor and recorder

Re: [Audacity-devel] [Audacity-Team] Problems of Midi playback wtih ALSA