[Stk] Seg fault in "duplex"

[Gary Worsham]

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/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/2488221d/attachment.html>