<div dir="ltr"><div class="gmail_quote"><div dir="ltr">Hi Gary,<div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>duplex will either pass data cleanly (10% of the time), or with level-independent crackles (90%).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div><br></div><div>GSW</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 5, 2016 at 9:51 AM, Gary Scavone <span dir="ltr"><<a href="mailto:gary@ccrma.stanford.edu" target="_blank">gary@ccrma.stanford.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Gary,<br>
<br>
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.<br>
<br>
Regards,<br>
<br>
—gary<br>
<div><div><br>
> On Sep 5, 2016, at 12:05 PM, Gary Worsham <<a href="mailto:gary.worsham@gmail.com" target="_blank">gary.worsham@gmail.com</a>> wrote:<br>
><br>
> I'm running stk under 64-bit Ubuntu 14.04 on an AMD CPU. Audio interface is Focusrite Scarlett 2i2.<br>
><br>
> 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.<br>
><br>
> This seg fault happens on the first call to inout in duplex.cpp:<br>
><br>
> Running ... press <enter> to quit (buffer frames = 512).<br>
> [Switching to Thread 0x7fffeffc5700 (LWP 31167)]<br>
><br>
> Breakpoint 1, inout (outputBuffer=0x63cee0, inputBuffer=0x63eef0, nBufferFrames=512, streamTime=0, status=0,<br>
> data=0x7fffffffdda0) at duplex.cpp:53<br>
> 53 {<br>
> (gdb) n<br>
> 56 if ( status ) std::cout << "Stream over/underflow detected." << std::endl;<br>
> (gdb) n<br>
> 59 memcpy( outputBuffer, inputBuffer, *bytes );<br>
> (gdb) n<br>
><br>
> Program received signal SIGSEGV, Segmentation fault.<br>
> __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/me<wbr>mcpy-sse2-unaligned.S:36<br>
> 36 ../sysdeps/x86_64/multiarch/me<wbr>mcpy-sse2-unaligned.S: No such file or directory.<br>
> ====================<br>
><br>
> I'm looking into things like explicit alignment for the buffer. Any clues as to what is going on here welcomed!<br>
><br>
> Thx,<br>
><br>
> GSW<br>
</div></div>> ______________________________<wbr>_________________<br>
> Stk mailing list<br>
> <a href="mailto:Stk@ccrma.stanford.edu" target="_blank">Stk@ccrma.stanford.edu</a><br>
> <a href="https://cm-mail.stanford.edu/mailman/listinfo/stk" rel="noreferrer" target="_blank">https://cm-mail.stanford.edu/m<wbr>ailman/listinfo/stk</a><br>
<br>
<br>
</blockquote></div><br></div>
</div></div></div><br></div>