0

This is my first post on Stackoverflow, I hope I'm doing this right.

I'm new to C++.

I've been playing with RtAudio and Qt (on linux, desktop and raspberry pi).

Backend is ALSA.

Audio out went fine both on my desktop computer (RME Fireface UCX in ClassCompilant mode and on the Raspberry Pi 3 with HifiBerry and PiSound)

Lately, I tried to add audio input support to my program. I read the duplex tutorial on RtAudio website, and tried to implement it inside my code.

As soon as I added the input StreamParameters to openStream I got a very cracky sound. Although, StreamStatus is ok in the callback...

I tried to create an empty C++ project, and simply copy the RtAudio tutorial. Sadly, the problem remains...

I added this to my project file in Qt Creator

LIBS += -lpthread -lasound

I think my issue is similar to this one, but I couldn't find how (or if) it was solved

I tried different buffer sizes (from 64 to 4096 and more), the cracks are less audible, but still present when buffer size increases

Do you know anything that should be done regarding RtAudio in duplex mode that might solve this ? It seems that buffer size is not the same when in duplex mode.

edit :

Out of curiosity (and despair), I tried even lower buffer sizes with the canonical example from RtAudio help : it turns out using buffer size 1, 2, 4 and 8 frames removes the cracks...

As soon as I use 16 frames, sound is awful

Even 15 frames works, I really don't get what's going on

Code Sample : 

RtAudio::StreamOptions options;
options.flags |= RTAUDIO_SCHEDULE_REALTIME;

RtAudio::StreamParameters params_in, params_out;
params_in.deviceId = 3;
params_in.nChannels = 2;
params_out.deviceId = 3;
params_out.nChannels = 2;

When output only, it works :

try {
    audio.openStream(
        &params_out,
        NULL,
        RTAUDIO_SINT16,
        48000,
        &buffer_frames,
        &inout,
        (void *) &buffer_bytes,
        &options
    );
}
catch (RtAudioError& e) {
    std::cout << "Error while opening stream" << std::endl;
    e.printMessage();
    exit(0);
}

Cracks appear when changing NULL to &params_in :

try {
    audio.openStream(
        &params_out,
        &params_in,
        RTAUDIO_SINT16,
        48000,
        &buffer_frames,
        &inout,
        (void *) &buffer_bytes,
        &options
    );
}
catch (RtAudioError& e) {
    std::cout << "Error while opening stream" << std::endl;
    e.printMessage();
    exit(0);
}

Thank you for your help

MrFrangipane
  • 11
  • 2
  • 1
    Sounds like your backend cannot support such a small buffer. What backend are you using? – dtech Nov 07 '18 at 14:20
  • Thanks for your comment. Backend is ALSA, I tried buffers from 64 to 16384 : cracks are less present when buffer increases, but never disappears. Output only works well with 64 buffers. – MrFrangipane Nov 07 '18 at 15:02
  • Maybe try jack audio? Or building a "RT kernel" for audio. – dtech Nov 07 '18 at 15:29
  • I was on the way to try JACK, the kernel is RT on the raspberry pi from [Blokas Pisound](https://github.com/BlokasLabs/rpi-kernel-rt). I'll try JACK, thanks ! – MrFrangipane Nov 07 '18 at 16:38
  • Keep in mind the PI is kind of under-powered and probably its audio chip might be as well. It may be an interface bandwidth issue, if the problem arises from trying to do full duplex audio... it may well be something that doesn't have enough juice to achieve full duplex. – dtech Nov 07 '18 at 16:57
  • This happens on my desktop computer as well as the Pi. Plus, the Pi soundcard is PiSound, not the included audio chip. People have achived low latency (kind of) with that setup, [an example here](https://www.youtube.com/watch?v=t6P5qDFKlhI). – MrFrangipane Nov 07 '18 at 17:56

1 Answers1

0

Answering my own question.

I re did my tests from scratch on the Raspberry Pi 3 / PiSound.

It turns out I must have done something wrong the first time. The canonical example from RtAudio (and the input implementation I did for my program) work well at 64, 128, etc buffer sizes.

The desktop build still have cracky sound, but works with weird buffer sizes (like 25, 30 or 27). The problem most likely comes from the Fireface UCX which is not well supported on Linux (even in ClassCompilant mode).

Thank you for your help, and sorry if I wasted your time.

MrFrangipane
  • 11
  • 2