[Stk] Seg fault in "duplex"
Gary Worsham
gary.worsham at gmail.com
Tue Sep 6 12:22:36 PDT 2016
OK I did some more testing, and even with the assignment of bufferBytes
moved prior to openStream(), I get about 10-20% nice clear sound and the
rest are jumbly/crackly/garbled sound. I see what you mean, until the
stream starts, it is not trying to use the value. The openStream() is just
telling the system where the # of bytes value is for later use.
Since I have a MacBook Pro sitting around doing nothing I think I will
start checking this same thing in different dimensions, such as trying the
built in Linux PC sound device (motherboard chip) vs. the Focusrite USB,
and also built-in vs. USB on the Mac.
I don't have any specific reason to favor Linux over the Mac other than I'm
more used to it.
Thanks,
GSW
On Tue, Sep 6, 2016 at 8:56 AM, Gary Scavone <gary at ccrma.stanford.edu>
wrote:
> Actually, it is very strange that that was a problem because the callback
> function shouldn’t start running until after the “startStream()” function
> is called. Maybe there is a bug in the ALSA implementation of RtAudio.
>
> —gary
>
> On Sep 6, 2016, at 11:25 AM, Gary Scavone <gary at ccrma.stanford.edu> wrote:
>
> > Hi Gary,
> >
> > Thanks for the debugging! The position of that statement did catch my
> eye yesterday and I was thinking it could be a problem if the callback
> function gets invoked _before_ the “bufferBytes” value is assigned. Sorry
> about that.
> >
> > Regards,
> >
> > —gary
> >
> > On Sep 6, 2016, at 12:42 AM, Gary Worsham <gary.worsham at gmail.com>
> wrote:
> >
> >> Never mind the rest of my confused comments. I understand that the
> tick() function, or inout() as it's called in duplex, is not sent buffer
> pointers directly by any code in the program. openStream() references the
> tick() function which then receives the buffer pointers from the stream
> management functions.
> >>
> >> By moving the assignment of bufferBytes to BEFORE its use in
> openStream(), I now have lovely clear sound coming through. So that would
> be a bug in duplex.cpp.
> >>
> >> bufferBytes = bufferFrames * channels * sizeof( MY_TYPE );
> >>
> >> try {
> >> adac.openStream( &oParams, &iParams, FORMAT, fs, &bufferFrames,
> &inout, (void *)&bufferBytes, &options );
> >> }
> >> catch ( RtAudioError& e ) {
> >> std::cout << '\n' << e.getMessage() << '\n' << std::endl;
> >> exit( 1 );
> >> }
> >>
> >> Cheers,
> >>
> >> GSW
> >>
> >> On Mon, Sep 5, 2016 at 12:32 PM, Gary Worsham <gary.worsham at gmail.com>
> wrote:
> >> Here's a section of duplex.cpp that I find a little baffling.
> >>
> >> try {
> >> adac.openStream( &oParams, &iParams, FORMAT, fs, &bufferFrames,
> &inout, (void *)&bufferBytes, &options );
> >> }
> >> catch ( RtAudioError& e ) {
> >> std::cout << '\n' << e.getMessage() << '\n' << std::endl;
> >> exit( 1 );
> >> }
> >>
> >> bufferBytes = bufferFrames * channels * sizeof( MY_TYPE );
> >>
> >> bufferBytes is an int, and the pointer to this is used in the
> openStream call before bufferBytes is initialized. I thought that
> &bufferBytes was supposed to be a pointer to an actual data buffer. In
> other examples (in the effects folder), this parameter is a pointer to a
> TickData struct. Clearly I'm not wrapping my head around where the actual
> data buffer being used in duplex comes from.
> >>
> >> GSW
> >>
> >> On Mon, Sep 5, 2016 at 12:09 PM, Gary Worsham <gary.worsham at gmail.com>
> wrote:
> >> Hi Gary,
> >>
> >> Yes I'm starting with duplex.cpp and trying to get it to simply pass
> data reliably from input to output. The changes I am making currently are
> simply to output more of the DeviceInfo details on the audio interface so I
> can try to debug it.
> >>
> >> If I run the stock duplex executable, I often get errors from RtAudio
> that the device is busy. If I run audioprobe, I might get the same info
> reported about 1 or more interfaces but like as not, after a few runs of
> audioprobe, all interfaces report back. Then I can run duplex
> (unmodified). So that's problem #1, getting the audio driver into a stable
> state (or something like that).
> >>
> >> I have not received any seg faults from the unmodified duplex
> executable. But the minute I added the line that simply iterates through
> the discovered audio APIs and prints them to the screen using cout, I
> started getting the seg fault. Take that line out, no seg fault. Put it
> back in, seg fault returns. That is problem #2.
> >>
> >> duplex will either pass data cleanly (10% of the time), or with
> level-independent crackles (90%).
> >>
> >> I modified duplex.cpp with some code from audioprobe (which prints out
> the DeviceInfo stuff). The idea was to see whether the behavior was in any
> way related to what the RtAudio functions think about the state of the
> audio hw. I subsequently started getting seg faults even though I would
> not have expected anything like that based on my changes. I traced the seg
> faults using gdb to the memcpy call in the inout() function. Of course I'm
> not entirely sure that debugging this way is Ok.
> >>
> >> This Focusrite Scarlett 2i2 USB is reported as being pretty stable and
> supported for Linux, and I have had no issues with it using Audacity or
> Ardour. I might try recompiling everything for Jack, as I have used that
> on this machine as well. My thought process was that ALSA would be simpler
> than Jack with fewer layers of things involved, so I'm a bit reluctant to
> head in this direction.
> >>
> >> Thanks,
> >>
> >> GSW
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Sep 5, 2016 at 9:51 AM, Gary Scavone <gary at ccrma.stanford.edu>
> wrote:
> >> Hi Gary,
> >>
> >> Have you tried the “duplex.cpp” example in the "stk/projects/examples/“
> folder? That would at least verify whether things are working with your
> hardware, before dealing with possible programming errors. If that works,
> then you could use that as a starting point from which to make changes for
> your specific needs.
> >>
> >> Regards,
> >>
> >> —gary
> >>
> >>> On Sep 5, 2016, at 12:05 PM, Gary Worsham <gary.worsham at gmail.com>
> wrote:
> >>>
> >>> I'm running stk under 64-bit Ubuntu 14.04 on an AMD CPU. Audio
> interface is Focusrite Scarlett 2i2.
> >>>
> >>> I've started making some mods to the duplex.cpp to try to work my way
> up to clean audio. My previous post/thread notes several variations of
> behavior when I use duplex and audioprobe.
> >>>
> >>> This seg fault happens on the first call to inout in duplex.cpp:
> >>>
> >>> Running ... press <enter> to quit (buffer frames = 512).
> >>> [Switching to Thread 0x7fffeffc5700 (LWP 31167)]
> >>>
> >>> Breakpoint 1, inout (outputBuffer=0x63cee0, inputBuffer=0x63eef0,
> nBufferFrames=512, streamTime=0, status=0,
> >>> data=0x7fffffffdda0) at duplex.cpp:53
> >>> 53 {
> >>> (gdb) n
> >>> 56 if ( status ) std::cout << "Stream over/underflow detected."
> << std::endl;
> >>> (gdb) n
> >>> 59 memcpy( outputBuffer, inputBuffer, *bytes );
> >>> (gdb) n
> >>>
> >>> Program received signal SIGSEGV, Segmentation fault.
> >>> __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/
> memcpy-sse2-unaligned.S:36
> >>> 36 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such
> file or directory.
> >>> ====================
> >>>
> >>> I'm looking into things like explicit alignment for the buffer. Any
> clues as to what is going on here welcomed!
> >>>
> >>> Thx,
> >>>
> >>> GSW
> >>> _______________________________________________
> >>> Stk mailing list
> >>> Stk at ccrma.stanford.edu
> >>> https://cm-mail.stanford.edu/mailman/listinfo/stk
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Stk mailing list
> >> Stk at ccrma.stanford.edu
> >> https://cm-mail.stanford.edu/mailman/listinfo/stk
> >
> >
> > _______________________________________________
> > Stk mailing list
> > Stk at ccrma.stanford.edu
> > https://cm-mail.stanford.edu/mailman/listinfo/stk
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/stk/attachments/20160906/711fec97/attachment.html>
More information about the Stk
mailing list