[Stk] Seg fault in "duplex"
Gary Scavone
gary at ccrma.Stanford.EDU
Tue Sep 6 08:56:14 PDT 2016
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
>
More information about the Stk
mailing list