In my opinion, you need to minimise the IO buffersize as much as possible, then look at ksmps. If you could achieve a buffer of 64 frames, with ksmps = 32, you would  be near to millisecond latency.

Victor Lazzarini

Dean of Arts, Celtic Studies, and Philosophy

Maynooth University

Ireland

On 2 May 2017, at 13:38, Michael Gogins <michael.gogins@GMAIL.COM> wrote:

Reduce ksmps to about 20. I have measured very little increase in computational efficiency with ksmps higher than that. 

You might also consider getting rid of OpenAL and doing your spatialization in Csound. Also the sample playback. But perhaps OpenAL is better for your speaker rigs. 

Csound on its own should be able to do synthesis, sample playback, and spatialization with about 3 to 5 ms latency.

Another option if you need to use OpenAL is to invert control, use OpenAL as opcodes for processing audio inside the Csound performance loop. 

I don't know how hard that would be but it must be possible. If OpenAL needs a "device" consider writing a device driver to make Csound such a device.

Hope this helps, 

Mike

On May 2, 2017 04:34, "Anders Genell" <anders.genell@gmail.com> wrote:

Dear devs!

I'd like if I may to tap into the huge collective knowledge concerning computer audio in general and Csound in particular that this forum represents.

Thanks to your generous support and suggestions we now successfully apply the Csound API to generate sound for our vehicle driving simulator. It uses OpenAL to spatialize sound and we (i.e. my programmer colleagues) have written a small program that polls for how many AL-buffers have been consumed and runs the corresponding number of performKsmps() iterations to generate enough audio to refill empty buffers.

One thing we are investigating though is the possibility to reduce latency. With the current setup we have a latency of about 350ms from pressing a button in our simulator vehicle cabin to onset of sound generated by Csound. We have file playback functionally independent of Csound (it basically takes a wav file and copies audio data from it into AL-buffers), and when triggering a file playback with the same vehicle cabin button the latency is about 150ms. The button-press is registered by a vehicle dynamics simulation program on a dedicated computer that then sends an udp message to the audio computer, som some delay is expected, but we would like to minimize the difference in latency between file playback and streaming Csound audio.

As we use performKsmps() (and access audio from spinout) we do not rely on -B or -b flags etc. ksmps currently set to 512 and the AL buffers are 2048 bytes. Right now we use 4 AL-buffers, so that's 4x2048.

As fast as I understand, AL (or in our case OpenAL-soft), does Ambisonic decoding of the spatial coordinates provided from the program using the lib to whatever speaker setup that is defined in the AL configuration file, so I guess the is one additional buffer worth of latency before copying to audio hardware, but that should be the same for audio files and streaming audio.

Any suggestions and ideas about where we could shave off a few millliseconds of latency would be greatly appreciated!

Best regards,
Anders

Do you need to have 4 buffers of 2048?  Is that in series?  Also, what
version of Csound are you using?

On Tue, May 2, 2017 at 4:13 PM, Oeyvind Brandtsegg
<oyvind.brandtsegg@ntnu.no> wrote:
> Hi Anders,
>
> It looks to me as if your latency in practice is larger than what you should
> expect from the buffer sizes you use.
> A ksmps of 512 should give you around 11 milliseconds latency at 44.1 kHz
> (and lower latency if your sr is higher). Even the outer OpenAL buffering of
> 2048 samples should not give you anything more than 46 millisecs. So the 350
> millisecs you have must be caused by something else. Adjusting the Csound
> ksmps might reduce the resulting latency somewhat , but I think it
> reasonable to look at other things that might cause the big delay.
> Perhaps there is something in the routine that " polls for how many
> AL-buffers have been consumed and runs the corresponding number of
> performKsmps() iterations to generate enough audio to refill empty buffers."
> ?
>
> Also, as Michael suggests, if you can try running the audio directly out of
> Csound it might be faster/easier. If nothing else, you could try it as a
> test case, to see in practice what latency you get from Csound.
> And btw. what platform/OS is this? Can you run other audio processes with
> very low latency? (< 10 ms or so). Can you try running Csound on its own,
> without any of the other simulator components? Just using the button to
> trigger a Csound instrument directly. And, come to think of it (guessing,
> since I don't know the full system you have), could there me some latency in
> the signal chain from the button trigger you use as well? I know none of
> these things will explain the difference in latency between the direct
> sample playback and the Csound output, but, ... or, hey, if the routine
> calling performKsmps() has some issues that might explain the difference in
> latency there.
>
> Good luck. You'll find it.
>
> 2017-05-02 5:51 GMT-07:00 Victor Lazzarini <Victor.Lazzarini@nuim.ie>:
>>
>> In my opinion, you need to minimise the IO buffersize as much as possible,
>> then look at ksmps. If you could achieve a buffer of 64 frames, with ksmps =
>> 32, you would  be near to millisecond latency.
>>
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>>
>> On 2 May 2017, at 13:38, Michael Gogins <michael.gogins@GMAIL.COM> wrote:
>>
>> Reduce ksmps to about 20. I have measured very little increase in
>> computational efficiency with ksmps higher than that.
>>
>> You might also consider getting rid of OpenAL and doing your
>> spatialization in Csound. Also the sample playback. But perhaps OpenAL is
>> better for your speaker rigs.
>>
>> Csound on its own should be able to do synthesis, sample playback, and
>> spatialization with about 3 to 5 ms latency.
>>
>> Another option if you need to use OpenAL is to invert control, use OpenAL
>> as opcodes for processing audio inside the Csound performance loop.
>>
>> I don't know how hard that would be but it must be possible. If OpenAL
>> needs a "device" consider writing a device driver to make Csound such a
>> device.
>>
>> Hope this helps,
>> Mike
>>
>>
>> On May 2, 2017 04:34, "Anders Genell" <anders.genell@gmail.com> wrote:
>>
>> Dear devs!
>>
>> I'd like if I may to tap into the huge collective knowledge concerning
>> computer audio in general and Csound in particular that this forum
>> represents.
>>
>> Thanks to your generous support and suggestions we now successfully apply
>> the Csound API to generate sound for our vehicle driving simulator. It uses
>> OpenAL to spatialize sound and we (i.e. my programmer colleagues) have
>> written a small program that polls for how many AL-buffers have been
>> consumed and runs the corresponding number of performKsmps() iterations to
>> generate enough audio to refill empty buffers.
>>
>> One thing we are investigating though is the possibility to reduce
>> latency. With the current setup we have a latency of about 350ms from
>> pressing a button in our simulator vehicle cabin to onset of sound generated
>> by Csound. We have file playback functionally independent of Csound (it
>> basically takes a wav file and copies audio data from it into AL-buffers),
>> and when triggering a file playback with the same vehicle cabin button the
>> latency is about 150ms. The button-press is registered by a vehicle dynamics
>> simulation program on a dedicated computer that then sends an udp message to
>> the audio computer, som some delay is expected, but we would like to
>> minimize the difference in latency between file playback and streaming
>> Csound audio.
>>
>> As we use performKsmps() (and access audio from spinout) we do not rely on
>> -B or -b flags etc. ksmps currently set to 512 and the AL buffers are 2048
>> bytes. Right now we use 4 AL-buffers, so that's 4x2048.
>>
>> As fast as I understand, AL (or in our case OpenAL-soft), does Ambisonic
>> decoding of the spatial coordinates provided from the program using the lib
>> to whatever speaker setup that is defined in the AL configuration file, so I
>> guess the is one additional buffer worth of latency before copying to audio
>> hardware, but that should be the same for audio files and streaming audio.
>>
>> Any suggestions and ideas about where we could shave off a few
>> millliseconds of latency would be greatly appreciated!
>>
>> Best regards,
>> Anders
>>
>>
>
>
>
> --
>
> Oeyvind Brandtsegg
> Professor of Music Technology
> NTNU
> 7491 Trondheim
> Norway
> Cell: +47 92 203 205
>
> http://www.partikkelaudio.com/
> http://crossadaptive.hf.ntnu.no
> http://gdsp.hf.ntnu.no/
> http://soundcloud.com/brandtsegg
> http://flyndresang.no/
> http://soundcloud.com/t-emp
>

Oh, I missed that it was indeed 4x2048, that would more or less account for the ~150 millisecs latency (if you use 48kHz it would be around 170 ms). How do you measure the latency?

2017-05-02 14:50 GMT-07:00 Steven Yi <stevenyi@gmail.com>:

Do you need to have 4 buffers of 2048?  Is that in series?  Also, what
version of Csound are you using?

On Tue, May 2, 2017 at 4:13 PM, Oeyvind Brandtsegg
<oyvind.brandtsegg@ntnu.no> wrote:
> Hi Anders,
>
> It looks to me as if your latency in practice is larger than what you should
> expect from the buffer sizes you use.
> A ksmps of 512 should give you around 11 milliseconds latency at 44.1 kHz
> (and lower latency if your sr is higher). Even the outer OpenAL buffering of
> 2048 samples should not give you anything more than 46 millisecs. So the 350
> millisecs you have must be caused by something else. Adjusting the Csound
> ksmps might reduce the resulting latency somewhat , but I think it
> reasonable to look at other things that might cause the big delay.
> Perhaps there is something in the routine that " polls for how many
> AL-buffers have been consumed and runs the corresponding number of
> performKsmps() iterations to generate enough audio to refill empty buffers."
> ?
>
> Also, as Michael suggests, if you can try running the audio directly out of
> Csound it might be faster/easier. If nothing else, you could try it as a
> test case, to see in practice what latency you get from Csound.
> And btw. what platform/OS is this? Can you run other audio processes with
> very low latency? (< 10 ms or so). Can you try running Csound on its own,
> without any of the other simulator components? Just using the button to
> trigger a Csound instrument directly. And, come to think of it (guessing,
> since I don't know the full system you have), could there me some latency in
> the signal chain from the button trigger you use as well? I know none of
> these things will explain the difference in latency between the direct
> sample playback and the Csound output, but, ... or, hey, if the routine
> calling performKsmps() has some issues that might explain the difference in
> latency there.
>
> Good luck. You'll find it.
>
> 2017-05-02 5:51 GMT-07:00 Victor Lazzarini <Victor.Lazzarini@nuim.ie>:
>>
>> In my opinion, you need to minimise the IO buffersize as much as possible,
>> then look at ksmps. If you could achieve a buffer of 64 frames, with ksmps =
>> 32, you would  be near to millisecond latency.
>>
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>>
>> On 2 May 2017, at 13:38, Michael Gogins <michael.gogins@GMAIL.COM> wrote:
>>
>> Reduce ksmps to about 20. I have measured very little increase in
>> computational efficiency with ksmps higher than that.
>>
>> You might also consider getting rid of OpenAL and doing your
>> spatialization in Csound. Also the sample playback. But perhaps OpenAL is
>> better for your speaker rigs.
>>
>> Csound on its own should be able to do synthesis, sample playback, and
>> spatialization with about 3 to 5 ms latency.
>>
>> Another option if you need to use OpenAL is to invert control, use OpenAL
>> as opcodes for processing audio inside the Csound performance loop.
>>
>> I don't know how hard that would be but it must be possible. If OpenAL
>> needs a "device" consider writing a device driver to make Csound such a
>> device.
>>
>> Hope this helps,
>> Mike
>>
>>
>> On May 2, 2017 04:34, "Anders Genell" <anders.genell@gmail.com> wrote:
>>
>> Dear devs!
>>
>> I'd like if I may to tap into the huge collective knowledge concerning
>> computer audio in general and Csound in particular that this forum
>> represents.
>>
>> Thanks to your generous support and suggestions we now successfully apply
>> the Csound API to generate sound for our vehicle driving simulator. It uses
>> OpenAL to spatialize sound and we (i.e. my programmer colleagues) have
>> written a small program that polls for how many AL-buffers have been
>> consumed and runs the corresponding number of performKsmps() iterations to
>> generate enough audio to refill empty buffers.
>>
>> One thing we are investigating though is the possibility to reduce
>> latency. With the current setup we have a latency of about 350ms from
>> pressing a button in our simulator vehicle cabin to onset of sound generated
>> by Csound. We have file playback functionally independent of Csound (it
>> basically takes a wav file and copies audio data from it into AL-buffers),
>> and when triggering a file playback with the same vehicle cabin button the
>> latency is about 150ms. The button-press is registered by a vehicle dynamics
>> simulation program on a dedicated computer that then sends an udp message to
>> the audio computer, som some delay is expected, but we would like to
>> minimize the difference in latency between file playback and streaming
>> Csound audio.
>>
>> As we use performKsmps() (and access audio from spinout) we do not rely on
>> -B or -b flags etc. ksmps currently set to 512 and the AL buffers are 2048
>> bytes. Right now we use 4 AL-buffers, so that's 4x2048.
>>
>> As fast as I understand, AL (or in our case OpenAL-soft), does Ambisonic
>> decoding of the spatial coordinates provided from the program using the lib
>> to whatever speaker setup that is defined in the AL configuration file, so I
>> guess the is one additional buffer worth of latency before copying to audio
>> hardware, but that should be the same for audio files and streaming audio.
>>
>> Any suggestions and ideas about where we could shave off a few
>> millliseconds of latency would be greatly appreciated!
>>
>> Best regards,
>> Anders
>>
>>
>
>
>
> --
>
> Oeyvind Brandtsegg
> Professor of Music Technology
> NTNU
> 7491 Trondheim
> Norway
> Cell: +47 92 203 205
>
> http://www.partikkelaudio.com/
> http://crossadaptive.hf.ntnu.no
> http://gdsp.hf.ntnu.no/
> http://soundcloud.com/brandtsegg
> http://flyndresang.no/
> http://soundcloud.com/t-emp
>

--

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://www.partikkelaudio.com/
http://crossadaptive.hf.ntnu.no
http://gdsp.hf.ntnu.no/
http://soundcloud.com/brandtsegg
http://flyndresang.no/
http://soundcloud.com/t-emp