I may have posted about this issue before, or something closely related, but
maybe not. If so, apologies for dredging up old discussions.

I'm trying to get real-time MIDI performance using QuteCsound 0.5 and Csound
5.11 in a Windows 7 64-bit machine. My audio interface is an M-Audio
Firewire 410. (I'm not using ASIO; Csound doesn't seem to know about ASIO
drivers.) What I'm finding is not only that the latency is pretty bad but
that the audio output stream is unstable.

In QuteCsound Configuration, I've set -b to 1024 and -B to 2048. If I go any
lower, I get serious glitching. That's ...barely... usable latency, but in
addition, there are glitches in the audio stream as I play MIDI notes,
especially when I start the file running but occasionally after that as
well. The header is set to ksmps = 8, because if I grow it any bigger I hear
zippering on the envelope release segment. But growing ksmps to a large
value doesn't, in any case, eliminate the glitches.

The instrument I'm playing (see below) is about as simple as could be
imagined -- two-op FM and a pair of envelopes.

The glitches are not caused by any sort of CPU overload. When I watch the
meters in Task Manager, it's obvious that Csound is not taxing the CPU; it's
just glitching all by itself. And I can easily sustain 16 notes without any
glitching. The glitching seems to be unrelated to CPU usage, except that it
exhibits, perhaps, a mild preference for happening at the beginnings of new
notes.

Have others encountered this? Are there ways to improve the reliability of
the audio stream (and perhaps reduce the latency a bit)? Thanks for any
tips!

--JA

;; entire .csd file, for reference purposes, omitting header and footer:

sr = 44100
ksmps = 8
nchnls = 2
0dbfs = 1
gibasefreq = 31

instr 1

inote	notnum
ioct = int(inote / 12) - 2
ioct	pow	2, ioct
inote = inote % 12
ipitchclass		table	inote, 11
ifreq = gibasefreq * ipitchclass * ioct

kampenv	linsegr 0, 0.005, 0.15, 1.5, 0.02, 1, 0.02, 0.08, 0
kindex	linsegr 0, 0.005, 2, 2, 0.1, 1, 0.1, 0.1, 0
asig	foscili kampenv, ifreq, 1, 1, kindex, 1

		outs	asig, asig
endin



f1 0 1024 10 1
f11 0 16 -2		1.0 1.0833 1.125 1.2 1.25 1.333 1.375 1.5 1.625 1.666 1.75
1.875 2 2 2 2

; to keep the file open during performance:
f101 300 8 10 1
e

Csound communicates with the ASIO drivers via portaudio (whoa, deja vu 
;-) ). So if you use portaudio, your basically using ASIO.

As for the ksmps = 8, if you use an a-rate envelope you could bump this 
up without zippering. I've also found that if you click the "run in 
terminal" button in QuteCsound the sound is less glitchy.

.mmb

Jim Aikin wrote:
> I may have posted about this issue before, or something closely related, but
> maybe not. If so, apologies for dredging up old discussions.
>
> I'm trying to get real-time MIDI performance using QuteCsound 0.5 and Csound
> 5.11 in a Windows 7 64-bit machine. My audio interface is an M-Audio
> Firewire 410. (I'm not using ASIO; Csound doesn't seem to know about ASIO
> drivers.) What I'm finding is not only that the latency is pretty bad but
> that the audio output stream is unstable.
>
> In QuteCsound Configuration, I've set -b to 1024 and -B to 2048. If I go any
> lower, I get serious glitching. That's ...barely... usable latency, but in
> addition, there are glitches in the audio stream as I play MIDI notes,
> especially when I start the file running but occasionally after that as
> well. The header is set to ksmps = 8, because if I grow it any bigger I hear
> zippering on the envelope release segment. But growing ksmps to a large
> value doesn't, in any case, eliminate the glitches.
>
> The instrument I'm playing (see below) is about as simple as could be
> imagined -- two-op FM and a pair of envelopes.
>
> The glitches are not caused by any sort of CPU overload. When I watch the
> meters in Task Manager, it's obvious that Csound is not taxing the CPU; it's
> just glitching all by itself. And I can easily sustain 16 notes without any
> glitching. The glitching seems to be unrelated to CPU usage, except that it
> exhibits, perhaps, a mild preference for happening at the beginnings of new
> notes.
>
> Have others encountered this? Are there ways to improve the reliability of
> the audio stream (and perhaps reduce the latency a bit)? Thanks for any
> tips!
>
> --JA
>
> ;; entire .csd file, for reference purposes, omitting header and footer:
>
> sr = 44100
> ksmps = 8
> nchnls = 2
> 0dbfs = 1
> gibasefreq = 31
>
> instr 1
>
> inote	notnum
> ioct = int(inote / 12) - 2
> ioct	pow	2, ioct
> inote = inote % 12
> ipitchclass		table	inote, 11
> ifreq = gibasefreq * ipitchclass * ioct
>
> kampenv	linsegr 0, 0.005, 0.15, 1.5, 0.02, 1, 0.02, 0.08, 0
> kindex	linsegr 0, 0.005, 2, 2, 0.1, 1, 0.1, 0.1, 0
> asig	foscili kampenv, ifreq, 1, 1, kindex, 1
>
> 		outs	asig, asig
> endin
>
> 
> 
> f1 0 1024 10 1
> f11 0 16 -2		1.0 1.0833 1.125 1.2 1.25 1.333 1.375 1.5 1.625 1.666 1.75
> 1.875 2 2 2 2
>
> ; to keep the file open during performance:
> f101 300 8 10 1
> e
>   



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Mike Moser-Booth wrote:
> 
> Csound communicates with the ASIO drivers via portaudio (whoa, deja vu 
> ;-) ). So if you use portaudio, your basically using ASIO.
> 
Hmm ... in that case, I'd expect to be able to crank the buffer lower than
1024.

Mike Moser-Booth wrote:
> 
> As for the ksmps = 8, if you use an a-rate envelope you could bump this 
> up without zippering. I've also found that if you click the "run in 
> terminal" button in QuteCsound the sound is less glitchy.
> 
It won't run in the terminal. The terminal gives me an error message that
says "Csound Command ERROR: too many arguments". The self-same file,
however, runs fine from within QuteCsound. Go figure.

I've found that playback on the MacBook seems solid (though with a USB audio
device, not a Firewire audio device) ... this is some kind of
Windows-specific problem.

--JA

On Windows there are a few options for 'infrastructure' audio (via 
portaudio). All of them but ASIO are very high latency.
Portaudio is starting to support WASAPI, but from what I read is not 
low-latency yet.

So, if you want RT low-latency audio on Windows, you will need to use ASIO. 
If you don't have an ASIO driver, you
can try downlading ASIO4All (not sure on Windows 7, though. It works  on XP 
& Vista). With ASIO, I managed
buffers down to 128, 64 samples (-b) and very low latency (XP, never really 
tested on Vista)

Victor


----- Original Message ----- 
From: "Jim Aikin" 
To: 
Sent: Friday, June 11, 2010 4:30 AM
Subject: [Csnd] Re: Re al-Time Audio


>
>
>
> Mike Moser-Booth wrote:
>>
>> Csound communicates with the ASIO drivers via portaudio (whoa, deja vu
>> ;-) ). So if you use portaudio, your basically using ASIO.
>>
> Hmm ... in that case, I'd expect to be able to crank the buffer lower than
> 1024.
>
> Mike Moser-Booth wrote:
>>
>> As for the ksmps = 8, if you use an a-rate envelope you could bump this
>> up without zippering. I've also found that if you click the "run in
>> terminal" button in QuteCsound the sound is less glitchy.
>>
> It won't run in the terminal. The terminal gives me an error message that
> says "Csound Command ERROR: too many arguments". The self-same file,
> however, runs fine from within QuteCsound. Go figure.
>
> I've found that playback on the MacBook seems solid (though with a USB 
> audio
> device, not a Firewire audio device) ... this is some kind of
> Windows-specific problem.
>
> --JA
> -- 
> View this message in context: 
> http://old.nabble.com/Real-Time-Audio-tp28850252p28851013.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound"
> 



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Thanks for the nudge, Victor. I had already tried using Asio4all as the
output, and Csound didn't like it ... but sometimes I'm a little slow. On
reading your message, I belatedly realized that the error message I had been
seeing was about the output device not matching the input device.

I'm not using audio input, so why should that matter? Well, it does. I
launched QuteCsound and specified Asio4all as both the output and the input,
and now it works. I'm getting glitch-free playback with reasonable latency.

I haven't yet tested it with a complex instrument definition, that's the
next step. But there are ways to optimize instrument code, and I'm sure I'll
be learning some of them!

--JA


Victor Lazzarini wrote:
> 
> On Windows there are a few options for 'infrastructure' audio (via 
> portaudio). All of them but ASIO are very high latency.
> Portaudio is starting to support WASAPI, but from what I read is not 
> low-latency yet.
> 
> So, if you want RT low-latency audio on Windows, you will need to use
> ASIO. 
> If you don't have an ASIO driver, you
> can try downlading ASIO4All (not sure on Windows 7, though. It works  on
> XP 
> & Vista). With ASIO, I managed
> buffers down to 128, 64 samples (-b) and very low latency (XP, never
> really 
> tested on Vista)
> 
> Victor
> 
> 
> ----- Original Message ----- 
> From: "Jim Aikin" 
> To: 
> Sent: Friday, June 11, 2010 4:30 AM
> Subject: [Csnd] Re: Re al-Time Audio
> 
> 
>>
>>
>>
>> Mike Moser-Booth wrote:
>>>
>>> Csound communicates with the ASIO drivers via portaudio (whoa, deja vu
>>> ;-) ). So if you use portaudio, your basically using ASIO.
>>>
>> Hmm ... in that case, I'd expect to be able to crank the buffer lower
>> than
>> 1024.
>>
>> Mike Moser-Booth wrote:
>>>
>>> As for the ksmps = 8, if you use an a-rate envelope you could bump this
>>> up without zippering. I've also found that if you click the "run in
>>> terminal" button in QuteCsound the sound is less glitchy.
>>>
>> It won't run in the terminal. The terminal gives me an error message that
>> says "Csound Command ERROR: too many arguments". The self-same file,
>> however, runs fine from within QuteCsound. Go figure.
>>
>> I've found that playback on the MacBook seems solid (though with a USB 
>> audio
>> device, not a Firewire audio device) ... this is some kind of
>> Windows-specific problem.
>>
>> --JA
>> -- 
>> View this message in context: 
>> http://old.nabble.com/Real-Time-Audio-tp28850252p28851013.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
>> csound"
>> 
> 
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 
> 

Agreed. I just also wanted to mention that you can get even lower
buffer settings to work if you disable audio input (chek if you have
that -iadc option on, and remove it). It seems the synchronizing of
audio input and audio output creates some additional overhead, and
with only output enabled you're free to push harder on the buffers.

best
Oeyvind.

2010/6/11  :
> Maybe you have an -i adc  in your options. Csound only looks for input if
> there is one.
> The complex instrument definition should not matter anyway, because if your
> CPU cannot
> keep the pace, no amount of latency will do. The need for large buffers are
> generally only
> for marginal cases where there are strong peaks of CPU activity. For most
> synthesis instruments,
> either your CPU can do it or it can't. If it can, then with a low-latency
> audio driver, you can
> drive down the latency to reasonably low levels.
>
> Victor
>
> ----- Original Message -----
> From: Jim Aikin 
> Date: Friday, June 11, 2010 7:50 am
> Subject: [Csnd] Re: Re: Re al-Time Audio
> To: csound@lists.bath.ac.uk
>
>>
>> Thanks for the nudge, Victor. I had already tried using Asio4all
>> as the
>> output, and Csound didn't like it ... but sometimes I'm a little
>> slow. On
>> reading your message, I belatedly realized that the error
>> message I had been
>> seeing was about the output device not matching the input device.
>>
>> I'm not using audio input, so why should that matter? Well, it
>> does. I
>> launched QuteCsound and specified Asio4all as both the output
>> and the input,
>> and now it works. I'm getting glitch-free playback with
>> reasonable latency.
>>
>> I haven't yet tested it with a complex instrument definition,
>> that's the
>> next step. But there are ways to optimize instrument code, and
>> I'm sure I'll
>> be learning some of them!
>>
>> --JA
>>
>>
>> Victor Lazzarini wrote:
>> >
>> > On Windows there are a few options for 'infrastructure' audio
>> (via
>> > portaudio). All of them but ASIO are very high latency.
>> > Portaudio is starting to support WASAPI, but from what I read
>> is not
>> > low-latency yet.
>> >
>> > So, if you want RT low-latency audio on Windows, you will need
>> to use
>> > ASIO.
>> > If you don't have an ASIO driver, you
>> > can try downlading ASIO4All (not sure on Windows 7, though. It
>> works  on
>> > XP
>> > & Vista). With ASIO, I managed
>> > buffers down to 128, 64 samples (-b) and very low latency (XP, never
>> > really
>> > tested on Vista)
>> >
>> > Victor
>> >
>> >
>> > ----- Original Message -----
>> > From: "Jim Aikin" 
>> > To: 
>> > Sent: Friday, June 11, 2010 4:30 AM
>> > Subject: [Csnd] Re: Re al-Time Audio
>> >
>> >
>> >>
>> >>
>> >>
>> >> Mike Moser-Booth wrote:
>> >>>
>> >>> Csound communicates with the ASIO drivers via portaudio
>> (whoa, deja vu
>> >>> ;-) ). So if you use portaudio, your basically using ASIO.
>> >>>
>> >> Hmm ... in that case, I'd expect to be able to crank the
>> buffer lower
>> >> than
>> >> 1024.
>> >>
>> >> Mike Moser-Booth wrote:
>> >>>
>> >>> As for the ksmps = 8, if you use an a-rate envelope you
>> could bump this
>> >>> up without zippering. I've also found that if you click the
>> "run in
>> >>> terminal" button in QuteCsound the sound is less glitchy.
>> >>>
>> >> It won't run in the terminal. The terminal gives me an error
>> message that
>> >> says "Csound Command ERROR: too many arguments". The self-
>> same file,
>> >> however, runs fine from within QuteCsound. Go figure.
>> >>
>> >> I've found that playback on the MacBook seems solid (though
>> with a USB
>> >> audio
>> >> device, not a Firewire audio device) ... this is some kind of
>> >> Windows-specific problem.
>> >>
>> >> --JA
>> >> --
>> >> View this message in context:
>> >> http://old.nabble.com/Real-Time-Audio-tp28850252p28851013.html
>> >> Sent from the Csound - General mailing list archive at Nabble.com.
>> >>
>> >>
>> >>
>> >> Send bugs reports to the Sourceforge bug tracker
>> >>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> Discussions of bugs and features can be posted here
>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> "unsubscribe
>> >> csound"
>> >>
>> >
>> >
>> >
>> > Send bugs reports to the Sourceforge bug tracker
>> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> > Discussions of bugs and features can be posted here
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> "unsubscribe> csound"
>> >
>> >
>> >
>>
>> --
>> View this message in context: http://old.nabble.com/Real-Time-
>> Audio-tp28850252p28851812.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> "unsubscribe csound"
>>
>
> Dr Victor Lazzarini, Senior Lecturer, Dept. of Music,
> National University of Ireland, Maynooth
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I would suggest trying out the latest QuteCsound beta version.  Andres
can correct me if I'm wrong, but I think previous versions of
QuteCsound force the use of the input buffer.  AFAIK, the latest
QuteCsound beta (http://sourceforge.net/projects/qutecsound/files/)
does not force the input buffer to be used.  You may have to change
the realtime performance settings in the QuteCsound configuration, but
you should now be able to use smaller buffer sizes by setting the
"Input device (-i)" to "none()".

Cheers,
~ andy.f



On Fri, Jun 11, 2010 at 5:58 AM, Oeyvind Brandtsegg  wrote:
> Agreed. I just also wanted to mention that you can get even lower
> buffer settings to work if you disable audio input (chek if you have
> that -iadc option on, and remove it). It seems the synchronizing of
> audio input and audio output creates some additional overhead, and
> with only output enabled you're free to push harder on the buffers.
>
> best
> Oeyvind.
>
> 2010/6/11  :
>> Maybe you have an -i adc  in your options. Csound only looks for input if
>> there is one.
>> The complex instrument definition should not matter anyway, because if your
>> CPU cannot
>> keep the pace, no amount of latency will do. The need for large buffers are
>> generally only
>> for marginal cases where there are strong peaks of CPU activity. For most
>> synthesis instruments,
>> either your CPU can do it or it can't. If it can, then with a low-latency
>> audio driver, you can
>> drive down the latency to reasonably low levels.
>>
>> Victor
>>
>> ----- Original Message -----
>> From: Jim Aikin 
>> Date: Friday, June 11, 2010 7:50 am
>> Subject: [Csnd] Re: Re: Re al-Time Audio
>> To: csound@lists.bath.ac.uk
>>
>>>
>>> Thanks for the nudge, Victor. I had already tried using Asio4all
>>> as the
>>> output, and Csound didn't like it ... but sometimes I'm a little
>>> slow. On
>>> reading your message, I belatedly realized that the error
>>> message I had been
>>> seeing was about the output device not matching the input device.
>>>
>>> I'm not using audio input, so why should that matter? Well, it
>>> does. I
>>> launched QuteCsound and specified Asio4all as both the output
>>> and the input,
>>> and now it works. I'm getting glitch-free playback with
>>> reasonable latency.
>>>
>>> I haven't yet tested it with a complex instrument definition,
>>> that's the
>>> next step. But there are ways to optimize instrument code, and
>>> I'm sure I'll
>>> be learning some of them!
>>>
>>> --JA
>>>
>>>
>>> Victor Lazzarini wrote:
>>> >
>>> > On Windows there are a few options for 'infrastructure' audio
>>> (via
>>> > portaudio). All of them but ASIO are very high latency.
>>> > Portaudio is starting to support WASAPI, but from what I read
>>> is not
>>> > low-latency yet.
>>> >
>>> > So, if you want RT low-latency audio on Windows, you will need
>>> to use
>>> > ASIO.
>>> > If you don't have an ASIO driver, you
>>> > can try downlading ASIO4All (not sure on Windows 7, though. It
>>> works  on
>>> > XP
>>> > & Vista). With ASIO, I managed
>>> > buffers down to 128, 64 samples (-b) and very low latency (XP, never
>>> > really
>>> > tested on Vista)
>>> >
>>> > Victor
>>> >
>>> >
>>> > ----- Original Message -----
>>> > From: "Jim Aikin" 
>>> > To: 
>>> > Sent: Friday, June 11, 2010 4:30 AM
>>> > Subject: [Csnd] Re: Re al-Time Audio
>>> >
>>> >
>>> >>
>>> >>
>>> >>
>>> >> Mike Moser-Booth wrote:
>>> >>>
>>> >>> Csound communicates with the ASIO drivers via portaudio
>>> (whoa, deja vu
>>> >>> ;-) ). So if you use portaudio, your basically using ASIO.
>>> >>>
>>> >> Hmm ... in that case, I'd expect to be able to crank the
>>> buffer lower
>>> >> than
>>> >> 1024.
>>> >>
>>> >> Mike Moser-Booth wrote:
>>> >>>
>>> >>> As for the ksmps = 8, if you use an a-rate envelope you
>>> could bump this
>>> >>> up without zippering. I've also found that if you click the
>>> "run in
>>> >>> terminal" button in QuteCsound the sound is less glitchy.
>>> >>>
>>> >> It won't run in the terminal. The terminal gives me an error
>>> message that
>>> >> says "Csound Command ERROR: too many arguments". The self-
>>> same file,
>>> >> however, runs fine from within QuteCsound. Go figure.
>>> >>
>>> >> I've found that playback on the MacBook seems solid (though
>>> with a USB
>>> >> audio
>>> >> device, not a Firewire audio device) ... this is some kind of
>>> >> Windows-specific problem.
>>> >>
>>> >> --JA
>>> >> --
>>> >> View this message in context:
>>> >> http://old.nabble.com/Real-Time-Audio-tp28850252p28851013.html
>>> >> Sent from the Csound - General mailing list archive at Nabble.com.
>>> >>
>>> >>
>>> >>
>>> >> Send bugs reports to the Sourceforge bug tracker
>>> >>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> >> Discussions of bugs and features can be posted here
>>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> "unsubscribe
>>> >> csound"
>>> >>
>>> >
>>> >
>>> >
>>> > Send bugs reports to the Sourceforge bug tracker
>>> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> > Discussions of bugs and features can be posted here
>>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> "unsubscribe> csound"
>>> >
>>> >
>>> >
>>>
>>> --
>>> View this message in context: http://old.nabble.com/Real-Time-
>>> Audio-tp28850252p28851812.html
>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> "unsubscribe csound"
>>>
>>
>> Dr Victor Lazzarini, Senior Lecturer, Dept. of Music,
>> National University of Ireland, Maynooth
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

On Windows, PortAudio includes other drivers in addition to ASIO.

Regards,
Mike

On Thu, Jun 10, 2010 at 10:46 PM, Mike Moser-Booth
 wrote:
> Csound communicates with the ASIO drivers via portaudio (whoa, deja vu ;-)
> ). So if you use portaudio, your basically using ASIO.
>
> As for the ksmps = 8, if you use an a-rate envelope you could bump this up
> without zippering. I've also found that if you click the "run in terminal"
> button in QuteCsound the sound is less glitchy.
>
> .mmb
>
> Jim Aikin wrote:
>>
>> I may have posted about this issue before, or something closely related,
>> but
>> maybe not. If so, apologies for dredging up old discussions.
>>
>> I'm trying to get real-time MIDI performance using QuteCsound 0.5 and
>> Csound
>> 5.11 in a Windows 7 64-bit machine. My audio interface is an M-Audio
>> Firewire 410. (I'm not using ASIO; Csound doesn't seem to know about ASIO
>> drivers.) What I'm finding is not only that the latency is pretty bad but
>> that the audio output stream is unstable.
>>
>> In QuteCsound Configuration, I've set -b to 1024 and -B to 2048. If I go
>> any
>> lower, I get serious glitching. That's ...barely... usable latency, but in
>> addition, there are glitches in the audio stream as I play MIDI notes,
>> especially when I start the file running but occasionally after that as
>> well. The header is set to ksmps = 8, because if I grow it any bigger I
>> hear
>> zippering on the envelope release segment. But growing ksmps to a large
>> value doesn't, in any case, eliminate the glitches.
>>
>> The instrument I'm playing (see below) is about as simple as could be
>> imagined -- two-op FM and a pair of envelopes.
>>
>> The glitches are not caused by any sort of CPU overload. When I watch the
>> meters in Task Manager, it's obvious that Csound is not taxing the CPU;
>> it's
>> just glitching all by itself. And I can easily sustain 16 notes without
>> any
>> glitching. The glitching seems to be unrelated to CPU usage, except that
>> it
>> exhibits, perhaps, a mild preference for happening at the beginnings of
>> new
>> notes.
>>
>> Have others encountered this? Are there ways to improve the reliability of
>> the audio stream (and perhaps reduce the latency a bit)? Thanks for any
>> tips!
>>
>> --JA
>>
>> ;; entire .csd file, for reference purposes, omitting header and footer:
>>
>> sr = 44100
>> ksmps = 8
>> nchnls = 2
>> 0dbfs = 1
>> gibasefreq = 31
>>
>> instr 1
>>
>> inote   notnum
>> ioct = int(inote / 12) - 2
>> ioct    pow     2, ioct
>> inote = inote % 12
>> ipitchclass             table   inote, 11
>> ifreq = gibasefreq * ipitchclass * ioct
>>
>> kampenv linsegr 0, 0.005, 0.15, 1.5, 0.02, 1, 0.02, 0.08, 0
>> kindex  linsegr 0, 0.005, 2, 2, 0.1, 1, 0.1, 0.1, 0
>> asig    foscili kampenv, ifreq, 1, 1, kindex, 1
>>
>>                outs    asig, asig
>> endin
>>
>> 
>> 
>> f1 0 1024 10 1
>> f11 0 16 -2             1.0 1.0833 1.125 1.2 1.25 1.333 1.375 1.5 1.625
>> 1.666 1.75
>> 1.875 2 2 2 2
>>
>> ; to keep the file open during performance:
>> f101 300 8 10 1
>> e
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> 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


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi,

Yes, previous versions would add the -i flag even if you didn't
specify anything. The latest beta fixes this. There should also be a
noticeable improvement in performance with respect to earlier
versions, but I'd really appreciate feedback. I haven't announced the
beta, because OS X versions aren't yet done, but if you are on Windows
and want to give the new QuteCsound a try, you can go to:
http://sourceforge.net/projects/qutecsound/files/

Feedback, bug reports and ideas most welcome as usual.

Cheers,
Andrés

On Fri, Jun 11, 2010 at 12:57 PM, andy fillebrown
 wrote:
> I would suggest trying out the latest QuteCsound beta version.  Andres
> can correct me if I'm wrong, but I think previous versions of
> QuteCsound force the use of the input buffer.  AFAIK, the latest
> QuteCsound beta (http://sourceforge.net/projects/qutecsound/files/)
> does not force the input buffer to be used.  You may have to change
> the realtime performance settings in the QuteCsound configuration, but
> you should now be able to use smaller buffer sizes by setting the
> "Input device (-i)" to "none()".
>
> Cheers,
> ~ andy.f
>
>
>
> On Fri, Jun 11, 2010 at 5:58 AM, Oeyvind Brandtsegg  wrote:
>> Agreed. I just also wanted to mention that you can get even lower
>> buffer settings to work if you disable audio input (chek if you have
>> that -iadc option on, and remove it). It seems the synchronizing of
>> audio input and audio output creates some additional overhead, and
>> with only output enabled you're free to push harder on the buffers.
>>
>> best
>> Oeyvind.
>>
>> 2010/6/11  :
>>> Maybe you have an -i adc  in your options. Csound only looks for input if
>>> there is one.
>>> The complex instrument definition should not matter anyway, because if your
>>> CPU cannot
>>> keep the pace, no amount of latency will do. The need for large buffers are
>>> generally only
>>> for marginal cases where there are strong peaks of CPU activity. For most
>>> synthesis instruments,
>>> either your CPU can do it or it can't. If it can, then with a low-latency
>>> audio driver, you can
>>> drive down the latency to reasonably low levels.
>>>
>>> Victor
>>>
>>> ----- Original Message -----
>>> From: Jim Aikin 
>>> Date: Friday, June 11, 2010 7:50 am
>>> Subject: [Csnd] Re: Re: Re al-Time Audio
>>> To: csound@lists.bath.ac.uk
>>>
>>>>
>>>> Thanks for the nudge, Victor. I had already tried using Asio4all
>>>> as the
>>>> output, and Csound didn't like it ... but sometimes I'm a little
>>>> slow. On
>>>> reading your message, I belatedly realized that the error
>>>> message I had been
>>>> seeing was about the output device not matching the input device.
>>>>
>>>> I'm not using audio input, so why should that matter? Well, it
>>>> does. I
>>>> launched QuteCsound and specified Asio4all as both the output
>>>> and the input,
>>>> and now it works. I'm getting glitch-free playback with
>>>> reasonable latency.
>>>>
>>>> I haven't yet tested it with a complex instrument definition,
>>>> that's the
>>>> next step. But there are ways to optimize instrument code, and
>>>> I'm sure I'll
>>>> be learning some of them!
>>>>
>>>> --JA
>>>>
>>>>
>>>> Victor Lazzarini wrote:
>>>> >
>>>> > On Windows there are a few options for 'infrastructure' audio
>>>> (via
>>>> > portaudio). All of them but ASIO are very high latency.
>>>> > Portaudio is starting to support WASAPI, but from what I read
>>>> is not
>>>> > low-latency yet.
>>>> >
>>>> > So, if you want RT low-latency audio on Windows, you will need
>>>> to use
>>>> > ASIO.
>>>> > If you don't have an ASIO driver, you
>>>> > can try downlading ASIO4All (not sure on Windows 7, though. It
>>>> works  on
>>>> > XP
>>>> > & Vista). With ASIO, I managed
>>>> > buffers down to 128, 64 samples (-b) and very low latency (XP, never
>>>> > really
>>>> > tested on Vista)
>>>> >
>>>> > Victor
>>>> >
>>>> >
>>>> > ----- Original Message -----
>>>> > From: "Jim Aikin" 
>>>> > To: 
>>>> > Sent: Friday, June 11, 2010 4:30 AM
>>>> > Subject: [Csnd] Re: Re al-Time Audio
>>>> >
>>>> >
>>>> >>
>>>> >>
>>>> >>
>>>> >> Mike Moser-Booth wrote:
>>>> >>>
>>>> >>> Csound communicates with the ASIO drivers via portaudio
>>>> (whoa, deja vu
>>>> >>> ;-) ). So if you use portaudio, your basically using ASIO.
>>>> >>>
>>>> >> Hmm ... in that case, I'd expect to be able to crank the
>>>> buffer lower
>>>> >> than
>>>> >> 1024.
>>>> >>
>>>> >> Mike Moser-Booth wrote:
>>>> >>>
>>>> >>> As for the ksmps = 8, if you use an a-rate envelope you
>>>> could bump this
>>>> >>> up without zippering. I've also found that if you click the
>>>> "run in
>>>> >>> terminal" button in QuteCsound the sound is less glitchy.
>>>> >>>
>>>> >> It won't run in the terminal. The terminal gives me an error
>>>> message that
>>>> >> says "Csound Command ERROR: too many arguments". The self-
>>>> same file,
>>>> >> however, runs fine from within QuteCsound. Go figure.
>>>> >>
>>>> >> I've found that playback on the MacBook seems solid (though
>>>> with a USB
>>>> >> audio
>>>> >> device, not a Firewire audio device) ... this is some kind of
>>>> >> Windows-specific problem.
>>>> >>
>>>> >> --JA
>>>> >> --
>>>> >> View this message in context:
>>>> >> http://old.nabble.com/Real-Time-Audio-tp28850252p28851013.html
>>>> >> Sent from the Csound - General mailing list archive at Nabble.com.
>>>> >>
>>>> >>
>>>> >>
>>>> >> Send bugs reports to the Sourceforge bug tracker
>>>> >>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> >> Discussions of bugs and features can be posted here
>>>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>> "unsubscribe
>>>> >> csound"
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > Send bugs reports to the Sourceforge bug tracker
>>>> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> > Discussions of bugs and features can be posted here
>>>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>> "unsubscribe> csound"
>>>> >
>>>> >
>>>> >
>>>>
>>>> --
>>>> View this message in context: http://old.nabble.com/Real-Time-
>>>> Audio-tp28850252p28851812.html
>>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>> "unsubscribe csound"
>>>>
>>>
>>> Dr Victor Lazzarini, Senior Lecturer, Dept. of Music,
>>> National University of Ireland, Maynooth
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>



-- 


Andrés


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"