<div dir="ltr"><div><div><div><div><div><div>This is the pattern of things that happen:<br><br></div>a) Running <b>duplex, </b>typically I will get a bunch of errors like the following:<br><br>RtApiAlsa::getDeviceInfo: snd_pcm_open error for device (hw:0,0), Device or resource busy.<br>RtApiAlsa::getDeviceInfo: snd_pcm_open error for device (hw:1,0), Device or resource busy.<br><br></div>b) If I then run <b>audioprobe</b>, 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 <b>duplex</b> without any error messages.<br><br></div><div>I'm running: <b>duplex 2 48000</b><br></div><div><br></div>The sound is either:<br></div>i) crunchy/garbled all the time, independent of signal level, or<br></div>ii) Sounds clean, except for a slight crackle that comes in every several seconds.<br><br></div><div>Left side and right side are coming through to headphones independently and the artifacts are the same regardless of channel being used.<br></div><div><br></div>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 <b>audioprobe</b>, but after running it a few more times that stops. But it can come back at any time.<br><div><div><div><div><div><div><br></div><div>Any hints are of course most welcome!<br><br></div><div>GW<br></div><div><b></b></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 28, 2016 at 5:16 PM, Gary Worsham <span dir="ltr"><<a href="mailto:gary.worsham@gmail.com" target="_blank">gary.worsham@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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!<br><br></div>Gary W.<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 28, 2016 at 9:31 AM, Perry Cook <span dir="ltr"><<a href="mailto:prc@cs.princeton.edu" target="_blank">prc@cs.princeton.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Gary,<br>
<br>
I’m feeling that this is likely not at the root of your audio crunchiness.<br>
And I’m pretty certain that hard-wiring INT into format would not work.<br>
STK assumes floats in the rough range +/- 1.0 throughout, and only<br>
the last layer of the audio interface worries about getting it out to the<br>
sound card. I didn’t check all the RTAudio code but I think that format<br>
type might be more wide-reaching than just the last audio hardware<br>
layer.<br>
<br>
Spits and Fizzles on EFX sounds more like buffer/IO problems to me,<br>
unless it’s purely signal (level) dependent, and in that case it sounds<br>
more like clipping. Starting with EFX, which has I/O and signal<br>
processing, has too many potential areas for problems to happen<br>
to be sure where things might be going wrong. Maybe try a simpler<br>
demo yet (in the examples folder), like the single sine oscillator, or<br>
playsimp on a really simple (sine wave ideally) .wav file. Play with<br>
the gain a bit (from within the code) and see if clipping or other<br>
interruption occurs. If you can get it to make a pure sine wave in<br>
real time that sounds like a pure sine wave (or play any sound file<br>
without distortion/clipping), then the FORMAT/32/64 is likely not the<br>
problem.<br>
<br>
Others please chime in if you have experience in this area.<br>
<br>
PRC<br>
<br>
> On Aug 27, 2016, at 5:51 PM, Gary Worsham <<a href="mailto:gary.worsham@gmail.com" target="_blank">gary.worsham@gmail.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> I accomplished 2 different things.<br>
><br>
> #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.<br>
><br>
> #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!<br>
><br>
> 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:<br>
><br>
> effects.cpp: RtAudioFormat format = ( sizeof(StkFloat) == 8 ) ? RTAUDIO_FLOAT64 : RTAUDIO_FLOAT32;<br>
><br>
> 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.<br>
><br>
> Should I just hard-wire RTAUDIO_SINT32 in here to get started, or do I have to change the code itself to accommodate this?<br>
><br>
> Thanks,<br>
><br>
> Gary W.<br>
> ______________________________<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>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>