[Stk] Fwd: Seg fault in "duplex"

Gary Worsham gary.worsham at gmail.com
Mon Sep 5 12:09:03 PDT 2016


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/me
> mcpy-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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/stk/attachments/20160905/7752d33b/attachment.html>


More information about the Stk mailing list