If you are using CsoundGUI, Iain's suggestion makes a lot of sense, and 
could explain unusual MIDI and audio behavior.

CsOptions interact with: .csoundrc, Csound defaults, and environment 
variables - as well as what happens to be in your work folder. It has gotten 
so confusing for me that I have resorted to putting all the files I need 
into a single folder and working from there.

Including MIDI and audio drivers there are only about 10 Csound files I 
actually use; I put them in a single folder, then add my .csd(s) and 
whatever front-end I may be using, click through to that folder and run. 
Prior to then, I get rid of my .csoundrc and environment variables, and put 
all my necessary commandline options in .

This keeps me saner (not sane - just saner). I don't know how many times 
I've gone through what you're experiencing - and let everyone know of it as 
well (especially the "user-unfriendliness" bit).

One other random idea: some music programs (MIDIOX is one) grab MIDI and 
perhaps audio devices and lock them up so that other programs can't use or 
see them.

Finally, I'm not sure what I'd expect if I omitted -b and -B from my 
. (At one time, the PC system defaults for these were *not* 
realtime friendly!) The requirements here for realtime vs. delayed playback 
are quite different, and very system dependent. (SR, KR and textural 
complexity also are major factors.) I generally find settings that work with 
my systems and reuse them over and over.

Art Hunkins

----- Original Message ----- 
From: "Iain McCurdy" 
To: 
Sent: Friday, July 31, 2009 1:37 PM
Subject: [Csnd] RE: Re altime Audio Output Gargling



If you are using CsoundGUI make sure you don't have 'Skip CsOptions' ticked 
under the 'General' tab of the 'Configure' settings.
Iain

----------------------------------------
> Date: Fri, 31 Jul 2009 10:25:11 -0700
> From: midiguru23@sbcglobal.net
> To: csound@lists.bath.ac.uk
> Subject: [Csnd] Re altime Audio Output Gargling
>
>
> Now that I know my MIDI device number, I've been able to write a very 
> simple
> .csd that responds to MIDI by producing audio. Unfortunately, the audio is 
> a
> horrible gargling noise. I know the gargling is coming from the .csd,
> because I can hear the release segment in the linsegr amplitude envelope.
> But I should be hearing a nice sine wave....
>
> I've tried setting -b and -B to various values in .csoundrc. None of the
> settings I've tried changes the nature of the output in the slightest.
>
> Needless to say, all of my other audio apps sound just fine.
>
> What I think may be interesting is that the setting for -odac doesn't
> actually matter. Whether I select -odac1 or -odac6, the sound always 
> arrives
> via the default audio device specified in the Windows control panel.
> According to the Csound console messages window (I'm back in the GUI 
> now --
> tried it in the DOS prompt, it sounds just the same there), PortAudio 
> device
> 6 is the M-Audio FW410's SPDIF output. So I think we have to assume that 
> the
> -odac setting in  is being ignored.
>
> Now, it's possible that the GUI is inserting command-line arguments, which
> are overriding . Except ... when I run the .csd from the DOS
> prompt, an argument of -odac 6 is _still_ being ignored. And the manual
> would lead one to believe that only the command line itself can override 
> the
> settings in .
>
> So what I have is garbage audio that is entirely unaffected by the 
> settings
> for -b, -B, and -odac. Can anyone suggest why this might be happening?
>
> --Jim Aikin
>
> --
> View this message in context: 
> http://www.nabble.com/Realtime-Audio-Output-Gargling-tp24760065p24760065.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound"

_________________________________________________________________
Windows Live™ Hotmail®: Celebrate the moment with your favorite sports pics. 
Check it out.
http://www.windowslive.com/Online/Hotmail/Campaign/QuickAdd?ocid=TXT_TAGLM_WL_QA_HM_sports_photos_072009&cat=sports

Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
csound"= 

Art Hunkins wrote:
> 
> Including MIDI and audio drivers there are only about 10 Csound files I 
> actually use; I put them in a single folder, then add my .csd(s) and 
> whatever front-end I may be using, click through to that folder and run. 
> Prior to then, I get rid of my .csoundrc and environment variables, and
> put 
> all my necessary commandline options in .
> 

With respect to environment variables, I seem to have settings for CSOUNDRC,
OPCODEDIR, OPCODEDIR64 (though the current csound version I'm using is NOT
the 64-bit version), and PYTHONPATH. I don't think any of the other paths in
the list are Csound-related.

I tried getting rid of .csoundrc entirely. What I think is interesting is
that now rendering a pre-written score file to the dac works fine from the
DOS command prompt -- it sounds perfect -- but produces gargling from the
GUI. And that's _without_ a .csoundrc file anywhere in the system. The
pre-written score file doesn't have ANY of those options in its CSoptions
area! Yet it plays from the command line.

The simple MIDI input test file I posted earlier, however, produces gargling
when run from the command line. So I tried replacing its complex options
(all the stuff in .csoundrc, a file which now no longer exists). And it
works! I hear my sine wave. The latency is horrible, but this is progress.

When I add values for -b and -B back into CSoptions, in order to try to cut
down on the latency, the gargling reappears. I could sit here all afternoon
testing various combinations of values for -b, -B, and ksmps, but I'll bet
you $5 that won't make any difference. I'm betting that the problem is that
PortAudio doesn't want to see ANY command-line argument for -b or -B.

I'm wondering a bit about the ASIO vs. MME audio. In the Windows Control
Panel one doesn't have an option to choose an ASIO driver; presumably the
system is using a high-latency MME driver. So if Csound is expecting to see
an ASIO driver, but it's _also_ automatically directing the audio to the
Windows system audio output ... it's vaguely possible that this conflict
could cause the problem I'm seeing. When I don't specify -b or -B, PortAudio
just says, "Okay, we'll use the standard MME audio pipeline, then." And
everything is copacetic.

But I'm making a blind guess here. I'm just saying ... -b and -B flat-out
don't work on my system, and I don't know why.

--JA



-- 
View this message in context: http://www.nabble.com/Realtime-Audio-Output-Gargling-tp24760065p24763048.html
Sent from the Csound - General mailing list archive at Nabble.com.

I'm afraid this is a little bit complex.

PortAudio does see the -b and -B options, and they do matter.

Your vague suspicion is, I think, the case., Plain -dac defaults to
whatever Windows thinks is the audio output. This may or may not be
what you want. -dacN will choose the driver listed as N by Csound when
it runs.

Hope this helps,
Mike



On 7/31/09, Jim Aikin  wrote:
>
>
> Art Hunkins wrote:
>>
>> Including MIDI and audio drivers there are only about 10 Csound files I
>> actually use; I put them in a single folder, then add my .csd(s) and
>> whatever front-end I may be using, click through to that folder and run.
>> Prior to then, I get rid of my .csoundrc and environment variables, and
>> put
>> all my necessary commandline options in .
>>
>
> With respect to environment variables, I seem to have settings for CSOUNDRC,
> OPCODEDIR, OPCODEDIR64 (though the current csound version I'm using is NOT
> the 64-bit version), and PYTHONPATH. I don't think any of the other paths in
> the list are Csound-related.
>
> I tried getting rid of .csoundrc entirely. What I think is interesting is
> that now rendering a pre-written score file to the dac works fine from the
> DOS command prompt -- it sounds perfect -- but produces gargling from the
> GUI. And that's _without_ a .csoundrc file anywhere in the system. The
> pre-written score file doesn't have ANY of those options in its CSoptions
> area! Yet it plays from the command line.
>
> The simple MIDI input test file I posted earlier, however, produces gargling
> when run from the command line. So I tried replacing its complex options
> (all the stuff in .csoundrc, a file which now no longer exists). And it
> works! I hear my sine wave. The latency is horrible, but this is progress.
>
> When I add values for -b and -B back into CSoptions, in order to try to cut
> down on the latency, the gargling reappears. I could sit here all afternoon
> testing various combinations of values for -b, -B, and ksmps, but I'll bet
> you $5 that won't make any difference. I'm betting that the problem is that
> PortAudio doesn't want to see ANY command-line argument for -b or -B.
>
> I'm wondering a bit about the ASIO vs. MME audio. In the Windows Control
> Panel one doesn't have an option to choose an ASIO driver; presumably the
> system is using a high-latency MME driver. So if Csound is expecting to see
> an ASIO driver, but it's _also_ automatically directing the audio to the
> Windows system audio output ... it's vaguely possible that this conflict
> could cause the problem I'm seeing. When I don't specify -b or -B, PortAudio
> just says, "Okay, we'll use the standard MME audio pipeline, then." And
> everything is copacetic.
>
> But I'm making a blind guess here. I'm just saying ... -b and -B flat-out
> don't work on my system, and I don't know why.
>
> --JA
>
>
>
> --
> View this message in context:
> http://www.nabble.com/Realtime-Audio-Output-Gargling-tp24760065p24763048.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

Michael Gogins-2 wrote:
> 
> I'm afraid this is a little bit complex.
> 
> PortAudio does see the -b and -B options, and they do matter.
> 
> Your vague suspicion is, I think, the case., Plain -dac defaults to
> whatever Windows thinks is the audio output. This may or may not be
> what you want. -dacN will choose the driver listed as N by Csound when
> it runs.
> 

Thanks, Michael. (And I apologize for being snarky about the file in the
examples folder!) Here's my tentative diagnosis -- subject to follow-up from
wiser heads. In version 5.10 for Windows (running under XP SP3):

1) The number following odac is being ignored. No matter how I set it, the
audio output ALWAYS goes to the port specified in the Windows system control
panel as the default audio device.

2) Settings for -b and -B, if they exist, prevent PortAudio from sending
data to the Windows audio device in a manner that it can deal with. The
result is gargling caused by buffer underruns or something similar. If there
are NO settings for these options, PortAudio produces good output, though
with high latency, making it unsuitable for any sort of real-time MIDI
performance.

3) Because the GUI automatically sets -b and -B, it can't be used.

If anyone can suggest tests that will further narrow this down, I'll be
happy to try them.

--JA
-- 
View this message in context: http://www.nabble.com/Realtime-Audio-Output-Gargling-tp24760065p24763343.html
Sent from the Csound - General mailing list archive at Nabble.com.

Victor.Lazzarini wrote:
> 
> In addition, -odac  is hardly going to be the fastest option, whichis
> ASIO. The ASIO drivers are in my experience oftern the last oneslisted by
> portaudio (the highest numbers). The low numbers andthe default IO often
> is the old MME out.Victor

Good point. But when I tried switching to -odac 16, which is listed by
PortAudio as Asio4All, or -odac 17, which is M-Audio FW ASIO, this did not
reduce the latency. And when I tried restoring values for -b and -B
(specifically, -b 128 -B 512) while using either of these ASIO drivers, the
gargling sound returned. So I'm still suspecting that the settting for -odac
is being ignored.

--JA

-- 
View this message in context: http://www.nabble.com/Realtime-Audio-Output-Gargling-tp24760065p24763579.html
Sent from the Csound - General mailing list archive at Nabble.com.

Well, you can check whether it's the ASIO driver that is running.
I think ASIO4all has a control that pops up when it's running.
Another way of testing is to try to use the device with another
program. If it's being used by an ASIO driver, it will not let
you use it and you'll then know.

Are you using both input and output? If so, please set the
ksmps to a power of two (8,16,32,64).

Otherwise, I'd be surprised if your ASIO IO does not give
you a good latency. In my 5-year old system, I could go down
to -b64 -B128.

Victor

----- Original Message ----- 
From: "Jim Aikin" 
To: 
Sent: Friday, July 31, 2009 10:47 PM
Subject: [Csnd] Re: Re: Re: RE: Re altime Audio Output Gargling




Victor.Lazzarini wrote:
>
> In addition, -odac is hardly going to be the fastest option, whichis
> ASIO. The ASIO drivers are in my experience oftern the last oneslisted by
> portaudio (the highest numbers). The low numbers andthe default IO often
> is the old MME out.Victor

Good point. But when I tried switching to -odac 16, which is listed by
PortAudio as Asio4All, or -odac 17, which is M-Audio FW ASIO, this did not
reduce the latency. And when I tried restoring values for -b and -B
(specifically, -b 128 -B 512) while using either of these ASIO drivers, the
gargling sound returned. So I'm still suspecting that the settting for -odac
is being ignored.

--JA

-- 
View this message in context: 
http://www.nabble.com/Realtime-Audio-Output-Gargling-tp24760065p24763579.html
Sent from the Csound - General mailing list archive at Nabble.com.



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
csound"= 

>> Good point. But when I tried switching to -odac 16, which is listed by
> PortAudio as Asio4All, or -odac 17, which is M-Audio FW ASIO, this did not
> reduce the latency. And when I tried restoring values for -b and -B
> (specifically, -b 128 -B 512) while using either of these ASIO drivers,
> the
> gargling sound returned. So I'm still suspecting that the settting for
> -odac
> is being ignored.
>

I thought the format was -odac17 and -odac16 without the space.  Or do I
miss-remember?

==John ff