[Stk] RTAUDIO Float64 vs 32 vs Integer SoundCard

[Gary Worsham]

This is the pattern of things that happen:

a) Running *duplex, *typically I will get a bunch of errors like the
following:

RtApiAlsa::getDeviceInfo: snd_pcm_open error for device (hw:0,0), Device or
resource busy.
RtApiAlsa::getDeviceInfo: snd_pcm_open error for device (hw:1,0), Device or
resource busy.

b) If I then run *audioprobe*, it might show errors for some or all
interfaces similar to above, or it might show them all OK.  If it shows
them all OK, (and the USB interface I am using is now the default device),
then I can run *duplex* without any error messages.

I'm running: *duplex 2 48000*

The sound is either:
i) crunchy/garbled all the time, independent of signal level, or
ii) Sounds clean, except for a slight crackle that comes in every several
seconds.

Left side and right side are coming through to headphones independently and
the artifacts are the same regardless of channel being used.

So the first thing I notice is that RTAudio has a hard time getting
reliably initialized on this system for some reason.  Sometimes I get the
"Device or resource busy" running *audioprobe*, but after running it a few
more times that stops.  But it can come back at any time.

Any hints are of course most welcome!

GW

On Sun, Aug 28, 2016 at 5:16 PM, Gary Worsham <gary.worsham at gmail.com>
wrote:

> Thanks Perry.  My next step is trying to get the "Duplex" (pass thru)
> working.  For comparison, the pure generators sound fine. I agree that
> building up a step at time is probably the only way to go.  And it sure
> gets one's feet wet with the code!
>
> Gary W.
>
> On Sun, Aug 28, 2016 at 9:31 AM, Perry Cook <prc at cs.princeton.edu> wrote:
>
>> Hey Gary,
>>
>> I’m feeling that this is likely not at the root of your audio crunchiness.
>> And I’m pretty certain that hard-wiring INT into format would not work.
>> STK assumes floats in the rough range +/- 1.0 throughout, and only
>> the last layer of the audio interface worries about getting it out to the
>> sound card.  I didn’t check all the RTAudio code but I think that format
>> type might be more wide-reaching than just the last audio hardware
>> layer.
>>
>> Spits and Fizzles on EFX sounds more like buffer/IO problems to me,
>> unless it’s purely signal (level) dependent, and in that case it sounds
>> more like clipping.  Starting with EFX, which has I/O and signal
>> processing, has too many potential areas for problems to happen
>> to be sure where things might be going wrong.  Maybe try a simpler
>> demo yet (in the examples folder), like the single sine oscillator, or
>> playsimp on a really simple (sine wave ideally) .wav file.  Play with
>> the gain a bit (from within the code) and see if clipping or other
>> interruption occurs.  If you can get it to make a pure sine wave in
>> real time that sounds like a pure sine wave (or play any sound file
>> without distortion/clipping), then the FORMAT/32/64 is likely not the
>> problem.
>>
>> Others please chime in if you have experience in this area.
>>
>> PRC
>>
>> > On Aug 27, 2016, at 5:51 PM, Gary Worsham <gary.worsham at gmail.com>
>> wrote:
>> >
>> > I understand I'm still messing around at the RtAudio stage, but I
>> promise to ask some stk questions just as soon as I get this other stuff
>> out of the way.
>> >
>> > I accomplished 2 different things.
>> >
>> > #1 I figured out how to determine the index of the USB interface and
>> use this instead of "default" when picking the audio interface to use.
>> >
>> > #2 I figured out how to get the USB interface down to the default
>> position.  At least, let's say I changed some things and it's there but I
>> couldn't actually explain it.  So now this interface is used by default
>> with the stk example programs.  Yay!
>> >
>> > Next issue is that for example, I am running "effects" via StkEffects.
>> The sound is very crunchy - not overdriven, but spits and fizzles with any
>> signal at all.  I noticed in the effects.cpp:
>> >
>> > effects.cpp:  RtAudioFormat format = ( sizeof(StkFloat) == 8 ) ?
>> RTAUDIO_FLOAT64 : RTAUDIO_FLOAT32;
>> >
>> > So we are choosing float 64 or float 32 format based on a runtime
>> decision... however this particular interface only supports 32 bit int.
>> Seems like this code assumes support for 32 or 64 bit float.
>> >
>> > Should I just hard-wire RTAUDIO_SINT32 in here to get started, or do I
>> have to change the code itself to accommodate this?
>> >
>> > Thanks,
>> >
>> > Gary W.
>> > _______________________________________________
>> > 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/20160904/0b20e79c/attachment.html>